IAP USART Questions

[andyolivares]

Posted on July 02, 2014 at 08:24

Hi everyone:

I've been playing with ''STM32F4xx_AN3965_V1.0.0'' which is IAP over USART with my STM32F4Discovery board. I managed to port all the relevant code to work with this board and it's running quite fine. The bootloader is downloading .BIN files using the YModem protocol, writing them into FLASH memory and booting to the user code afterwards, so everything fine here. One of my tests consisted in create a binary file of 1032192 bytes which is the full programable FLASH space that we can program as user code according to the IAP application that saves the first 0x4000 bytes for the bootloader itself (0x8004000-0x80FFFFFF). The test file started with a 0x55 byte followed by 0xAA bytes and ending with a 0x55 byte again. I did this to easily identify the start/end of the file and its contents. So, I programmed the FLASH using the IAP application and using the prevously created test file and after a while, it was programmed fine (according to the application). After that, I opened up STLinkV2 flash utility to check if the file was programmed as expected and it mostly did except for the last 4 bytes (read as 0xFFFFFFFF). In other words, I found the first 0x55 byte at address 0x8004000, followed by a lot of 0xAA bytes, but I didn't find the last 0x55 byte. Debugged the code trying to find out what went wrong, and after a couple of debugging sessions I found the following line in file ''flash_if.c'' (line 93): for (i = 0; (i < DataLength) && (*FlashAddress <= (USER_FLASH_END_ADDRESS-4)); i++) Please note the text in bold. As I understand, it programs all flash except all 4 last bytes of it. I really don't understand why it is made the way it is. I removed the ''-4'' and retried the programming process, and this time all bytes where programmed fine and I was able to see the last 0x55 byte at the end of the flash memory space, which seems to be the correct behaviour for me.So, is there anything I should worry about having removed the ''-4'' from that line of code? Is there any special purpose for the last 4 bytes of flash? Am I missing something here? Does anybody know why the ''-4'' on that line of code? Thank you so much for your answers. Andy #iap-usart-uart-stm32f4discovery

[Tesla DeLorean]

Posted on July 02, 2014 at 13:47

Probably coded with the expectation of adding a CRC32 or check sum to the back end of the image so the boot loader could validate it.

[andyolivares]

Posted on July 02, 2014 at 16:36

But as far as I can see, there is no reference to such CRC32 checksum, so I assume it is safe to remove the ''-4'' part of that line of code.

Thank you!

[Tesla DeLorean]

Posted on July 02, 2014 at 21:39

Indeed, but the code is fairly generic and used by several ST examples. It's not a particularly robust example, and any sensible update process would allow the boot loader to validate the entire application image was written correctly before blindly jumping in to it.

[andyolivares]

Posted on July 04, 2014 at 05:53

Thank you so much for your answers.

According to your experience, what would it be the best way to do the CRC32 checksum stuff? The IAP sample is intended to be used with HyperTerminal using Ymodem protocol, so I think there's no CRC32 calculation on that end. I suppose I should calculate a checksum as long as the packages arrieve to the microcontroller and then write the checksum to the last 4 bytes of flash memory at the end of the download process. Does that sound right? And the other question would be: how to actually check this stored CRC32 value? Should I calculate a CRC32 checksum of the entire flash memory space and compare to the stored value evey time the IAP application wants to actually boot the user code? Wouldn't that be a little bit slow? Thank you again 🙂