TMS570LS1224: Bootloader reset hangs on undefEntry after clearing memory

Hello,

((void(*) (void))0x00000000)(); should work. 

Please add a breakpoint or a while() loop at the beginning of _c_int00(), then step through your code to find which instruction causes the problem.

I did what you asked for.

The processor hangs at the function c_int00() where checkRAMECC() is called.
Then step by step I went through the checkRAMECC() function and noticed that right after calling ramread = tcramA2bit, the processor enters prefetchEntry and then undefEntry and is only saved by reloading the program.

For the tests, I commented 2 lines of code

ramread = tcramA2bit;
ramread = tcramB2bit;

and everything works fine. After uploading the wrong program, I jump to the 0x00 range and the bootloader starts from the beginning.
But ultimately I would like to avoid a situation where error checking in c_int00 () -> checkRAMECC() would have to be turned off.

The problem is probably the displacement of the interrupt vector, which is shifted to the application.
Any ideas?

Paulina

Hello Paulina,

Your analysis is correct. Read from location with 2-bit ECC error will cause a data abort to be generated, and CPU can't find the abort handler in the shifted location (0x17FF8).

Hi QJ,

I have one more issue to clarify related to the bootloader. 

When I upload single-application, everything works fine. However, when I upload the FreeRTOS application, the bootloader hangs.

I suppose it's still an interrupt vector issue.

I read this thread:
https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/476577?Issue-with-bootloading-and-RTOS
but I don't think I fully understand the solution proposed by Vladimir. Where should I replace/add the mentioned vectors? 

How could I fix it? 

Paulina

Hello Paulina,

The interrupt should disabled before the bootloader starts to ease the flash or program the flash. 

Hi QJ,

I turn on the bootloader (there is no other application yet uploaded, only the bootloader). Then I erase and program flash with the FreeRTOS application. The application is flashed, the hardware checksum is correct. When trying to reset the bootloader, jump to 0x000000 address (to check the flag and enter the application if avaliable) the controller hangs in sys_startup.c.

Where should I disable interrupts if the bootloader doesn't support them and the application has not entered?

There is no problem with uploading bare metal app, only with RTOS.

Paulina

Hello Paulina,

I misunderstood your question. Your application is freeRTOS based, and bootloader doesn't use freeRTOS. 

At which instruction does the code get hung up? Is it caused by the ESM error flag? The sys_startup.c checks if there were ESM group3 errors during power-up:

Exactly, the bootloader is bare-metal. Loading the application also bare-metal works properly, the problem appears when loading the freeRTOS application.
The situation is as follows:
-> bootloader (bare-metal) is running
-> loading the FreeRTOS application - the application is loaded into the memory, the checksum is correct
-> I reset the bootloader, i.e. I jump to the address 0x000000
-> at this point the processor freezes, the red ERR LED is on

I set up some breakpoints to see exactly where the CPU hangs.
The application enters errata_PBIST_4 (); , and then stops at _pmuResetCounters_ () ;.

If I set a breakpoint in line 2794 the application stops there, but when the breakpoint is in line 2795 the application will not get there because it freezes earlier.

After stopping at a given breakpoint there is a problem with the reset because I lose communication with the debugger - controller (some problem with resseting CPU?) The following errors are shown.

CortexR4: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 8.0.903.2)
CortexR4: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2)
CortexR4: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2)

Still an interrupt vector problem? How can I avoid it?

Paulina

Hello Paulina,

I don't think this issue is caused by the interrupt vector table. If you power cycle the board, does the code still get stuck at this location? Does the code allow you step into pmuResetCounter() function? If yes, which instruction causes the issue? When stuck happened, are the values of MCU registers expected values? 

The problem was due to the interrupt vector in the application (not in bootloader).
Appropriate configuration of the .cmd and sys_intvecs.asm files solved the problem.

Thanks! 
Paulina