Interrupt vector mapping when Bootloader comes into picture

Hi Renjith,

I have forwarded your query to our Boot loader expert. We will get back to you as soon as possible.

Best Regards

Prathap

Renjith,

Yes, Both the bootloader and the applican may need the interrupt vector table. There are many ways to handle this.

Some architecture supports remapping the vector table, which is one of the method,what is your target TI controller?

Alternatively you may have to step into the bootloader each time and exit into the application after performing a check on a flag that you would have set the time you exited out of the bootloader.

Regards,

Pratip

Dear Pratip,

I am using the TMS570LS20216SPGE.

Thanks,

Renjith George

Renjith,

A simpler method would be to have a common vector table and jump to the boot code each time

where you can perform a flag status check that you could set  while you exit the bootloader.

So for the first time you can perform the boot and the set a flag just before exiting the boot, second time onwards check this flag in the begening and jumpt to application from the boot.

Let me know if this would work for you.

This could also depend on what you plan to do in the boot code.In the begening of the boot you may want to disable all the interrupts as well.

Regards,

Pratip

To add a little bit more information:

1) The CPU supports a "V" bit,  bit 13 of "System Control Register" (Coprocessor Register C1, C0, 0).

    While this would allow remapping of interrupt vectors to "HIVECS" which you might be familiar with from other ARM products,  the address range of
    HIVECS at 0xFFFF 0000 to 0xFFFF 001C maps into the area of the TMS570 where we have system registers (aka. peripherals) so you can't execute code from this region.

    In other words,  don't try setting "V";  while the vectors can be remapped the area they map to won 't be useful to you.

2) The VIM essentially contains an entire IRQ and FIQ interrupt map and is reprogrammable.   So you can easily remap your actual interrupt vector address by reprogramming VIM between exiting the bootloader and starting the application code.

    There are several ways to use VIM for IRQ.   One way doesn't even cause the CPU to jump to the exception vector at 0x00000018 first, you jump directly to the address programmed in VIM.  This is enabled through bit 24 "VE" of the same System Control Register (Coprocessor Register C1, C0, 0).     Another way is to dispatch to 0x000000018 (don't set "VE") but still read VIM and branch to the address that VIM returns.   Either of these two methods mean you can dispatch IRQs to different handlers before and after the bootloader by simply reprogramming VIM.

  FIQ doesn't support dispatching directly even when VE is set.  VE only affects IRQ However for FIQs you can still read the VIM register and dispatch to whereever it points to allow for different FIQ locations.  

But ...  you probably don't need to use FIQ in the bootloader and it would perhaps be simpler to do something like push critical registers onto the stack in the bootloader sector then jump to the actual handler,  which would be a default handler when the bootloader alone is programmed but could be overridden by the application.   Probably this means reserving some RAM to be used as a dispatch table that can be configured by the bootloader but then overwritten by the application. 

3)  The latter recommendation for FIQ is what you'd also need to do for the other exception vectors, like undefined, abort, svc.... 

-Anthony

Assuming the user got the query resolved.
Pls feel free to continue the thread if further clarifications need on the same query.  

Best Regards
Prathap

Hi Prathap,

I know this is an old post but after quite a bit of searching, I hope that it is appropriate to post my question here. If not so please let me know and I will start a new thread. Thanks.

I used to use an ARM7 based MCU with a parallel bus so I can use the boot mode feature of the MCU to decide which memory to fetch during system power-up. My bootstrap loader was burned to an external Flash rather then the MCU internal ROM, so there is no link at all between the BSL and the main application. To start either the externally programmed BSL or the main application, all I have to do is to set the boot mode discrete signals (let say, pin header programming) accordingly.

On our new HW design, we use the FPQ packaged 144-pin TMS570LS20216 MCU, and unfortunately, there is no external bus to access external memory. Therefore I guess that the BSL must be embedded to share the same Flash ROM as the main application.

Here are my questions:

1) Is there a BSL feature in the TMS570LS like the one for the MSP430, found here: http://www.ti.com/lit/ug/slau319b/slau319b.pdf "MSP430 Programming Via Bootstrap Loader".

2) Otherwise, is there a sample project for such purpose for the TMS570?

Thank you very much!

Chuck.

Hello Chuck,

The TMS570LS products will only boot from the internal embedded flash memory.  There is no built in boot loader - the user is free to implement a boot loader of choice.  Code execution will simply start at address 0x0.

Best Regards,
Karl 

Thanks Karl,

Any chance to direct me to some sample source code examples of such a boot loader, instead for me to re-invent the wheel?

Much appreciated!

Chuck.

Hi Chuck,

The HALCoGen tool can be used to create a basic boot loader.  Also you may wish to take a look at the following app note and code on Hercules MCU initialization:  http://focus.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=spna106a&docCategoryId=1&familyId=1931.

Regards,

Karl

Hi Karl,

I have HALCoGen v2.07 dated 2010-04-06, and I can't locate the section for the generation of a basic boot loader for the TMS570LS MCU. Can you please shed some light as on "How to"?

Thanks again!

Chuck.

Hi Chuck,

Perhaps I mis-wrote; what I meant to say is that if you create code from a basic HALCoGen project, it will act as your bootloader.  To my knowledge there is not a "blank" bootloader only project with HALCoGen.

Regards,
Karl