2016-04-28 02:14 AM
Hello,
I have a system where a linux gateway is connected to multiple stm32F030R8Tx via UartLinux Gateway <---> STM32F030 <------> STM32F030 .....Is it possible to upgrade the firmware of stm32F030R8Tx on the field?Can you please guide me to a relevant documentation?thanks a lot for your helprifo #firmware-update2016-04-28 04:51 AM
It should certainly be possible, if they share a common firmware image that would make thing simpler.
I don't think the System Loader will be of much help, you'd probably want to look at the IAP (In App Programming) examples and documentation, and generally get familiar with writing boot loaders, and suitable data transfer protocols.2016-04-28 06:54 AM
Hello Clive,
Thanks a lot for your answer. Now that I know it's possibleI'll dig into the documentation for more info.One more thing I would like to ask isDo you think that adding an external spi flash wouldmake life easier for me? or can I just go with theinternal flash?Also, about the bootloader, what kind of development shouldI be making Clive? I have thought about storing the firmwarein an internal (or external) flash and then sending a commandto boot from a particular address, aren't there anybootloaders capable of doing this?thanksrifo2016-04-28 11:46 AM
Staging the firmware can help in situations where you can't control the flow and writing of Flash. Generally I prefer not to have to erase my loaders, and I separate the app from the loader, so the update procedure is robust, and I don't brick my devices. I generally stage to SD cards, or unused sections of Flash, where that is required. SPI, NOR or NAND devices would also work. I also X-Modem and write-in-place where that is viable, I don't think one method is significantly more complicated than the other.
If one part in the chain has updated firmware it can just copy itself to the next, your diagram isn't particularly clear but I'm presuming a daisy-chaining of one serial to the next.The STM32 IAP examples are just one, other than the express flash erase/writing the concepts involved here are applicable to many architectures, and no doubt other examples exist. Boot loaders tend to be designed to perform specific jobs for specific application, developers create what they needs, and the bulk are likely to be closed source and beyond the handful of engineers that wrote them perhaps not seen by anyone else.Yes you can move code around, jump to other areas of RAM, ROM or FLASH, the processor is quite flexible in that regard.2016-07-15 08:13 AM
Hello Clive,
I have just found the chance to start working on this topic. I was going through the documentation, namely AN4657, ''in application programming using usart''. I will follow the strategy that you've suggested and will have a 2 stage application. I have set my plan like below1) Modify the parts of the code, writing to flash so that they are compatible with the new HAL layer 2) Write an initial stage program where a certain address is read and depending on the value, new or existing code is executed.I'll report about the outcome and share the code if I have it working fine.2016-07-21 03:37 AM
Hello,
We have successfully tried AN4657, STM32 ''in-application programming (IAP) using the USART'' for STM32F103.Now we would like to modify it for our processor, stm32F030R8Tx and use HAL drivers. We have found '''' but there are 2 things we don't understandFor remapping the vector tables, we can't find the HAL driver counterparts of the below function and definition. Can you please guide us for finding it.NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x3000);
#define VECT_TAB_OFFSET 0x0
thanksrifops: one more thing is, when we compile the project for Xcube IAP, we got a compile error. We didn't do any changes, can you also please guide us for what we did wrong?