• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 1818 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS570LS3137: vector table seeting on bootloader and application

guodong yao
Prodigy 110 points
Part Number: TMS570LS3137

Tool/software: Code Composer Studio

hello

right now i am trying to impliment the bootloader and application project on the tms570HDK,both the bootloader and the app use UCOS-II and tftp (lwip).

most scenario you talked about are like this :

(e2e.ti.com/.../225447)

  _c_int00     ;0x00   Bootloader reset
         b #0x7ff8    ;0x04   undefined_instruction, branch to application
         b #0x7ff8    ;0x08   software_interrupt, branch to application
         b #0x7ff8    ;0x0C   prefetch_abort, branch to application
         b #0x7ff8    ;0x10   data_abort, branch to application
        b #0x7ff8 ; reserved, branch to application
        ldr pc,[pc,#-0x1b0]        ;0x18
        ldr pc,[pc,#-0x1b0]        ;0x1C

The application vector table at the address 0x8000 should look as follows.

         b   _c_int00     ;0x00   application reset
         b  _undef_ISR;  0x04 undefined_instruction
         b  _swi_ISR    ;0x08   software_interrupt 
         b  _prefetch_abort_ISR    ;0x0C   prefetch_abort 
         b  _data_abort_ISR    ;0x10   data_abort
         b  _reserved_ISR ; reserved
         ldr pc,[pc,#-0x1b0]        ;0x18
         ldr pc,[pc,#-0x1b0]        ;0x1C

 in all these cases ,the irq using the vector mode,and in the boot proj, the udef ,abort , swi have no ISR,,they just jump to the app‘s ISR.

so is the spna236,

but for the ucos project, the IRQ have to use index mode (legacy arm7 mode ) ，and all the exceptions have to be down in the bootloader .

can you give me some advice?

or if the sharing vectors in sram method described in spna236 works ,can you give me some specific suggestions about how to do in the app?

i am stucking here for a month ,realy need your help!

thank you !

  • 0
    TI__Guru 59540 points
    Hello Guodong,

    If your application is unable to support vectored interrupt mode, then use the legacy mode but use sharing within the ISRs. i.e., within the exception handlers/ISRs, have separate code to process according to the different needs of the boot loader vs. the application. This can be accomplished by the setting of a global flag once the application is reached and bootloader operation is no longer needed. You may want to add additional protections of the flag such as a multi-bit key or diverse locations of multiple keys if this is a safety application.

    as an example using psuedo code:

    data_abort_Exception()
    {
    switch( boot_state )
    {
    case (BOOT_MODE):
    do_boot_excep_process.....
    break;
    case (APP_MODE):
    do_app_excep_process.....
    break;
    default:
    while(1);
    break;
    }
    }
  • 0 in reply to Chuck Davenport
    Prodigy 110 points

    hi Chuck, 

    thank you for your help!

    i think it is hard to know the adress of the "do_app_excep_process" in the bootloader programm,cause Bootloader and app are two seperate CCS Proj.

    i think the way is to share the vector table in ram , right now my proj works, but i am not sure if there are still some hidden danger or bugs. 

    as in the app report spna236 chapter 3 considered several  considerrations, and refer to the "TMS570 and vectors forwarding to application from bootloader  "

    [ https://lists.rtems.org/pipermail/devel/2015-November/012878.html ]

    they finally choose the RAM vector and  POM, but the code is less, i can't understand how to impliment it .

    is it possible that you can give me the email of the auther who write SPNA236, so i can ask him some question?

    thank you!

  • 0 in reply to guodong yao
    TI__Guru 59540 points
    Hello Guodong,

    So for now your project is working but you want to understand the risks of placing the vector table in RAM. Correct?

    As per the application note, the biggest concern is that there will be an exception that occurs prior to initialization of the RAM vector table. This would cause a jump to some unintended area of the device memory.

    Please let me know if there are other concerns. The original author of the application note is no longer at TI so they are no longer available for discussion on this topic.