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

TMS320F28379S: DMA Memory Access Conflict

Bae Kevin
Prodigy 80 points

Part Number: TMS320F28379S

Tool/software:

Hello,

I am currently using SPI FIFO (Master) in conjunction with DMA, and utilizing the DMA RX interrupt.
In total, two interrupts are used, including a PWM interrupt.

The PWM interrupt occurs at 50kHz, while the DMA RX interrupt is triggered approximately every 110–140kHz.

Each time a DMA RX interrupt occurs, a simple process is executed: a GPIO is used to control the CS line to select the next SPI slave channel, and DMA is then triggered again.

Within the PWM interrupt, I read data from four channels using the SDFM.
After that, I access the DMA RX buffer.
At this point, the SDFM data occasionally reads as 0 at regular intervals — for example, every 4th, 7th, or 24th cycle.

I suspect this issue may be due to the DMA and CPU accessing the same memory bus simultaneously.
I attempted to resolve the problem by relocating the memory regions as follows, but the issue persists:

  • DMA TX buffer → RAMGS0

  • DMA RX buffer → RAMGS1

  • SDFM data buffer → RAMLS4

Could you please advise what the root cause might be, and share any potential solutions?

Thank you.

  • 0
    TI__Mastermind 45606 points

    Hi,

    I'm not following your application and desired configuration. How are DMA, SPI, and SDFM being used together? RAMLS4 cannot be accessed by DMA either.

    Bae Kevin said:
    The PWM interrupt occurs at 50kHz, while the DMA RX interrupt is triggered approximately every 110–140kHz.

    Do these frequencies need to be synchronized (or de-synchronized) for some reason?

    Bae Kevin said:
    At this point, the SDFM data occasionally reads as 0 at regular intervals — for example, every 4th, 7th, or 24th cycle.

    Is SDFM getting reset by PWM or something? Can you verify new data exists to be read?

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Prodigy 80 points

    Hello,
    RAMLS is not accessed by DMA.
    In the setup described above, DMA is assigned to RAMGS0 and RAMGS1.
    SDFM is configured to be triggered by PWM11 and PWM12, and the PWM11 (50kHz) interrupt is used.
    Since Sync3 and OSR are set to 128, the conversion completes before the 50kHz interrupt occurs.
    Therefore, when the PWM11 interrupt is triggered, the SDFM has already completed the conversion, and the value stored in Sdfm1Regs.SDDATA1.all is read into the variable sdfm_data.
    I tried placing sdfm_data in RAMLS4.
    This was to test whether the issue was related to the RAM region, but the problem was not resolved.

    The DMA frequency is not synchronized with the PWM frequency.
    6 words of data are transmitted and received using a 10MHz clock.
    This is to explain that the DMA operation frequency is not consistent, since the PWM interrupt workload takes precedence.

    DMA is currently configured with Burst = 5, Transfer = 5, and SPI FIFO = 6.
    When it is configured with Burst = 0, Transfer = 0, and SPI FIFO = 1, the issue where SDFM reads zero at specific cycles disappears.

    Additional test results are as follows:

    1. When DMA is stopped, SDFM readings are all normal (every 50kHz).

    2. During DMA operation, if the line reading from the DMA RX buffer is commented out, readings are normal (SDFM is read first, and RX buffer access follows).

    3. During DMA operation, if a test global variable buffer unrelated to DMA is read, zero values appear at specific cycles.

    4. Separating the DMA TX and RX buffers to RAMGS0 and RAMGS1, and placing the variable storing SDFM register data into RAMLS4, does not resolve the issue.

    5. With DMA Burst = 5, Transfer = 5, and SPI FIFO = 6, zero values are read at specific cycles.

    6. With DMA Burst = 0, Transfer = 0, and SPI FIFO = 1, SDFM readings are normal.

    For accessing the same resource, only the CPU and CLA can contend with DMA.
    Between CPU and DMA, priorities are arbitrated by a hardware arbiter using round-robin logic.
    Between CLA and DMA, the priority is fixed via user MUX configuration.
    Therefore, there should be no relation to SDFM, which makes this issue quite strange.

    If the behavior mentioned above aligns with the order of processing in the interrupt service routine,
    then in the case of:

    "During DMA operation, if the line reading the DMA RX buffer is commented out, SDFM readings are normal",
    the SDFM result read is processed first in time, and commenting out a subsequent step makes the prior error disappear. This part is hard to understand.
    I assumed that there is no hardware-level correlation between SDFM and DMA—could this assumption be wrong?

    Due to the time difference, I would appreciate it if you could fully understand my question and list all the potential causes you can think of.
    I will perform all the suggested tests and get back to you with the results.
    Your assistance toward a quick resolution would be greatly appreciated.

  • +1 in reply to Bae Kevin
    TI__Mastermind 45606 points

    Hi,

    Is it possible underflow condition is occurring with SDFM or DMA? That you're reading from the memory space before new data arrives? un-synchronized behavior could be causing it even.

    Best,

    Kevin