[Feature Support]Add support for STM32F303 MCU

[devanlai]

Hi @Linjieqiang,

It would be technically feasible to port it to the STM32F303, though I'm not sure how useful it would be - the STM32F303 already has an on-chip USB DfuSe bootloader that offers very similar functionality. Is there a particular reason that you need a flash-resident DFU bootloader like dapboot instead of the on-chip bootloader?

[Linjieqiang]

@devanlai Can we add encryption and decryption feature for the application with your bootloader?

[cvrtky]

How about just setting read protection bit?

Cheers Tim

2017-12-24 1:37 GMT+01:00 LinJieqiang notifications@github.com:

@devanlai https://github.com/devanlai Can we add encryption and decryption feature for the application with your bootloader?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/devanlai/dapboot/issues/9#issuecomment-353757311, or mute the thread https://github.com/notifications/unsubscribe-auth/AOXwjO2WMOiqo2k8xBiIP1W7dHFFJgHRks5tDZzDgaJpZM4RFUQ_ .

[devanlai]

@Linjieqiang It's certainly possible to add encryption / decryption, but that's not something I had any plans to implement. If you're looking for a USB DFU bootloader with support for encrypted firmware updates, you might be interested in the sboot_stm32 project. Note that while the sboot_stm32 handles encryption/decryption, it does not do any sort of authentication so it's possible to brick the device by attempting to load unencrypted firmware.

[Linjieqiang]

Thanks,

[Linjieqiang]

Hello devanlai.Would you like to add encryption / decryption feature in this project?

[fmckeogh]

If I wanted to implement support for STM32L0 series chips without on-chip bootloaders, would it be possible and if so, roughly what would the steps be? Thanks! :)

[devanlai]

Hi @chocol4te,

It looks like the STM32L0 series has USB support in libopencm3, so it should be doable. Broadly speaking, you would need to:

• Create a new target for your STM32L0 target in targets.mk
• Add compiler/linker flags for the STM32L0 architecture in rules.mk
• Implement the target-specific functions declared in target.h. The functions aren't really documented, but hopefully they're self-explanatory enough that you can work it out ;p.

The main caveat that I know of is that Cortex-M0 cores do not support vector table relocation. You would either need to:

1. Implement some kind of pass-through table where the bootloader interrupt handlers call the corresponding application interrupt handlers
2. Place the application vector table in SRAM and remap SRAM to 0x00000000, as described in this forum post: https://community.st.com/thread/30718

[fmckeogh]

@devanlai Thank you so much, that's really helpful! :D