STM32F4 USART Programming

[bcornwellmott]

Posted on November 14, 2015 at 02:43

I am trying to program the STM32F4 Discovery board through the UART and am having a very perplexing problem. 

I am getting into the bootloader through my program code, following the same method as the ST video that demonstrates how to do this. I can successfully get into the bootloader section and run GET (0x00), Get Version (0x01), Get ID (0x02), and Go (0x21) commands. 

For the most part, I can also use the Read (0x11) and Write (0x31) commands. However, while attempting to re-program the microcontroller, I am running into an issue where a specific chunk of data is not writing correctly. I have a short example below:

Get into the Bootloader

Send: 0x7F

Receive: 0x79

Try to write 8 bytes to address 0x08000000

Send: 0x31

Receive: 0x79

Send: 0x08 0x00 0x00 0x00 0x08

Receive: 0x79

Send: 0x07 0x00 0x00 0x02 0x20 0xF1 0x5A 0x01 0x08 0x87

Receive: 0x79

Try to read 8 bytes at address 0x08000000

Send: 0x11

Receive: 0x79

Send: 0x08 0x00 0x00 0x00 0x08

Receive: 0x79

Send: 0x07 

Receive: 0x79 0x00 0x00 0x02 0x20 0x31 0x5A 0x01 0x08

So one of the bytes did not get write correctly. If I immediately repeat the same code and try to rewrite the memory at the same location (to fix the error), I get the following output:

Try to write 8 bytes to address 0x08000000

Send: 0x31

Receive: 0x79

Send: 0x08 0x00 0x00 0x00 0x08

Receive: 0x79

Send: 0x07 0x00 0x00 0x02 0x20 0xF1 0x5A 0x01 0x08 0x87

Receive: 0x79

Try to read 8 bytes at address 0x08000000

Send: 0x11

Receive: 0x79

Send: 0x08 0x00 0x00 0x00 0x08

Receive: 0x79

Send: 0x07 

Receive: 0x79 0x00 0x00 0x02 0x20 0xF1 0x5A 0x01 0x08

So it appears that the device memory was correctly written this time. However, when I later use ST-LINK to read my program memory, the value of that byte is not 0xF1, but the original read value of 0x31.

I cannot for the life of me figure out why the read command is reporting an incorrect value. 

If anyone has any suggestions, I'm very grateful...

#uart #stm32 #bootloader

[Tesla DeLorean]

Posted on November 14, 2015 at 03:06

USART1 via PA9/PA10 is NOT usable on the STM32F4-DISCO because of a large capacitor on PA9 (review the schematic)

It might be workable at 1200 8E1, but I wouldn't trust it.

[bcornwellmott]

Posted on November 16, 2015 at 18:06

I am using USART 3 through pins PB10/PB11. Furthermore, I am able to communicate with the bootloader (receive data, write data) for the most part.

[Tesla DeLorean]

Posted on November 16, 2015 at 18:39

Do you erase the memory at any point? I'm pretty sure over-writing is not a workable strategy.

What version of the boot loader is on the device?

Can you replicate this behaviour every time?

Is this done using USB-to-Serial adapters, or a motherboard base serial port?

Can you write a significantly larger block of data, which spans a flash line? Trying to rule out any prefetch/caching issues.

[bcornwellmott]

Posted on November 16, 2015 at 19:14

Hi clive,

Thanks for your help. 

When I send the GET command, I receive

0x79 0x0B 0x31 0x00 0x01 0x02 0x11 0x21 0x31 0x44 0x63 0x73 0x82 0x92 0x79

Based on that, my bootloader version seems to be 3.1, and I have access to the extended memory erase command. However, I haven't been successful in running that command:

Send: 0x44

Receive: 0x79

Send: 0xFF 0xFF 0x00

Receive: nothing

I have tried writing other bytes afterwards but it seems that I don't get any response from the bootloader after I receive the one ACK byte.

I am using an FTDI chip for the serial communication (USB to serial).

The issue occurs consistently and on the same memory addresses. I tried writing 0x00 to each byte and that seems to work without any issues, but as soon as I try to change that to my actual program, it gives me the same behaviour (first time fails to write, second time reports back the target values but doesn't actually change).

I have tried chunk sizes from 4 to 256 and I don't seem to get a different response depending on the chunk size.

I didn't know that an erase needs to be performed before writing to the memory. If I could get the erase working that may be the solution... 

EDIT: I figured out why the erase wasn't working. I was sending compliments to each byte by accident. I'm going to see if erasing first fixes it. I will post back when I check it.

[bcornwellmott]

Posted on November 16, 2015 at 19:31

That seems to have worked. Thank you Clive!

I needed to run an erase command on the memory before writing to it. I didn't notice that in any of the documentation, but I guess it makes sense.