Interrupt exception vector handling with bootlaoder

Joachim,

Actually, I had many discussion about this interesting topic recently.  The following discussion is based on the assumptions (1) bootloader and application are independent entities such that changes in application will not affect bootloader and vice versa, and (2) bootloader only needs to handle reset and IRQ/FIQ.

There are two types of interrupts on TMS570. The first types are exceptions such as reset, SWI, data and prefetch abort, etc. The second type is IRQs and FIQs.

For IRQs  and FIQs, CPU directly fetches the ISR address from VIM module. If the hardware vector mode is enabled, CPU will not even jump to the exception vector at 0x00000018 or 0x0000001c. You can configure VIM module and RAM independently for the bootloader and application. The hardware vector mode can be enabled by the discussion in the following thread.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/183311.aspx

Since the exception vector table is not relocatable, Every time a reset or an abort happens, CPU will jump to the vectors starting at address 0x0. Assume that your bootloader occupies addresses from 0x0 to 0x7fff, and application starts at 0x8000. you can set up the bootloader vector table at 0x0 as follows,

    b _c_int00 ; entry point to bootloader

    b 0x8004   ; jump to application vector for processing

    b 0x8008   ; jump to application vector for processing

    b 0x800c   ; jump to application vector for processing

    b 0x8010  ; jump to application vector for processing

    b 0x8014  ; jump to application vector for processing

In your application project, you need to put the vector table at address 0x8000. In this set up, when an exception occurs, CPU will first jump to the bootlaoder exception vector starting at address 0x0 and then jump to the application exception vector starting at address 0x8000. After a reset, CPU will always enter boot loader first. In the bootloader, you need to use intruction "b 0x8000" to jump to application. If you want to debug your application without bootloader, you can change the vector address in the application link command file from 0x8000 to 0x0.Or you cna change the first instruction in the bootloader vector from "b _cint00' to "b 0x8000".

The limitation of this idea is that you cannot enable ECC for the bootloader because abort handling is not allowed for bootloader.

Please let me know if this idea works for you. Please notify us if you can think of something better out of this discussion. 

Thanks and regards,

Zhaohong

Zhaohong,

Thanks for your informative answer. Unfortunately it doesn't solve the problem.

The hardware vector mode is enabled already by HALCoGen with the tick "Enable IRQ Handling via VIC Controller" which produces exactly the assembler code you provided.

The ESRAM ECC Check should trigger a data abort exception. What it does actually is generating a prefetch abort exception. Thats all I see with the debugger. After the instruction "ramread = tcramA2bit;" generated by HALCoGen (sys_selftest.c, in function checkB0RAMECC()) the PC jumps to 0x0C (prefetch abort) and sticks to there. Not even the jump to 0x800C is executed.

Any idea why the appliaction triggers a different exception interrupt and why the PC sticks to that address?

Thanks and regards,

Joachim

Zhaohong,

Thank you, this helped quite a lot to the situation. I won't get any prefetch aborts anymore.

But first, somehow the assembler instruction for the  jump from exception vector of the bootloader to the one of the app is weird. For the data abort I have to write

b    #0x7FF8

instead of the expected

b    #0x8010

Do you have any idea why?

Second, now I get  a step further in the app but get a undefined exception somewhere later. In the application code i just changed the command file telling the linker to start placing the code from address 0x8000. Do I have to make other modifications, or should this be enough?

Thanks a lot and have a nice weekend

Joachim

Zhaohong,

"b 0x8000" doesn't work with the assembler: [E0004]  Illegal operand

Everything (Application and Bootloader) works fine with the app's exception vector at 0x00 (what you proposed to do). Something with the jump from 0x00 to 0x8000 seems to crash the system. Any idea?

Best regards,

Joachim

Joachim,

Do you use "b #0x7ff8" at address 0x0 to jump to address 0x8000? Can you put "b #-8" at address 0x8000 to check if branch occurs correctly? After a power-on-reset, CPU will starts at address 0x0. When you connect debugger to CPU, you should see PC at 0x8000. To branch to 0x8000 from the bootloader, you can call an assembly function from c-code. The assembly function can be constructed as follows assuming that you use eabi compiling option.

    .global branch2address
.text
branch2address:    
   b r0     ;no need to to save any register because CPU branches to a new application
   bx lr
.end

Calling in C:

extern void branch2address(unsigned int address);

branch2address(0x8000);

Thanks and regards,

Zhaohong

Zhaohong,

Ok, I found the solution. My exception table in the bootloader looks now like this:

    b   _c_int00    ;0x00
    b     #0x7FF8     ;0x04, undefined instruction
    b    #0x7FF8     ;0x08, Software interrupt
    b    #0x7FF8     ;0x0C, Abort (prefetch)
    b    #0x7FF8     ;0x10, Abort (data)
    b   #0x7FF8     ;0x14
    ldr pc,[pc,#-0x1b0]    ;0x18 IRQ
    ldr pc,[pc,#-0x1b0] ;0x1C FIQ

The last two entries were missing (IRQ and FIQ). The ADC interrupts are configured in FIQ mode and if triggered jump to 0x1C. So long so good, but why is this? You said that the IRQs and FIQs are reallocated to VIM by hardware, this seems not to be the case for FIQ. Furthemore what does instruction "ldr pc,[pc,#-0x1b0]" and why is a simple "b   #0x7FF8" not working here?

Hopefully you can bring some light into the dark.

Thanks and regards,

Joachim

Christian,

Thanks for the satisfying explanation, it helps a lot.

There is no possibility to use #3 for FIQ, is that right?

Regards,

Joachim