2015-11-13 05:43 PM
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: 0x7FReceive: 0x79Try to write 8 bytes to address 0x08000000
Send: 0x31Receive: 0x79Send: 0x08 0x00 0x00 0x00 0x08Receive: 0x79Send: 0x07 0x00 0x00 0x02 0x20 0xF1 0x5A 0x01 0x08 0x87Receive: 0x79Try to read 8 bytes at address 0x08000000
Send: 0x11Receive: 0x79Send: 0x08 0x00 0x00 0x00 0x08Receive: 0x79Send: 0x07 Receive: 0x79 0x00 0x00 0x02 0x20 0x31 0x5A 0x01 0x08So 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: 0x31Receive: 0x79Send: 0x08 0x00 0x00 0x00 0x08Receive: 0x79Send: 0x07 0x00 0x00 0x02 0x20 0xF1 0x5A 0x01 0x08 0x87Receive: 0x79Try to read 8 bytes at address 0x08000000
Send: 0x11Receive: 0x79Send: 0x08 0x00 0x00 0x00 0x08Receive: 0x79Send: 0x07 Receive: 0x79 0x00 0x00 0x02 0x20 0xF1 0x5A 0x01 0x08So 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 #bootloader2015-11-13 06:06 PM
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.2015-11-16 09:06 AM
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.
2015-11-16 09:39 AM
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.2015-11-16 10:14 AM
Hi clive,
Thanks for your help. When I send the GET command, I receive0x79 0x0B 0x31 0x00 0x01 0x02 0x11 0x21 0x31 0x44 0x63 0x73 0x82 0x92 0x79Based 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: 0x44Receive: 0x79Send: 0xFF 0xFF 0x00Receive: nothingI 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.2015-11-16 10:31 AM
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.