• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 299 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.

TMS320C6748: Trouble Executing Code From L1P When Booting From Flash

Lawrence Wong
Genius 15820 points
Part Number: TMS320C6748

Customer reporting issue executing code from L1P memory region (cache disabled)

If I configure certain code to run in L1P, it works fine when debugging with the emulator, but locks up the system when running out of flash.  The software runs until a function placed in L1P is run and then the system locks up.  We do not see this issue when putting the code in L2.  I have tried changing the L1 configuration to be 100% RAM (no cache) and that makes no difference. Using data in L1D works fine, it’s only L1P that causes issues. 

 

Inspection of L1P memory region does not show any change during runtime

  • 0
    TI__Mastermind 27355 points

    Hi Lawrence,

    At first glance, I’m not sure it’s possible to place code into L1P RAM as the bootloader configures it as cache by default. Snippet from Using the TMS320C6748/C6746/C6742 Bootloader:

    There may be a way to copy the code into L1P at run-time using the DMA. I will discuss this with our boot expert and follow-up soon.

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    TI__Genius 15820 points

     Sahin,

     

    Customer does use the built-in bootloader ROM to load the AIS formatted UBL from flash.  The UBL then loads the software into RAM using the TI-provided SBL_MulticoreImageParse() Function.

     

    It sounds like the customer could have the UBL reconfigure the cache as RAM prior to the copy if they want to use it.  It looks like this can be done either with the CSL functions CACHE_L1pSetSize()/CACHE_L1dSetSize() or by directly setting and reading back the L1PCFG/L1DCFG registers.

     

    Customer added the following to the UBL to set and read back the L1 config registers:

     

    #define L1PCFG *(volatile unsigned int*)0x01840020

    #define L1DCFG *(volatile unsigned int*)0x01840040

     

        L1PCFG = 0; // no cache, all sram

        unsigned int cacheReadBack = L1PCFG;

     

        L1DCFG = 0; // no cache, all sram

        cacheReadBack = L1DCFG;

     

    This configures no cache, which is the same as the current settings for thier application (via RTSC platform config).

     

    They now get a different failure behavior when the software gets to the point of running functions in L1P.  Instead of locking up the board, it resets back to the start of the bootloader. 

     

    Is there anything additional needed to do or anything  they are doing wrong? 

     

    Regards,

     

    Lawrence

  • 0 in reply to Lawrence Wong
    TI__Mastermind 27355 points

    Lawrence,

    Please make sure they are using EDMA/IDMA to read/write to L1P. The CPU cannot access L1P as indicated in the TMS320C674x DSP Megamodule Reference Guide.

    I checked with the design team regarding what could be causing the device to reset after executing code in L1P. This was their reply:

    "Can you check if they are seeing any ECC interrupts from L1P. That could happen if they are pre-fetching code beyond the last instruction. They can pad their code with NOPs to get around that."

    Regards,
    Sahin

  • 0 in reply to Sahin Okur
    TI__Mastermind 27355 points

    Hi Lawrence,

    Has this issue been resolved?

    Regards,
    Sahin