USART System Bootloader - Process and Protection Removal

[phil239955_stm1_stmicro_com]

Posted on September 07, 2012 at 13:47

I am trying to reprogram an STM32F407IG by using the USART interface as described in

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00264342.pdf

. I am able to establish comms to the device, and read the PID, but as soon as I try to remove the READ (or WRITE) protection, I lose comms to the device. This is my process as it stands: - Place device into reset and take BOOT0 high, then release from Reset- Establish Comms     Send 0x7F and wait for 0x79 response.- Read PID to confirm correct device     Send 0x02 0xFD and await for response.- Remove Readout Protection     Send 0x92 0x6D and wait for response (0x79 0x79)- Read PID to confirm comms     Send 0x02 0xFD and await for response. The final Reading of the PD always fails, and I'm not sure why. In AN3155 it states the following with regards to the Readout Protection command (and any others that affect the option bytes):At the end of the Readout Unprotect command, the bootloader transmits an ACK and generates a system Reset to take into account the new configuration of the option byte. This seems to indicate that after the final ACK (0x79) from the device, it will perform a system reset, however even allowing for this I am unable to regain comms. I have tried repeating the 'Establish Comms' routine (send 0x7F and wait for 0x79) incase the system reset means that the Bootloader needs to re-sync the comms, but that doesn't seem to work. Am I missing something here? How 'deep' does the 'System Reset' mentioned in the documentation go;    Does it just cause the bootloader to re-read the option bytes?   Do I need to be re-establishing comms again (with the 0x7F / 0x79 routine) after running it?   Should I be (externally) driving and releasing the 'Reset' line to the device after sending the command? Many thanks for any help or guidance that can be offered!

[emalund]

Posted on September 07, 2012 at 16:27

just for kicks, try this:

first run this - Place device into reset and take BOOT0 high, then release from Reset- Establish Comms     Send 0x7F and wait for 0x79 response.- Read PID to confirm correct device     Send 0x02 0xFD and await for response.- Remove Readout Protection     Send 0x92 0x6D and wait for response (0x79 0x79)- Read PID to confirm comms     Send 0x02 0xFD and await for response. ........... ........... after the crash/hangup then remove- Remove Readout Protection     Send 0x92 0x6D and wait for response (0x79 0x79) and run again Erik PS I laud you for a very well written post (everything documented, link to document ...)

[stforum.tormod9]

Posted on September 08, 2012 at 09:59

The ''system reset'' is a full reset of the whole chip, so you will have to reestablish all communications from scratch. Sending 0x7F should therefore work. Maybe you have to wait a tiny amount of time after sending the unprotect command so you can be sure the bootloader and USART is ready. And maybe you will have to reset the communication on the host side, for instance flush the serial port buffer or reopen it.

[phil239955_stm1_stmicro_com]

Posted on September 11, 2012 at 11:31

Erik,

As requested, firstly with the remove readout instruction:

- Establishing comms

7F 

79

- Read PID

02

FD

79 01 04 13 79

- Remove Readout, (double ACK as first ack's command, second indicates operation complete)

92 6D

79

79

- Read PID

02 FD

No Response from Bootloader

Then without the Readout protection removal:

- Establishing comms

7F

79

- Read PID

02 FD

79

01 04 13 79 

- Read PID

02 FD

79 01 04 13 79

So as expected, the comms locked when the readout was used, and ran free when the PID request was sent twice.

Tormod,

This is what happens if I try to re-establish comms by sending the 7F;

- Initial establishing of comms

7F

79

- Read PID

02 FD

79 01

04 13 79

- Remove Readout, (double ACK as first ack's command, second indicates operation complete)

92 6D

79

79

- Attempt to re-establish comms (after 1000ms wait)

7F

No Response from Bootloader   -------------------------------------------------------------- The only way I have been able to 're-establish' comms so far is to perform the following: - Initial establishing of comms 7F

79

- Read PID

02 FD

79 01 04 13 79

- Remove Readout, (double ACK as first ack's command, second indicates operation complete)

92 6D

79

79 

Take RESET line low, then release high again and wait for Bootloader to start....

- Re-establish Comms

7F

79

- Read PID

02 FD

79 01 04 13 79

As I have 'remote' control of the Boot0 and RESET lines having to perform this reset is no major inconvenience, it just seems like it is a step that should not be required according to the documentation...

[David Littell]

Posted on September 11, 2012 at 16:52

AN3155 Section 3.13 says: ''After the transmission of the ACK byte, the bootloader erases all the Flash memory sectors...''

This step may take some time.  Does anyone know how long it takes to erase all the Flash sectors?  Have you tried waiting a few of sips of coffee (something longer than the 1 second you mentioned) before sending the 0x7f to resync?  (Tormod's suggestion to send 0x7f is, I believe, definitely required based on AN3155.) (I noticed that AN3155's Figure 25 doesn't match the written description of the process in Section 3.13.  Looks like time for AN3155 Rev 3! 😉

[David Littell]

Posted on September 11, 2012 at 16:53

(Sorry, it looks like the forum double-clutched - I got an error page but it posted anyway.)

[phil239955_stm1_stmicro_com]

Posted on September 11, 2012 at 18:30

According to table 38 in

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/DM00037051.pdf

 if you are able to use 32bit access, then a mass erase can take up to 16 seconds. I wait for 'up to' 17 seconds for the erase to take place. The thing is the first 0x79 received after the 'Remove Readout' command is an ACK to the command, THEN you have the delay (of up to 16 seconds), THEN the second ACK is sent. As I am successfully receiving both of the ACK's I know my timeout value is sufficient, however I still can't re-establish comms after the second ACK, (irrelevant of any additional time I specify to wait after the second ACK. The

only

way I can do it at the moment is to action the RESET line to the device, and restart the bootloader that way.

[phil239955_stm1_stmicro_com]

Posted on September 14, 2012 at 16:40

Problem Solved.

As mentioned previously, I have a 'master' that drives the BOOT0 & RESET lines of the 'slave' (where the usart based bootloader is running), and obviously a serial link between them. To place the 'slave' into its Bootloader mode, (ie boot from System Flash), I drive the RESET line low to place the device in reset, then drive BOOT0 high, and then drive the RESET line high to allow the slave to start. What I hadn't realised was that as part of the 'System reset' that the slave performs whenever the option bytes are written to, it actually needs to be able to drive the reset signal on the RESET line, (I had initially thought that the RESET was an Input, not an Input-Output). As my 'master' was still driving the RESET line high, the slave was unable to drive it low, and hence the 'system reset' was not taking place. I have since changed my 'master' output pin from a push-pull configuration to be an open-drain, and now the system reset works as expected, just requiring the 0x7F to be sent after removeing the readout protection in order to 're-sync' the comms. Thanks to all who assisted.