TMS570LS1224: CAN Bootloader application: problem moving application flash code to RAM

Hi Geert Jacobs,

Geert Jacobs said:

When the application code is all running from flash, the application works but accessing the Firmware status field crashes the application.

I think, reading the firmware status field should not crash the application. Either trying to erase it or writing will crash the application. What exactly you are trying to do here, what do you mean by accessing?

Geert Jacobs said:

So from other forum posts I understand I need to move the flash driver to RAM.

[FAQ] TMS570LC4357: Examples and Demos available for Hercules Controllers (E.g. TMS570x, RM57x and RM46x etc) - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Can refer below highlighted example from above FAQ.

This controller also had only single bank, so in this example i am copying the FAPI library into the RAM and doing erase and writing to the same bank from RAM.

--
Thanks & regards,
Jagadish.

Reading works fine with image running from flash

Writing in the same way as the bootloader crashes the application.

From similar forum posts I understand that the flash driver code needs to be moved to RAM.
I am trying that, but my image does not seem to start after upgrading. The XL2-TMS570 board show a red led after upgrade.

Geert Jacobs said:

Writing in the same way as the bootloader crashes the application.

Yes, writing will crash the application. Because this device has single bank right, so if you are trying to do code execute and write on the same bank the application will get crash.

So, you should need to execute the flash library from the RAM. Please refer the example i given.

Hello,

I ported the RM46 example to TMS570 and added some led blink to indicate that the application doesn't hang.
If  I run the example from address 0 (no bootloader present), it works.
If I run the example from address 0 with ECC settings in sys_link.cmd file, it works.
However if I change the application location to work from address 10020 in sys_link.cmd in order to work with bootloader, it does not start after upgrading with bootloader. Same issue as with my application.

Hi,

Geert Jacobs said:

However if I change the application location to work from address 10020 in sys_link.cmd in order to work with bootloader, it does not start after upgrading with bootloader. Same issue as with my application.

Make sure your bootloader properly calling the application.

You can debug the code in one way.

1. First program the bootloader code to the flash. Make sure you enabled the below highlighted line, this will be helpful to call the application without verifying the singature.

2. Now debug the application project, make sure that application program set to the "Necessary sectors only". For bootloader you can keep the "Entire Flash"

3. After going into the debug mode, now you can do the reset from application code and can verify whether the application is executing properly or not.

--
Thanks & regards,
Jagadish.

Hello,

- Programmed the modified bootloader using the debugger. 

- Rebuilt the TMS570 application in debug config, loaded Necessary sectors only: the application runs in debugging mode (led blink)

- Unplug the USB (power supply) to the XL2-TMS570 board and replug. (No debugging present.)
Expectation is that modified bootloader starts and calls application. No led blink, so application does not seem to start.

Tried this with and without ECC settings in sys_link.cmd file of application. Both versions do not seem to start.

Another observation: when I remove the flash copy to ram from the application and comment out the flash tests, run it in debug, it works.
When I then unplug the usb, it also works! The led does blink in an application without the copy to RAM.

Hi Geert Jacobs,

The problem is that i don't have TMS570LS1224 board with me, so it is difficult to debug and find out the issue with this information.

If you are okay, we can setup one live debugging session tomorrow. There you can share your screen and explain to me the behavior, and i can provide my suggestions.

I will be available from 10AM to 7PM IST (Indian Standard Time). So please schedule a meeting in this time.

--
Thanks & regards,
Jagadish.

Hi Geert Jacobs,

Thanks for creating meeting on tomorrow at 2PM IST. I will join to the meeting.

--

Thanks & Regards,
Jagadish.

Hi Jacobs,

Give me 15 minutes time looks like some audio issue was there.

--
Thanks & regards,
Jagadish.

Hi Jacobs,

I understood the root cause for the issue!

The problem is here:

In your application you are trying to erase and write at the address 0x10000 right?

I hope you already knew that minimum erase granularity for Hercules devices is sector. 

So, if you are trying to erase 0x00010000 this address means the entire sector will get erase, that means the data in the 0x10000 to 0x13FFF will get erased.

But if you verify your application code, we have stored our vectors at 0x10020 and our code at from 0x10040, so part of our code and vector table will also get erased.

For the first time you don't face any issue because, we didn't do erase and also, we are executing our code from RAM. But after reset, we should only read from flash, but flash already erased. That is the reason we are facing issue.

The solution is that it would be better to avoid the sectors where our application stored for additional data writing. Instead of you can use the sectors after the application stored. 

You can find out this by using your map file of the application.

Here my application was stored till the address 0x10040+0x7D0C that is 0x17D4C.

This address will be in the sector 5 of the flash. So, it would be better to use sector-6 that is from address 0x180000.

These screenshots are for RM46, so please verify for TMS570LS1224.

--
Thanks & regards,
Jagadish.

Hi Jacobs,

If you really want to write at the same address then don't erase the entire sector, instead of just write directly the data you want to write.

I am suggesting this because, i am assuming bootloader will erase this sector before programming the application.

And also, i don't understand why you are doing this write from application. Actually, in our CAN bootloader project this area is written by bootloader only and this area indicates whether valid application present or not. So, first CAN bootloader erases the flash(from the area after bootloader) and then bootloader writes application into the erased flash, if it successfully writes the application into the flash then at the end bootloader writes a signature into the 0x10000 address to indicate valid application.

--
Thanks & regards,
Jagadish.

The intention is to have the firmware upgrade triggered from software.
Therefore the application will erase/rewrite an invalid value in the Application Status at a certain location, shared by bootloader and application. After that the application will reset the device.
The TI CAN bootloader demo code placed this Application Status at address 0x10000, so I used that.

I have just tested with your suggested value of 0x18000 for this particular test case as Application status location and that does indeed seem to work better. 
Still need to test with bootloader only.
Thank you for your assistance.

Geert Jacobs said:

The intention is to have the firmware upgrade triggered from software.
Therefore the application will erase/rewrite an invalid value in the Application Status at a certain location, shared by bootloader and application.

That makes sense!

Geert Jacobs said:

I have just tested with your suggested value of 0x18000 for this particular test case as Application status location and that does indeed seem to work better. 
Still need to test with bootloader only.

Okay Jacobs.

I have been trying to move my application away from the flash sector of the app status (0x10000) to try and confirm your theory.
So I had to adapt the application address in three locations:

- The PC FW upgrade application sends the App Start address while programming
- The bootloader takes in the programming address but also has a hard coded App Start Address
- The test application needs to have its sys_link.cmd updated.

So I changed all these App Start locations to 0x20000.
This is outside the flash sector of the App Status (0x10000).

1. Test application without RAM copy of code and Without flash write/erase, just led blink: firmware upgrade works, application starts at 0x20000

2. Test application with RAM copy and only flash init (no read/write) + led blink: firmware upgrade works but application does not start ( no led blink).

So for now, I still cannot get an app with flash code copy to RAM working.

At this point I probably need to consider the FEE option.

Hi Jocobs,

Let me try same on my RM46 board,

I will try to provide my updates by Monday.

--
Thanks & Regards,
Jagadish.

Using the Flash Emulating EEPROM I now have a bootloader and application that can erase the Application Status field. This seems to be a more convenient way than writing an application status straight to Flash somewhere.