• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 399 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.

TMS320F28335: ADC -> DMA -> McBSP infrequent corrupted data

Gregory Smith1
Intellectual 323 points
Part Number: TMS320F28335


I have an application where the ADC channels (ADCRESULT0 though 15) are copied using DMA to the McBSP at 20kHz.  The DMA is triggered asynchronously with respect to the ADC.

Infrequently the data becomes corrupted, about once every few seconds.

Surprisingly there is absolutely no data courruption after connecting to the XDS510 emulator and free running.  Operation continues without problem even if the emulator is disconnected through software afterwards.  The problem recurs after a cold reboot.

Is free running with the XDS510 expected to make the TMS320F28335 function differently?  Are there registers configured when connecting the XDS510 for a debugging session?

Can the DMA safely read ADCRESULTn registers while the ADC is writing them?

Thank you for your help.

Greg

  • 0
    TI__Guru** 115881 points

    Hi Greg,

    When you are connected with emulator, are you resetting the device and then running it or loading the code and then run it. The difference in both case is if you load the code and then run it then BOOTROM may not be running but if you reset the device and then click on run icon then bootrom code will run and jump to your application if emulation boot (refer the device document) is set correctly. In standalone mode bootrom code always runs.

    This really should not impact the functioning of the code but there may be some difference.

    For ADC related query, I'll add other expert to reply.

    Regards,

    Vivek Singh

  • 0
    TI__Guru 62975 points

    Greg,

    There is arbitration logic to handle simultaneous reads and writes of the ADCRESULT registers.  This should not be a problem.

    With respect to Vivek's comments about the emulator activity, you can remove the GEL file from your target connection setup to minimize exogenous influences when connecting to the device.

    If the data corruption is significant (it sounds like it is), you can reconfigure the DMA to transfer a known sequence of values from SRAM to McBSP (instead of ADC to McBSP).  This will help to determine if the ADC is contributing to the problem.

    -Tommy

  • 0 in reply to tlee
    Intellectual 323 points

    Transferring constant values through DMA to the McBSP helped enormously in tracing the data corruption. 

    The problem is now solved.

    Ultimately the root cause was not in the TI DSP at all, but rather the receiving processor of the McBSP data (NXP Cortex M3), which had a thread-safety/interrupt issue resulting in intermittently missing several frame syncs to the McBSP. 

    How the observed problem disappeared when debugging with the TI emulator is still a mystery to me.  The answer could lie in the excellent answers from both Vivek and Tommy.  As the problem is solved I'm very happy and won't investigate further.