TMS570LC4357: Prefetch abort on power-on

Hello Lucas,

For TMS570LC43x, the flash ECC detection and correction is enabled at reset.  

The ECC values for all of the Flash memory space (Flash banks 0 through 6) must be programmed into the Flash before the program/data can be read. This can be done by generating the correct values of the ECC in linker cmd file. The Cortex R5F CPU may generate speculative fetches to any location within the Flash memory space. A speculative fetch to a location with invalid ECC will cause an abort. This may not be related to your problem, let you be aware of this kind of issue.

https://processors.wiki.ti.com/index.php/Linker_Generated_ECC

Hello Lucas,

What is the address value in R14_abt register? The R14_abt - 0x8 is the instruction which causes this abort.

Hello QJ, thank you for the quick reply!

I have tried following that wiki page but I get an error upon trying to program the development board:

CortexR5: Loader: One or more sections of your program falls into a memory region that is not writable.  These regions will not actually be written to the target.  Check your linker configuration and/or memory map.
CortexR5: File Loader: Verification failed: Values at address 0xF0408008 do not match Please verify target memory and memory map.
CortexR5: GEL: File: C:\project\build\app.out: a data verification error occurred, file load failed.
CortexR5: GEL Output:     Memory Map Setup for Flash @ Address 0x0 due to System Reset

The linker command file I'm using has been attached (renamed to .cfg instead of .cmd because of forum restrictions). Main difference I've noticed is that I don't split the flash memory into multiple banks ("FLASH0", "FLASH1", ...) but use a single memory segment named "PROGRAM" - does this matter?

Edit: Updated attachment 7823.linker.cfg

The value of the R14_abt register seems to be in sync with CP15_INSTRUCTION_FAULT_ADDRESS + 0x04

Hello Lucas,

If you use linker to generate ECC, it is necessary to change the CCS loader settings so that the loader doesn't also try to generate ECC. Also verification during programming needs to be skipped because the data areas and ECC areas will now be programmed in separate steps.

In CCS "Flash Settings", please check the following items:

1. System Reset on Connect is checked
2. Auto ECC Generation is unchecked
3. Align program segments to 64-bit memory regions is checked
4. Flash Verification Settings should be 'None'
5. Perform Blank Check before Program Load must be unchecked

Hello QJ,

That brought me further - now using linker generated ECC no longer results in a loading error in CCS.
However, I still end up in the same old Prefetch Abort upon re-plugging the power plug.

Regards,
Lucas

Lucas,

Th abort may be caused by the program attempting to jump to a memory location that doesn't exist. It may also occur if you try to prefetch an address that would be improperly aligned. It also may caused by stack pointer setting. I got prefetch exception before when my stack is not big enough and my stack pointer was set to flash. Please ensure that there is enough space on the stack so that the there are no chances for the function return address on the stack to get corrupted.

Hello QJ,

Thank you for your input - it had me thinking and sure enough, I found a problem in the boot initialization process.

Attached you'll find a small-ish project where the problem is reliably replicated.
Culprit seems to be "hal_mcuIrqInit()". To be quite honest, I'm not entirely sure what it does. If I had to guess, it enables IRQ and FIQ by clearing flags in one of the status registers.
3441.bootproblem.zip

This function is used to enable the IRQ interrupt and to enable Irq offset propagation via VIC port.

Please step into this function and figure out which instruction causes the abort. I got errors when compiling the code.

Hello QJ,

Jumping to blinkloop from the line before

msr CPSR_cxsf, R1

in hal_mcuIrqInit() works, the row after it jumps straight to prefetch.
Is there a register with pending interrupts I've forgotten to clear or is the problem likely more complex than that?

Regards,
Lucas