TMS570LS1114: SPNA236 exception handling between bootloader and application

Hello James,

I am fowarding your post to QJ who is a better resource on boot loader configurations than I am. He should get back to you shortly. Sorry for any delays or inconvenience.

Hello James,

To route exceptions to application, the exception vector in bootloader should be changed:



;-------------------------------------------------------------------------------
; import reference for interrupt routines

.ref _c_int00
.ref _dabort
.ref phantomInterrupt
.def resetEntry

;-------------------------------------------------------------------------------
; interrupt vectors

resetEntry
b _c_int00
undefEntry
b undefEntry ----> application start address - 0x8;
svcEntry
b svcEntry ----> application start address - 0x8;
prefetchEntry
b prefetchEntry ----> application start address - 0x8;
b _dabort ----> application start address - 0x8;
b phantomInterrupt
ldr pc,[pc,#-0x1b0]
ldr pc,[pc,#-0x1b0]


For example, if the application start address is 0x8000 (3rd sector), the modified vector is:
;*****************************************************************************
.sect ".intvecs"


;-------------------------------------------------------------------------------
; import reference for interrupt routines

.ref _c_int00

;-------------------------------------------------------------------------------
; interrupt vectors

b _c_int00 ;0x00
b #0x7FF8 ;0x04; 0x7FF8 = 0x8000-0x8; 0x7FF8 is the application start addr
b #0x7FF8 ;0x08, Software interrupt
b #0x7FF8 ;0x0C, Abort (prefetch)
b #0x7FF8 ;0x10, Abort (data)
reservedEntry
b reservedEntry ;0x14
ldr pc,[pc, #-0x1b0] ;0x18
ldr pc,[pc, #-0x1b0] ;0x1C

What happens if you get an exception during the bootloading process when there is no application code (using your example) at 0x8000 onward?

Currently my application is located at a location beyond 0x8000. The b instruction's longest reach is 0x7FFF so that approach you outlined cannot be used in my case. Ideas?

I had tried getting some of the exception table in SRAM approaches in SPNA236 but no luck yet. The final approach described in SPNA236 has a variable called ramIntvecsCpyTbl that the compiler can't find, not declared in the project, and I can't find anywhere in the code snippets provided with SPNA236. Tried changing removing the extern from the line in USER CODE 2 section of sys_startup.c that ties in ramIntvecsCpyTbl but the ram table in ramIntvecs doesn't end up in the RAMVECTORS section.

Hello James,

If you have exception of "RESET, IRQ, FIQ" during the bootloading process, the code will jump to the ISR defined in bootloader (c_int00, irq_isr, fiq_isr). If others (dabort, pabort, etc), the code will get abort since the isr is not defined.

The b (branch) instruction can reach up to 32M bytes, so there is no problem to use b 0x8000.

The only place for exception vector is at 0x00, the beginning of the main flash. For example, if any IRQ interrupt occurs, the CPU will execute the code at 0x18 (0x18 ldr pc,[pc,#-0x1b0]), then jump to interrupt ISR (address is in [pc,#-0x1b0]).
Why do you want to place the exception vector table in SRAM?

You are correct. I didn't look close enough at disassembly and the branch was getting translated correctly to jump to my application based at 0x20000. I was looking at the EA007FFEs at 0x4,0x8, and 0xc for some reason I thought it was limited to 0x7FFF; not thinking straight on that one. Anyway when I make the changes you suggested the application code hangs, stuck in a dabort, which actually is now going to the right location now for that - 0x20010. It's stuck in dabort or for(;;) loop in sys_startup where it checks for ESM group3 error when trying to debug this.

One reason I thought I needed to implement the exc vec table in SRAM for a while back when trying out Halcogen enabled self tests, the application would hang if I enabled the Halcogen CPU self test in the application code. If I put Halgogen enabled CPU self test in the bootloader code things worked (didn't hang). Halcogen generated dabort code for the bootloader project. Later when experimenting with SafeTI Diagnostic libraries, running the L2L3Interconnect test was causing a dabort, but when stepping thru the code it jumped to 0x10, stepped thru the bootloader Halcogen generated dabort code and went back to application but then right back to bootloader dabort code. Seeing that it was going thru the bootloader dabort code instead of the application dabort code I thought came to me that maybe I needed to implement in SRAM or something, so when dabort happens it goes to application code dabort code. So here were are.

I tried taking out all Halcogen enable-able self tests from bootloader code but the application code still hangs in dabort. The dabort code in the application code is the _excpt_vec_abort_data() code from the SafeTI diag library example.

If you have suggestions of things to look at to figure out why it is hanging let me know.

Hello,

This problem is not caused by the bootloader, and the exception vector take in bootloader. It is caused by the application itself. You need to debug the application by programming it 0x00 and executing it standalone.