search

dmitrystu / sboot_stm32

Secure USB DFU1.1 bootloader for STM32
Apache License 2.0
303 stars 63 forks source link

Support multiple DFU transports? USART? #48

Open salyzyn opened 2 years ago

salyzyn commented 2 years ago

Consider allow adding another polling object in the loop so that multiple transports can be supported simultaneously. For instance, as per https://www.st.com/resource/en/application_note/cd00264342-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf, one could conceivably simultaneously support DFU on the USB bus, or serial flashing via a selected serial port. I can imagine this opening the door to USART, LIN, CAN, I2C, ETH & SDCard as transports to approach the functionality of the ST built-in bootloader feature set.

dmitrystu commented 2 years ago

This will cost a flashrom space. This may not be a problem for MCU's with large 16k first block, but it very sensitive for small MCU's. Also the DFU (not DFUse) don't support other interfaces

salyzyn commented 2 years ago

Flashrom space is always tradeoff, all firmware projects one would assume adding another transport would be a configuration option. Only affect those that want it. I only suggested this because the build-in bootblock for STM devices includes several interfaces/transport, one of which I desire (USART if the hint was not strong enough :-) ) .

When and if USART protocol becomes a priority for us (~1man/yr) and once we have the 'other end' of the USART link running, I would like to look into adding/testing it then, submitting it up for approval. I expect it to use the same protocol as the STM built-in bootloader, but would want (the optional) decryption running. Does that sound OK?