RTOS/TMDXIDK5718: Issues when reloading program in CCS

Markus Mueller

Part Number: TMDXIDK5718
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

I'm using SYSBIOS V6.46.5.55 for my Cortex A15 program on IDK5718.

I'm having difficulties in restarting and/or reloading my program.
To be sure that the problem is not within my program I tried I TI example project
(clock_IDK_AM571X_CortexA, from CCS 7.3 Resource Explorer Classic)

When I have everything shut down (power off on IDK board, CCS disconnected) I do this:

- Launch Target configuration
- Connect to Target
- Load the program

The debugger halts on main() and running the program is fine.

When I pause the program and reload the program (without modification).
I halts on main, but then it crashes. After inserting some debug code I could see that
the SYSBIOS function Clock_create returns with a NULL-Pointer and the error block
message says: "out of memory".

It seems that reloading the program does not reset everything to default values.

As said above I have similar problems with my own application where the program crashes after a reload.
But before I continue there I want to be able to reload an even simpler program like the clock example.

How do I properly reload or restart a Cortex A15 SYSBIOS application?

Regards,
Markus

over 6 years ago

0 Biser Gatchev-XID over 6 years ago

TI__Guru**** 393215 points

The RTOS team have been notified. They will respond here.

0 lding over 6 years ago in reply to Biser Gatchev-XID

TI__Guru* 95265 points

Hi,

The usual way we do this is to disconnect the A15 core, do a system reset from CCS, then re-connect the core, reload the program. If you do the program restart, you need to make sure the program clean up the resource before exit.

Regards, Eric

0 Chester Gillon over 6 years ago

Guru 92251 points

Markus Mueller said:
How do I properly reload or restart a Cortex A15 SYSBIOSapplication?

The SYS/BIOS start-up code for a Cortex-A15 attempts to invalidate the cache. However, on the Cortex-A15 the cache invalidate instruction actually performs a cache clean which can corrupt the downloaded program if there is any data in the cache from a previous run.

A hard reset will clear the cache before attempting to download another program with CCS. Debugging Cortex A15 defines an alternate procedure to apply a System Reset from CCS, rather than have to press the hard reset button.

[See Does the ARM Cortex-A15 treat the invalidate instruction as a clean/invalidate instruction due to a design decision or due to an errata? for some background information]

In https://e2e.ti.com/support/arm/sitara_arm/f/791/p/550429/2015078#2015078 I attached some modified GEL scripts to try and work-around the cache clean problem when reloading a program from CCS. The modified GEL scripts were tested in CCS 6.2, and I haven't yet re-checked if still works in CCS 7.3

0 Markus Mueller over 6 years ago in reply to Chester Gillon

Expert 1370 points

Hi Chester

Thank you for this relpy. Now I can understand what happend.

Instead of loading the program a second time (which also can take some time, depending on application size) would it be possible to do a cache clean/invalidate by e.g. a gel file prior to loading/reloading the application? (may be manually executed)

As I'm not familiar with gel file programming, how could this be done (if at all)?

Regards,
Markus

0 Chester Gillon over 6 years ago in reply to Markus Mueller

Guru 92251 points

Markus Mueller said:
Instead of loading the program a second time (which also can take some time, depending on application size) would it be possible to do a cache clean/invalidate by e.g. a gel file prior to loading/reloading the application?

To perform a cache clean/invalidate the GEL file would have to repeat the "@ invalidate l1d and l2 cache" logic in the SYS/BIOS packages\gnu\targets\arm\rtsv7A\boot.asm file. Without further investigation not sure if GEL can execute the control register accesses to invalidate the cache by set/way.

Also, the GEL script would have to invalidate 512 lines for the L1 data cache and 65536 lines for the L2 cache which might just be slower than just downloading the program for a second time.

0 Markus Mueller over 6 years ago in reply to Chester Gillon

Expert 1370 points

Hi Chester

Thank you for this answer.

regards,
Markus

Processors

Processors forum

RTOS/TMDXIDK5718: Issues when reloading program in CCS