Add DFU hijack warning to manufacturer guidelines

[howels]

No description provided.

[McGiverGim]

What about F7? The text only comment about F4 but I think it happens too on F7.

[howels]

What about F7? The text only comment about F4 but I think it happens too on F7.

Please can you determine the UARTs for F722, F745 and H743? I'm not familiar enough to say for sure.

[haslinghuis]

@SteveCEvans this is a known STM32 design issue - but like to have a low level professional for final review.

For the record, using MAMBAG4 with GPS on UART 4.
Connected I would need to use boot button to enter DFU while disconnected it works.

EDIT: Tested with an ublox M8N GPS attached to the FOSSF4ELRS. Several successful flashes without resorting to DFU button (with M10 module it was mandatory).

After a few retries even the boot button didn't get me in DFU mode. Removing UART1 connector worked. YMMV.

[howels]

@SteveCEvans this is a known STM32 design issue - but like to have a low level professional for final review.

For the record, using MAMBAG4 with GPS on UART 4. Connected I would need to use boot button to enter DFU while disconnected it works.

EDIT: Tested with an ublox M8N GPS attached to the FOSSF4ELRS. Several successful flashes without resorting to DFU button (with M10 module it was mandatory).

After a few retries even the boot button didn't get me in DFU mode. Removing UART1 connector worked. YMMV.

Does this mean that the PR is good to go or do you have unresolved problems?

[haslinghuis]

Happy with the information provided. Just want low level expert confirmation and sharing some test results.

As why would this only be limited to UART 1 -3 ?

[catphish]

To clarify something on this: using the DFU button shouldn't help, as the same problem exists no matter how the chip entered DFU mode.

[howels]

Happy with the information provided. Just want low level expert confirmation and sharing some test results.

As why would this only be limited to UART 1 -3 ?

Check the AN2606 doc referenced here, it lists the pins which the bootloader listens on:
https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

[catphish]

As why would this only be limited to UART 1 -3 ?

Which UARTs and pins are affected on each chip is documented in ST Application Node 2606. The information in this documentation is copied from that document.

https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

[haslinghuis]

Still part of the question remains. As indeed it only should interfere with UART 1-3 using GPS on UART4 on MAMBAG4 it won't boot into DFU, while removing the GPS it does.

[howels]

Still part of the question remains. As indeed it only should interfere with UART 1-3 using GPS on UART4 on MAMBAG4 it won't boot into DFU, while removing the GPS it does.

Please check the table in the PR, you will see that pins PC10,PC11 are referenced for G473 which are mapped to uart4 on the mambaG4:
https://github.com/betaflight/config/blob/604a108c3ff537163244fc02a1e86543f54e1c0a/configs/MAMBAG4/config.h#L68

[haslinghuis]

Cool, so not the UART mapped to the pin but the PINS itself are suspect-able to the issue (as not reflected in the table)

[catphish]

Cool, so not the UART mapped to the pin but the PINS itself are suspect-able to the issue (as not reflected in the table)

Remember that when the bootloader is running, betaflight's pin mappings have not yet been applied. Instead the bootloader has its own pin mappings. In some cases these mappings map one UART to multiple pairs of pins.

So for the purposes of this documentation, the UART numbers are actually not relevant, only the pin numbers really matter.

[howels]

Cool, so not the UART mapped to the pin but the PINS itself are suspect-able to the issue (as not reflected in the table)

Remember that when the bootloader is running, betaflight's pin mappings have not yet been applied. Instead the bootloader has its own pin mappings. In some cases these mappings map one UART to multiple pairs of pins.

So for the purposes of this documentation, the UART numbers are actually not relevant, only the pin numbers really matter.

Should I remove the UART column? It's hardware USART and not betaflight UARTs anyway

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
2.1% Duplication

[howels]

Updated the table, removing the manufacturer USART definition and leaving pairs of pins instead. These pins should be avoided when using GPS or RX that may be powered from 3.3V or 4v5.

[catphish]

My comments have already been addressed, so looks good to me.

[SteveCEvans]

Apologies for not getting to this sooner (been on vacation) but it’s a good update. DFU should be entered if 0x7F is received on a monitored USART. It’s evident that a number of peripheral devices can do this.

This is described in more detail at https://www.st.com/resource/en/application_note/an3155-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf#page5

Newer processors provide secure boot mechanisms to inhibit DFU attacks, but we have to live with F4s. I’ll look into our options for newer processors.