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.

RTOS/TM4C1294NCPDT: uDMA error in high performance application

Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

Hello,

I develop high performance application with TM4C1294 MCU with TI RTOS - ADC sampling with uDMA ping pong buffers 20 Channels x 100 kHz, SPI sampling 1 kHz and outputs streaming with UDP packets (cca 35 Mbit/s). I have also a NDK web server for configuration the application with simple forms. The CPU load in RTOS viewer is about 30%.

I have problem with freezing MCU because of uDMA error. The problem occurs when all streaming inputs are enabled and I open web pages in MCU.

I have no idea how to debug uDMA error,  what is the couse and how to solve the problem.

Is in NDK any way to detect when http server is active? Maybe the one of the solutions can be temporarily disable streaming when somebody open web pages.

Thank you for answers.

Jiri

  • Jiri,

    Looking at uDMA documentation, the error treatment ain't too explicit indeed. But here are a few ideas:

    You could try to enable the DMA interrupt, and debug the error inside the ISR. Tivaware provides uDMAErrorStatusGet() to start with.

    Since the possible error on the documents refer to a "bus or memory protection error", I'd say you try to look at:

    - Is the destination address still valid? Maybe you are incrementing it into a off-boundary value?

    - Are you overloading the bus, trying to transfer data faster than the bus can handle?

    When an error occurs, the uDMA channel that caused such error gets disabled. Not too easy of a situation to debug, but you could try to read the registers and check what channel "you expected to be enabled and no longer is..."

    Bruno

  • *** LIKE *** (yet (intensely) DISLIKE forum's (claimed) upgrade - which harpooned the much appreciated, "LIKE.")
  • Thank you for helpful answer. I have some additional questions:
    - Where do you find the uDMA documentation? I have found only one chapter in datasheet.
    - I think the error is because overloading the bus. Is there any technique to detect the overloading? What is the maximal troughput the uDMA?

    Thank you for answer
  • Jiri,

    As for documentation:

    - Did you install Tivaware? Go to your ti/tivaware_xxx/ docs/ folder, and check the file SW-TM4C-DRL-UG-xxxx. That is the driverlib user guide, which is actually really helpful not only for understanding the library itself, but for a better understanding of what each peripheral can do.

    - Our colleague poster Luis Afonso has this site with some interesting examples for DMA, in case you haven't yet seen:

    https://sites.google.com/site/luiselectronicprojects/home

    This old post have some basic insight as well: e2e.ti.com/.../1270766

    I don't know the max TP of the DMA. The available information does not seem enough to figure it out... The transfer is based on the main clock cycle, but I'm not even sure if the transfer from any source to any destination is deterministic or not, and how many cycles are that - perhaps other posters or TI folks could clarify it. Docs state that each channel is independent, but are you always using separate channels? If you try to transfer something on the same channel "a few (how many?) cycles" after the previous transfer was initiated, most likely it will be busy.

    There's also additional processing time required for reconfiguring the DMA control table, which is a RAM location that takes normal processing time to happen. This is somewhat separate from the transfer itself, but depending on how your multiple transfers are structured, can impact.

    Other point: did you make sure you are using just one control table? I've seen people wrongly creating one table for each DMA periph and messing things up.

    Cheers

    Bruno

  • I have solved my problem.

    When http server has a client, the sampling of the ADC and SPI are disabled. That works fine. The problem was probably in overloading the bus.

    Thanks for helpful answers.

    Best regards

    Jiri

  • Does not your "solution" defeat your (initial) stated desire for, "High Performance?"     Somehow - "disabling vital functions" seems to (rather drastically) reduce performance...

    Normally those ADC measurements - and their communication (via SPI) - are "high priority" - and (may) be being sacrificed in favor of your server client!      Can that be good?      (it is NOT high-performance)  

    Would not "continuing ADC & SPI operation" - yet NOT via µDMA (while server client is allowed to dominate) provide a "better compromise?"     (i.e. "some" throughput trumps NO throughput!)