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.

TMS320F28035: RAM Memory Access

Genius 12760 points
Part Number: TMS320F28035

Customer encountering a strange issue in the code, I’m not sure exactly what is the root-cause.

      • I have “.ebss               : >> M0M1_DRAM | L0_DRAM | L1_DRAM,             PAGE = 1

      • Split my variables across available RAM

    • F2_APP_RLS_NoNewVar.Map à This is the “before” state when everything is working. 

      • I confirm working by stepping through the code: ptrBboxRam = (Uint16 *)(&sBboxRam);

      • In the Map File, see Line 766.  sBboxRam is located in 0x8540 (in L0 SARAM).  When I step-through the code, I can see that ptrBboxRam=0x8540, and so I can confirm that the pointer has the correct value.

    • F2_APP_RLSWithNewVar à This is the “after” state when something is wrong.

      • I added a new variable sSnapLocal, an array with 62 words.  This new variable is in 0x8840 (in L1 DPSARAM)

      • Adding this new variable also caused sBboxRam to be relocated to 0x8900 (in L1 DPSARAM)

      • When I step-through the code, I get ptrBboxRam=0xC1A1C7F7.  It is a crazy high number out of the memory range so I know something is wrong.

      • If I comment-out the declaration of sSnapLocal, re-compile and run, then code is working again because ptrBboxRam gets the correct value.  

      • So I have confirmed that the error has something to do with this new variable.  And I’m suspecting it is because sBboxRam has been relocated from L0_SARAM to L1_DPSARAM.  I have the impression that all RAM memories in this DSP are “similar” except L0 is dual-access.

    • Attached also is my Makefile so you can review my compiler/linker settings.

 

At the moment, I’m struggling to understand what could be the reason, might be a simple checkbox in the compiler options or more complicated.  I am currently adding a feature called “blackbox” and it is quite memory intensive.  sBoxRam itself has 672 words.

However, if I combine Mo, M1, L0, L1 all together, there is still enough space to go, so I know I’m not running out of space (yet) so maybe this is only a setting issue.

 

Customer tried to compare the Disassembly code, see pics below.  The code looks pretty similar, obviously except for the different memory address and DP value.

 

“Before” state sBboxRam @ 0x8540

 

“After” state sBboxRam @ 0x8900


 

I hope you can guide me on this one.
 

Regards, Bernd

  • Hi,
    Looking at the code i don't see anything wrong. Can you share ptrBboxRam value after each of the 3 assembly instructions below "ptrBboxRam = (Uint16 *)(&sBboxRam);"

    Regards
    Baskaran
  • Baskaran,

    just trying to understand the memory sections again...

     

    Memory types:

    M0

    M1

    L0 (Dual Mapped)

    L1 (CLA Data RAM 0)

    L2 (CLA Data RAM 1)

    L3 (CLA Prog RAM)

     

    In the Linker File, I have the following sections:

    .stack à Should be in M0.  Can it be in another memory?

    .esysmem à Should be in M0.  Can it be in another memory?

    .ebss à Can I also use L1 or L2 for this? 

     

    The problem has re-appeared again today, although this time it is another array affected.  One part of the array is in L0 and the other part in L1.  While doing a for-loop on the array, the L0-part of the array is accessed correctly.  However, when the loop reached the L1-part, data-access failed.  I am using the CLA in this project but the data used by the CLA code is stored in L2.  So the DSP in theory can access L1 without conflict with CLA.

     

    Regards, Bernd

     

  • I dont see any issue with interchanging memories for different purposes. Looks like LS1 access to CLA is not configured. Can you check the contents of LSxMSEL register bits 2&3.

    Pasting from TRM,

    00: Memory is dedicated to CPU.
    01: Memory is shared between CPU and CLA1

    Regards

    Baskaran

     

  • Baskaran,

    both L1 and L2 were both mapped to CLA data space.
    This was possibly the root cause, let me check.

    Regards, Bernd
  • Baskaran,

    the issue didn't come up since the hint you advised - thank you.

    Regards, Bernd