• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 442 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.

Problem with RAM-Sector

Ludwig Schlegel
Intellectual 445 points


I use concerto MCU (F28M35H52C1) and have problems with shared ram sector S1. My device is working. All control tasks in c28 and all communication tasks in the m3 work fine. Just after around 10, 20 or 30 minutes one value in the shared ram changes. In our software version 1.2.6 the address 0x200be80 changes to zero and in version 1.2.7 0x200be74 changes to value 0x1555. So we thought something in our software is wrong. Some pointer is running “crazy”. So we used our emulator xds560v2 and made a hardware breakpoint at this addresses. If our controller works with the value (read or wright) the debugging session stops by the breakpoint, but if I have the strange behavior that the value suddenly changes the debugging session doesn’t stops.

Could it be that there is something in hardware of the concerto that it behaves strange by worming? Or are there some know bugs like I describe??

  • 0
    TI__Guru** 115881 points

    Hi,

    Please let us know the use case for sector S1 in your application? Is it shared by master sub-system & control sub-system or only one of the CPU (M3/C28x) is making accesses to it? 

    Regards,

    Vivek Singh 

  • 0 in reply to Vivek Singh
    Intellectual 445 points

    Hi,

    only the M3 is making accesses.

    In my init-routine I´m using: RAMMReqSharedMemAccess(S1_ACCESS, SX_M3MASTER);

    And in linker command file:  

    S0 (RWX)        : origin = 0x20008000, length = 0x2000
    S1 (RWX)        : origin = 0x2000A000, length = 0x2000
    S2 (RWX)        : origin = 0x2000C000, length = 0x2000
    S3 (RWX)        : origin = 0x2000E000, length = 0x2000
    S4 (RWX)        : origin = 0x20010000, length = 0x2000

    .....

    .bss    :   >> S0 | S1 | S2 | S3 | S4

    Regards, Ludwig

  • 0 in reply to Ludwig Schlegel
    Intellectual 445 points

    It looks like we found the error.

    We use the IPC MSG RAM for asynchronous transfer of data from M3 to C28 and from C28 to M3. So it happens from time to time that the M3 is writing data while the C28 is reading it. So the M3 can´t access that ram and writes the value to the S1 RAM.

    We found it out because the MSG RAM has the address 0x2000FE7A and the value in S1 RAM has the address 0x2000BE7A.

    The problem is, that we ordered F28M35H52C1RFPT but we got xF28M35H52C1RFPT. On the “x” devices exists the errata: “RAM Controller: Cortex™-M3 Accesses to Shared RAM (Cx and Sx) and to MSG RAM Do Not Work When Any Other Master (μDMA/C28x/DMA) Simultaneously Accesses the Same Memory“.

     Do you think we are on the right way?

  • 0 in reply to Ludwig Schlegel
    TI__Guru** 115881 points

    Hi,

    Yes, we had an issue on initial revision of Silicon . I would strongly recomend to use new revision of Silicon for your use case.

    Regards,

    Vivek Singh