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.

cache issues in TMS320C6424 custom board

Other Parts Discussed in Thread: TMS320C6424

Hi ,
I face some problems when I try to enable the cache in the system .

the processor that we are using is  TMS320C6424 .
the software is using DSP/BIOS and it works perfectly without the cache,  except that it is relatively slow an doesn't meet our real-time requirement.
on the other hand When the cache is enabled through BIOS configuration,  the system starts working very well just for few seconds and after that,  the system suddenly stops and displays the following error .

Trouble Halting Target CPU:
(Error -1202 @ 0x0)
Device core is hung. The debugger will attempt to force the device to a ready state to recover debug control. Your application's state will be corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further.
(Emulation package 5.1.507.0)




when disabling the cache , we don't face such problem .


 what kind fault can cause such issue  ?

  • Hi,
    Have you tried setting breakpoints and debug the application?
    What is the application loaded on to DSP? Can you please increase the stack size of the application and try?
    Can you please try loading simple hello world example?
  • Hi,
    Thanks for your response ....
    As I said above I am able to run codes on the board ...
    the problem is, when I enable the cache in my DSP/BIOS , the system works perfectly and give the desirable results just for few seconds (random period not fixed... sometimes 1 minute sometimes 10 seconds ) and then it hang .

    why do I need the cache ?
    the system read the input signal through the codec with defined sampling rate, and we have time consuming operations , so the new sample may arrive before processing the old one ....
    using cache improve the performance considerably and gives us the desirable results .


    I have tried different configurations :
    increasing stack , heap ...
    decreasing / increasing cache size .....
    disabling L2 ram totally ...
    making L2 100% cache ....
    as suspecting that the issue may be due to "DSP SDMA/IDMA: Unexpected Stalling and Potential Deadlock Condition When L2 Memory Configured as Non-cache (RAM)" which described in the Silicon Errata
  • May I suggest two things:

    1. First make sure that all cache control functions are BIOS  (that is, no csl or other drivers manipulate teh cache)

    2. Do cache write back invalidate before reading the next frame for all the cache.  I suspect that you may have a global variable that is changed by some host (one of the peripherals?) and the code still reads the old value. So try to do cache write-back invalidate before each frame and report if the problem goes away

    Ran

  • thanks for you response ...

    1. I configure the cache through the BIOS GUI only, no other tool is used ...


    2. as u mentioned, I am using EDMA to get  data from the codec to an input buffer , and to output data to the codec from output buffer ....
    but as I am debugging , I have disabled EDMA and codec totally .... instead I read data form internal buffer. plus no other peripheral read or write from the memory  and still i face the same problem


    In case that  I am using EDMA, you said that I must write-back invalidate the cache before each frame ..
    what do you mean by "frame" ?
    In my case EDMA event right ?


    last thing :
    Can the cache coherence issue cause the device to hang (and the debugger to disconnect) at random times

    If this issue is related to Hardware, What possible cause of it

  • I will start from the end of your message
    Hardware issues for a device mature like TMS320C6424 are described in the errata. Please look at www.ti.com/.../sprz252d.pdf at advisory 1.3.1 and see if this is your case

    What I meant by frame is a group of input data that the code processes in a single iteration. For example, in voice application the system may collect data for 10 milliseconds and then processes it while the next group of data (that is, the next frame) is collected in parallel.

    If your issue is not EDMA but core read and write, and it works fine for N "frames" and then crashes, I would suspect either memory leak or some global variable that is not updated correctly. Now when you disable the cache you do not see the problem, so it is not memory leak. (Have you run the non-cache case for long enough time? I assume you did, but if not, run it again) so some global variable that is not updated correctly is my theory now.

    Look again, and post again if you still do not understand why. Other people on the forum may suggest other ideas as well

    Best regards

    Ran
  • thank you again ran35366

    OK it is clear now where I need to invalidate the data in the cache(after filling the input buffer) ...

    But it is not clear for me that, when I disable the EDMA and codec, still I face cache issues ??
    how some global variables don't update correctly when the cache is enabled, given that there is no external input (i.e. only cpu read and write to the memory no DMA ... ) ??

    by Hardware issue i meant in our custom board (power sequence , clock ,etc).
    I need to know what kind of hardware issues may lead to similar situation.
    Is it possible that our processor is corrupted due to different things(manufacturing, storing, shipping,assembly,...).



    by the way we have tested the code under EVMC6424 recently... and the code works perfectly even with cache .
    so the problem seem to be hardware related .....
    the EVM use the same processor but with different packaging...
    our custom board processor : TMS320C6424ZDUQ_$NC_56A4EDW (G1 L1)
    the EVM : TMS320C6424ZWT__$NC_24AT2VW (E1 L2)
    what is the difference between these two processors ?

    At this point I need to know if ...?
    1- definitely corrupted processor .
    2- definitely (PCB/BOARD ) related issues .
    3- may be software (configuration) issue.
  • OK

    I am a software guy, so I forward your posting to the hardware team to answer the hardware issue.

    Ran

  • regarding the non_cache case :
    I have tested the the code with cache disabled in the custom board for more than 10 hours without crashing or hanging.
  • Mohammed,

    Enabling cache will cause the CPU core to consume more power.  You should verify that the power supplies function properly once cache is enabled.  Similarly, the increased power consumption with cause the C6424 to dissipate more heat.  Make sure that the device is not getting too hot.  A different package will also affect heat dissipation.  You should verify that all clocks are correct on the custom board and that the power - clock - reset sequencing matches the datasheet.

    Tom

  • Hi
    Have you confirmed that when you run on the EVM vs your custom board, you are running the processor at the same frequency and core voltage in both scenarios?
    To further check what Tom suggested and potentially see if there are other marginalities in your board design, can you also try to reduce the DSP frequency in your custom board and see if you see failures reduce/go away?
  • thank u Tom and Mukul , ...

    first of all
    Measurement of Power and clock signal and sequence shows acceptable range of values, even when the cache is enabled.
    the values of clock and power signals are identical to the EVM and the software is the same .

    It seems that reducing the frequency solves the issue
    we were using 594 MHZ .... now we are using 324 MHZ and every thing seems to be OK
    I think we can increase frequency up to 430 MHZ without problems (I need to run long tests to approve this )


    by the way ... I had also suspected that the issue is related to speed and power consumption, but I hadn't reduced the clock probably . simply I changed the PLLM value in the gel file , and it seems that the BIOS overwrite this value and reconfigure the clock to be 594 MHZ .

    When I tried reducing clock this time , I discovered that I need to configure it after the Bios , simply I put a break point and changed the PLLM manually through the registers window ..


    so what you guys think ....
    plus I have software_related question ...(how can I prevent the BIOS from changing the PLL ?)

    We have another BOARD that will arrive soon ....
    We will test is and I will update you as soon as it arrive



    Thank you again that was really helpful

  • Mohammed,

    How many custom boards have you built and tested?  Do they all show the same pass and failure modes?  If some work better than others, please provide the ratio.

    Tom

  • for now only one BOARD ...
    additional boards will arrive in the future
  • Another debug point would be to now see if you have the ability to increase the core voltage of the device / sourcing it externally for your custom board (obviously please try to stay within datasheet limits and use this as a test) - if at a higher voltage you see that your 594 MHz works - you probably have some power supply design type issue... and should further see the differences in the EVM design vs your design even though it is for a different package. 

    Make sure no power pins have been left out in your design etc.

    On BIOS override, will see if Ran and team can provide some additional guidance.