2017-10-04 03:11 AM
Hi,
So I'm currently working on a product on the stm32f4 and we're trying to implement a simple firmware upgrade. The first solution that we used was to have a link on the board that you could use to connect BOOT0 to VD and then trigger a power cycle and when the device reboots it would boot up into DFU mode. This works but has the disadvantage that to access the link you have to unscrew the back of the device which isn't ideal when you are asking a customer to do it.
The next option was to have a USB command that we recognise in our code which sets a value (DEADBEEF) to a register address and then trigger a software restart, then upon startup that address is checked and if it is set it will force the uC into DFU mode.
This second method is much better other than the small issue that occurs due to the face that we enable read protection on the chip. as part of the upgrade process, we have to erase the flash once this has finished the chip reboots however as the 'DEADBEEF' has been cleared it doesn't boot into DFU mode.
Is anyone aware of a workaround to make the STM32F4 reboot into DFU mode after erasing the memory?
Thanks
2017-10-04 03:42 AM
Is anyone aware of a workaround to make the STM32F4 reboot into DFU mode after erasing the memory?
I think not.
Some newer F0 devices supposedly have a feature to start into the system bootloader if no application is present.
This works but has the disadvantage that to access the link you have to unscrew the back of the device which isn't ideal when you are asking a customer to do it.
With some experience in this matter, I actually view this as an advantage.
A few rhetorical questions to ask yourself:
2017-10-04 08:00 AM
>>Is anyone aware of a workaround to make the STM32F4 reboot into DFU mode after erasing the memory?
Ascribe some value to such a method..
2017-10-04 10:14 AM
... the value would be that you could program the unit via DFU after erasing the memory
2017-10-04 10:17 AM
I think not.
Some newer F0 devices supposedly have a feature to start into the system bootloader if no application is present.
That's a shame if it is indeed the case
:(
. Strangely enough the unit I have on my desk if I erase the flash will boot into DFU as standard, but it's the only unit, no idea why doesn't seem to be any other differences.2017-10-04 10:21 AM
that's not going to pay my bills
2017-10-04 10:32 AM
Yet it will pay my salary... I've been asked to implement a simple way for a user to upgrade the device. Ideally, that would mean that they wouldn't need to unscrew the back and
BOOT0 to +VD, instead, it would be much better if they could press one button and the rest of the process could be handled in software.
2017-10-04 11:12 AM
I described the 0xDEADBEEF method over 8 years ago, assume I understand the requirements expressed in the first post, and have a reasonable appreciation of how to solve difficult problems without using others code/methods.
2017-10-05 01:14 AM
Well, at least the F4 devices I know don't do this.
Not sure about the latest releases.
BTW, there seems some confusion with terms.
DFU is an USB mode/functionality, and (mostly) belongs to the attached debug adapter - except the device has an USB peripheral AND supports it in the bootloader.
A system bootloader (ROM-based) is present in all ST Cortex M devices.
Which device you are using ?
I remember that Cortex M devices of some other vendors routinely start into the system bootloader if they find no valid application.