STM32F405 Odd DFU behaviour

[Traud.Jason]

Posted on August 18, 2015 at 16:47

I'm experiencing some odd behaviour when attempting to place an STM32F405 into DFU mode. Currently, what works on one peice of hardware is that is that I send the STM32 a command to tell it to go into DFU mode, and a secondary processor pulls BOOT0 high. I've verified that the state of the BOOT0 and BOOT1 pins are as expected.

This works on some units, but not others. I was under the impression that the BOOT pins were triggered on an interrupt and were hands off. Is there some specific initialization I'm supposed to be performing on the boot pins to achieve the desired behaviour?EDIT:// The main application note I've found to put the device into DFU mode is application note AN26026.http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00167594.pdf

[Tesla DeLorean]

Posted on August 18, 2015 at 17:15

The BOOTx pins are latched at reset, to determine which memory is mapped at zero, and thus where execution starts.

[Traud.Jason]

Posted on August 19, 2015 at 21:28

So, after the BOOT pins are set in the proper states a reset needs to be called in order to ensure it goes into DFU mode?

Would the most appropriate method be to just call the ''Reset_Handler();'' function, or do I need to do anything lower level to achieve this?

[Tesla DeLorean]

Posted on August 19, 2015 at 21:37

Calling Reset_Handler doesn't do anything inside the CPU with respect to resetting things, NRST has to transition.

You'd call NVIC_SystemReset(); this will cause NRST to go low, and will reset anything in your system attached to it. It is important in ARM systems not to have anything driving the NRST pin high with a Push-Pull driver.I'm not sure why you need the second processor to get into the System Loader, I've gone over how to get into DFU mode here several times.

[Traud.Jason]

Posted on August 24, 2015 at 16:41

Clive, 

Revisiting this again, I changed up the timing on how this is working and I managed to expose something but I'm not entirely sure how to handle it. The way the timing works:!Reset is high and both BOOT0 and BOOT1 are lowBOOT0 goes high (both !Reset and BOOT1 are low)10ms passes!RESET drops (BOOT0 is still high, BOOT1 is held low)300ms passes!RESET goes high (BOOT0 is still high, BOOT1 is held low)300ms passesBOOT0 drops to 0 (!RESET is high, BOOT1 is held low)This would then put the device into DFU mode, and works for a large majority of devices, however, the occasional device pops up in device manager as being unrecognized. I could force a driver install to the STM Device in DFU mode that automatically installs with the other units. Have you seen something like this happen before?I was hoping that this would have been the solution since it would have made sense that the previous timing would have been too fast for the STM32 to have seen the status of the boot pins at the fourth clock cycle at reboot. With your comment about the second processor, is it possible to initiate DFU mode just in firmware? I'm using a second processor so that I can send a command down over USB to put it into DFU.