2014-03-19 08:17 AM
Hi All,
I would like to get started on firmware upgrade process. I have a following questions on the same. 1) My target board (STM32F427) has 1MB of flash, and 256 KB of external ram. At present, we run program from flash (we selected the option while creating a project using GreenHill tools). The image size on STM32F427 is around 700KB. I would like to upgrade the STM32F427 software using RS232 as well as using USB. What are the things I will have to worry about? Do I must have bootloader? and Do I need to modify the bootloader and implement the flash_erase/flash_write utilities in the same? Do I need to worry about any other things which I might have missed? Is there any document that would provide me insight to this? I think this must be pretty standard procedure since most of you are using the STM32 for a while. #firmware-update #boot-loader2014-03-19 09:21 AM
Hi
''Do I must have bootloader? '' No, The STM32F4xx has a built in bootloader and can be access using the 'DFU' processess. This built in DFU bootloader can work over UART, USB ,I2C etc. This link is about the UART http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF258152 I could not (easily) find the Bootloader DFU page?!? You need to reserve the 'BOOT0' pin in order to use this. ''Do I need to modify the bootloader and implement the flash_erase/flash_write utilities in the same?'' OR you can develop a bootloader of your own. Yes, you will have to develop (or use the existing Standard Peripheral Library) code to erase and program the Flash. ''What are the things I will have to worry about?'' ''Do I need to worry about any other things which I might have missed? '' Security - both in term of other people reading out your binary and reverse engineering your code and other people loading their own binary into you board. These 2 reasons drive many to develop their own proprietary bootloader.2014-03-19 10:21 AM
Is there any document that would provide me insight to this? I think this must be pretty standard procedure since most of you are using the STM32 for a while.
It's a pretty fundamental embedded concept, don't confuse the specifics of the STM32 with the process in general.http://shop.oreilly.com/product/0636920017776.do
ST has several IAP (In Application Programming) examples and documents.The System Loader on ROM has some other specific requirements, expressed in it's documentation, for the F4 you'd want access to USART1, USART3, or USB and BOOT0 pin. There is example software, with source, for programming the part, but if you want to control the experience you'll likely need to code your own software on each end.http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/CD00171488.pdf
2014-03-20 11:24 AM
Hi Clive,
Thanks for the response. I downloaded the flash loader tool v 2.36 from ST. I can connect to the target, however I don't see any device type I ignored it and went ahead but, it doesn't either let me erase/ program the flash. when I attempt to erase it says the device is read protected. If I try to wrie .srec (s19 or hex file) it says ''unable to load data from this file ..'' Any suggestions? Also, one more thing, my target is connected to other processor which is connected over serial to the STM32F4 We are planning to upgrade the firmware of those two processor as well. we don't have large enough flash or RAM on STM32F427 where I can temporarily store the files received from a user PC which needs to be flashed on the other two processor(s). How do I deal with those image update? Shall I create a circular buffer in STM32F427 application, where I will store the bytes received from a user PC using XON/Xoff which is equal to 1 flash block size and erase/write 1flash block? Do you think this is the right approach? or do you recommend a better solution for the same? Regards Poshtiw2014-03-20 12:04 PM
If you don't have anywhere to stage the firmware (NAND, SD Card, etc), one of the most effective/prolific solutions is to use XMODEM or XMODEM-1K. It's a fantastically robust solution, self pacing, supported by many terminal apps, simple to code. It's used by a lot of SoC designs. I would recommend that boot-loaders checksum the application firmware and confirm it's integrity before jumping into it.
2014-03-20 01:41 PM
Hi Clive,
Thanks for the quick reply. I read quickly about the X-ModeM 1k. It would work, if I have some application on the STM32F427 which understands the XModem protocol. I think I will have to write/compile Xmodem code for STM32F427 (Let me know if there is a sample code which I can use or any link describing the implementation ) and invoke it when a user decides to update a firmware image. Once the transfer is started using XModem 1K the STM32F427will receive 1024 bytes at which point it will stop/pause the sender (PC side) and at a same time, I will have to erase/program/write 1024 bytes of data to the respective flash? Please correct me If I misinterpreted this. Regards Poshtiw2014-03-20 02:00 PM
When you erase the app space really is a strategic decision. You could do it all at once, or a block/page at a time.
The way the protocol works is that you'd get your 1KB, perform the CRC, if that fails send a NACK immediately, if it is valid hold off sending the ACK until after you have written to flash, this paces things at the rate you can write to memory. After you send the ACK the host will immediately send the next block.I've written my own implementations, the ST YMODEM implementation in the IAP demo is a close example, though there are many others.2014-10-21 07:09 AM
2014-10-21 09:23 AM
Do you have any bootloader examples, I have a requirement to copy bootrom and appilication from flash to RAM. How do I jump from flash location to RAM say I have placed bootrom @ 0x08000000 and application @ 0x081C0000, copy application to RAM @ 0x20000000 through bootloader. All I want is to jump, how do I jump. Updating program counter will do that or need to change any target settings in KEIL. I was trying to update with SCB->VCTR but didn't jump. Could you give me some suggestions.
Is this for a commercial venture? In Keil you'd have to compile and link your application to work at the RAM address you want it to end up at. You'd need to make sure your IROM and IRAM memory don't step on each other. Your boot loader would also need to not step on the 0x20000000..0x2000xxxx memory you expect you code to reside at. You'd memcpy() the application data into, and jump to it. Your code in SystemInit() of the application would want to set the SCB->VTOR to the 0x20000000 address the code is residing in.
Reboot_RAM PROC
EXPORT Reboot_RAM
LDR R0, =0x20000000 ; RAM Base
LDR SP,[R0, #0]
LDR R0,[R0, #4]
BX R0
ENDP
You seem to be keep asking the same basic question over-and-over without a clear understanding of the architecture and tools you're attempting to use.
2014-10-22 12:56 AM
Its a medical device, since duration is too short unable to look in assembly basics. Few examples from KEIL I have looked in for blinky which compiled for RAM, where target settings for IROM1 and IRAM1 are fixed for 0x20000000. Moreover already the medical product has customed code for moving the Application data from flash to RAM and jump to RAM location this is developed in GHS, but when adapted for KEIL getting hard fault error. I need to retain the custom code which copies from FLASH to RAM, only sequence missing is jumping to RAM. Need to bridge C and assembly