Firmware Upgrade Issue

[Mujeeb Shaik]

Posted on April 24, 2017 at 07:48

Hi ,

I am using SP560B-Discovery board,

I am trying to do firmware upgrade,

From UART i will be getting the hex file data as a character buffer,once it receives i will be converting to integer using atoi() call,then i am writing into flash,before writing i am checking for CRC as well for integrity check,this logic will be in my bootloader,once writing into flash completes,my application is (whatever updated using bootloader code) is not working ,whether atoi() conversion is required or not ?

In addition to that,my boot loader is .elf file but main application file is .hex file is this the reason why it is not working?

kindly provide your valuable suggestions,

---

Thanks & Regards,

Mujeeb.

[zambrano.luigi]

Posted on April 24, 2017 at 15:08

Hi Mujeeb,

please, let me suggest you to use the binary file instead of the hex file. No conversions are needed with the binary file.

In attachment you can find a simple example that could help you to solve your issue. The example is composed by 2 different projects for SPC5Studio rev5.3:

1.SPC560Bxx_RLA PIT Test Application for Discovery is a simple application that toggles the LED7 and LED8. This applications has been developed to be executed from the first flash block (0x0). In the archive file I have also included the binary file (out.bin, 9744byte) related to this application. Suppose that this application is the firmware application that you want update.

2.SPC560Bxx_RLA Flash Test Application for Discovery is a simple flasher application that uses the SPC5Studio serial driver to read a binary from the serial and the SPC5Studio flash driver in order to program the binary file in the core flash starting from the first block (0x0). This test applications is developed to be executed from RAM.

In order to run this example, please, make the following steps:

a. Import the flasher application in SPC5Studio, compile it e load in the RAM of your

SPC560B Discovery board.

b. Open on your PC a serial terminal (I have used TeraTerm) and set the baud rate of the COM port to 38

c. Run the flasher application. When the LED7 is lighted on your

SPC560B Discovery board

, sendthe file out.binover serial (in TeraTerm File -> Send file ...). The flasher application will program the file out.bin in the flash memory of your

SPC560B Discovery board.

When the programming is finished, the LED8 will light.

Now, if you remove and then re-insert the supply on your

SPC560B Discovery board

,

, you should see the LED7 and LED8 toggle (in other words,the firmware application has been programmed in the flash and is executed on the board reboot).

Best regards,

Luigi

________________ Attachments : firmware_update.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyHO&d=%2Fa%2F0X0000000bBC%2FV3jhv9S7xbRCQLEHHVUoEXEetWL1D1szjJVE_UF5rvg&asPdf=false

[Mujeeb Shaik]

Posted on April 24, 2017 at 15:51

Hi 

Luigi,

Thanks for your quick reply,

I will try the code whatever provided by you,Can you please clear one more doubt, as i said i am writing into flash from my bootloader application,my bootloader is .elf and application is .hex is there any issue with this?,i would like to understand is there any conflict with this.

---

Thanks & Regards,

Mujeeb.

[zambrano.luigi]

Posted on April 24, 2017 at 16:34

Hi Mujeeb,

I think the hex file is a little bit more complicated to use than the binary file because the hex file is a sort of memory dump in ascii format that contains in addition to the bytes to be programmed also the addresses in which to program the bytes. So you should analyze in your code the hex file, skip the address and program the byte to the correct addresses. The binary file, instead, contains only the bytes to be progrmmed. So, you can read and program the single bytes in a easy way.

Regards,

Luigi

[Tesla DeLorean]

Posted on April 24, 2017 at 17:09

Both file formats encapsulate the data written to memory in different ways, however the bytes written to flash are the same.

You should perhaps get a better appreciation of the file formats by reviewing the relevant documentation. The .HEX files are simple, using a form readily processed in assembler by the 8-bit micros of the 1970-1980's. The .ELF files are significantly more complex.

I would probably avoid sending .HEX files to the loader, using binary files and X-MODEM is far more robust.

[Santhamurthy R]

Posted on April 24, 2017 at 17:35

Hi,

I am clear with your above suggestions.

Let me explain the similar kind of issue I am facing. I have two applications 1.Bootloader 2. Main Application. The execution starts from bootloader later it jumps to the main application.

For upgrading the firmware I am following the below procedure:

   As I am using UDE tool to load and debug the code since I am unable to load .bin file successfully. Hence I am loading .elf files initially. Later at some instant I am trying to send the upgraded version of Main application (.bin) file through UART which is received by the Bootloader application. The Bootloader receives the .bin file through UART and writes into the flash memory from specific address location from where the main application begins. After successfully write the complete .bin file of main application into the flash, I am restarting the setup. Now the bootloader begins normally and jumps to the main application.

   Since the bootloader is loaded as .elf format initially, later while upgrading the firmware .bin file(only main application) is loaded into the flash. I suspect that, since the bootloader and main application both differs in the format post upgrade, does it creates any problem due to which working of main application fails?. Is is necessary to have both the files in same format?

   kindly share your valuable suggestion and help in getting the problem resolved.

Thanks in Advance,

Regards,

R.Santhamurthy

[Tesla DeLorean]

Posted on April 24, 2017 at 17:44

The processor executes binary instructions, it doesn't understand .HEX or .ELF files, these are higher level encapsulations of the data generated by the tools (ie compiler / linker).

The goal is to write the instructions into flash, and discard any/all nefarious packaging you might have around it.

[Santhamurthy R]

Posted on April 26, 2017 at 17:21

Hi,

Thanks for your reply,

My bootloader and application working fine while loading with UDE. 0x00000000 to 0x00010000 is allocated for bootloader and the application starts from 0x00010000 which is getting branched from the bootloader.

The problem I am facing here is, I am trying to upgrade the main application which is starting from 0x00010000. The firmware upgrade follows the bellow procedure.

Once the board comes up the bootloader application starts executing. Inside my booloader I am waiting for 5sec to check for firmware upgrade request. If the sw2 is pressed within 5 sec the firware upgrade starts. I have the PC application which reads and sends the out.bin(out.bin of working main application) through UART.(128 bytes/TX). Bootloader receives the data through UART and starts writing from the location 0x00010000 of C-Flash. I can able to write successfully into the Flash. After completing the upgrade process I restart the Hardware. I observed that the bootloader is getting executed but the control is not getting branched to main application which was working while initially loading using UDE.

I am attaching bootloader and main application for your reference. Kindly review and provide your valuable suggestion for resolving the issue.

(FYI my applications are generated and compiled using SPCstudio 5.2.3 version. Initially .elf of both bootloader and main application are loaded using UDE 4.2).

Thanks in advance

With Regards,

R.Santhamurthy

________________ Attachments : Firmware_Upgrade_SPC560B.rar : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyds&d=%2Fa%2F0X0000000bB1%2FQmwBPIzaRy.1BGZ9LitFEqcXMSsBqSa5zhVCpqU_Z5o&asPdf=false

[Tesla DeLorean]

Posted on April 26, 2017 at 18:34

I don't have the time/resources to wade into your code.

If it works out of the UDE then you need to look at what's different in memory when it uses the boot-loader, and that is not the debugger that is changing the execution address. I'd suggest instrumenting the boot-loader so you understand what is is seeing in memory, and whether it is transferring control.

[zambrano.luigi]

Posted on May 08, 2017 at 09:35

Hi

R.Santhamurthy

sorry for the delay.

Let me underline that the Bolero B flash memory doesn't support the Single Bank Read While Write as specified in the Reference Manual (paragraph4.2.1 CFlash module sectorization):

The module is composed of a single bank (Bank 0): Read-While-Write is not supported.

This means that it is not possible to execute from flash a boot loader that programs a new main application in another Sector of the same Bank. The only way to make an update is to execute the update procedure from the RAM.

In attachment you can find an example of this procedure developed for the last release of SPC5Studio (5.3).

The boot loader application (SPC560Bxx_RLA Flash Test Application for Discovery) is configured with the Boot Mode option on Copy in RAM. This means that the code of the boot loader is stored in flash starting from address 0x0, but it is relocated in RAM when its execution starting.

The main application (SPC560Bxx_RLA PIT Test Application for Discovery) is designed to be executed from the flash starting from the address 0x10000.

The first step of the boot loader is the execution of a count down of 5 seconds. At the end of the count down the boot loader jump to 0x10000. If before the end of count down the user pushes the button SW2, the update of the main application will be started. In that case, the binary image of the new main application has to be provided via serial (please, for more details read the file readme.txt of the boot loader).

Please, note:

1. In the provided boot loader example the macroBIN_SIZE has to be set with the size of the binary file of the new main application that you want to update. In the zip file you can find also the binary file out.bin (obtained from the compilation of the application SPC560Bxx_RLA PIT Test Application for Discovery) that I have used for the example.

2. Before to jump to the main application, it is necessaryto stop all the peripherals used in the boot loader (in the example, the serial and PIT). \

3. In order to enable the update through the button SW2, please, connect the pin X4[10] with the pin X1[31]. In this way the button SW2 will be connect to theEIRQ So, when the button is pushed, theEIRQ17 callback (that startsthe update procedure) will be executed.

Regards,

Luigi

________________ Attachments : Boot Loader.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HygM&d=%2Fa%2F0X0000000bAt%2FRr7Laj45GOYrAbT8zz51Aa3mQ2Bb40YIk3lEMCi0KeE&asPdf=false