• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 793 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.

C6713 Jump from Bootloader to Application

Kevin Sylvestre
Prodigy 20 points
Other Parts Discussed in Thread: TMS320C6713B

I am attempting to write a secondary and tertiary bootloader for a custom board with the TMS320C6713B.  I am not using the DSP/BIOS.  I am using CCSv4.

The secondary bootloader is stored in the first 1kB of FLASH, and is loaded on power reset by the C6713B's primary bootloader routine.  The secondary bootloader is written in assembly language, and loads the tertiary bootloader from FLASH to RAM.  This seems to work correctly.

The tertiary bootloader provides a serial menu of options, including the ability to download hex files and modify FLASH.  It should also be capable of loading and launching application code, which is compiled separately.  The downloading and storing of hex files works properly.

The problem I keep running into is whenever I compile projects separately, I cannot jump between them.  For instance, I have created a secondary and tertiary bootloader.  The secondary bootloader is loaded to IRAM without a problem, and I can use the secondary bootloader to load the tertiary bootloader to IRAM (I have confirmed this using the debugger).  However, when I attempt to use a function pointer to branch to the "_c_int00" entry point of the tertiary bootloader, the tertiary bootloader does not execute (I am sure of this because I have programmed a pattern to appear on some on-board LEDs).

If I compile the secondary and tertiary bootloaders together, I can branch to the desired location without a problem.  However, I run into the same issue when I try to branch to separately compiled application code.

Is this a caching issue? Is there a way to disable the L1P and L1D on the C6713B?  I have looked in the Cache User's Guide (spru656a.pdf) and didn't see anything about disabling the caches.

  • 0
    TI__Guru*** 125430 points

    You cannot disable the L1P/L1D on the c671x.  I expect your problem is one of cache coherence.  Are you performing manual cache operations before branching to an application?  So in particular, in your secondary bootloader I suggest that you perform a writeback-invalidate on all address ranges that you touched immediately before branching to the tertiary bootloader.  Similarly, I suggest performing a writeback-invalidate on all addresses you touch/load immediately before branching to the application.

    After a cold power-up, only L1P and L1D are enabled, i.e. L2 is disabled.  The L1 is a read allocate cache so as long as you're just doing reads from external memory and then writes into L2, you shouldn't actually be caching anything.  I think the issue comes due to having so many layers of bootloaders.  For example, if you have a local variable of some sort in the L2 for the secondary bootloader, then that variable would be cached in L1D.  Then when you're in your secondary bootloader if you go to write instructions into that same location, because it's already allocated the instructions will "land" in the data cache instead of the actual memory!  Performing the writeback-invalidate will "push" anything that might be cached back to the physical memory and make sure that nothing stays allocated in the cache.  That way you can "start fresh" for the next piece of code.


    If that's not it please provide more details on your cache handling.  In particular be sure to specify whether you're doing writebacks, invalidates, writeback-invalidates, whether they're local or global operations, and the precise timing of the operations relative to other key functions like branching to the app, etc. I hope this helps.

    By the way, in addition to the "cache" guide there's also one called the "two level internal memory reference guide".  That one also contains important details related to cache operation.  In my mind they are tightly related (i.e. seems like they could have been one document), though that's not how we did it!  So be sure to consult that one too (SPRU609B).