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.

Is MSMC SRAM section Accessible for MCU domain

Part Number: TDA4AL

Tool/software:

Hi, 

I have been trying to move some data to MSMC SRAM at address 0x70040000 but I got core freeze. My code is running on MCU domain, is this memory accessible for both MCU and MAIN ? or it is just for MAIN and that`s why I get into core freeze  

  • Hi,
    I have assigned your query to the appropriate engineer, thank you for your patience.

    Thanks,

    Neehar

  • Hello,

    Yes, The system address of 0x70040000 will be accessible by default for both the MCU and MAIN domains. This system address maps to the MSMC3.  The MSMC3 can be either a cache or an SRAM.  The default will be as an SRAM.

    Chances are you are trying to access the memory from the MCU-R5 with the MPU enabled but not a BAR register setup for the region so the core rejects the access.  I would suggest you experiment and trouble shoot the code with a debugger to get to the root cause.  I've attached as short video showing both the MCU and MAIN domains successfully accessing the memory.  The video also shows how a missing MPU entry will result in a no-access abort. 

    Regards,
    Richard W.
  • Hi Richard,

    The provided info is really appreciated, we don`t have the MPU enabled, we still face the same issue with the following pattern

    • when we operate only on MCU it works 
    • when we try both MCU and main we get core freeze

    we have been trying to debug with no obvious output,

    so do you have any other ideas?

    do we need to do any specific configuration before using MSMC?

    Is there more information or details rather than that in the datasheet?

  • Hello Amira,

    MSMC-SRAM accesses should be achievable by either MCU and MAIN during typical operation.  As I mention the first issue in access would be R5 MPU related.  I can imagine a few possible reasons for a run time issue past that based on history:   #1 A firewall was setup by some code which blocks accesses from one of the cores, #2 if the MSMC-SRAM was reconfigured fully as a L3 cache instead of an SRAM, #3 some code tried to "reprogram" MSMC defaults in some unsafe way.   #4 one of the cores "or some other core" managed to generate a bus protocol violation which caused a path hang and now accesses from other cores hang.  #4 is a bit harder to cause in software but if say a 'clock' were set to an out-of-spec speed by errant code, it could result in a protocol violation type hang.   I suppose a #5 might be if your custom hardware has a voltage dip (brown out) when too many cores are active due to a PDN violation, when a voltage dip happens all manner of issues can happen (to include a protocol violation) followed by hangs.

    Regard,
    Richard W.