• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 385 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DK-TM4C129X: UDMA_INT_SW in driverlib/udma.h not expected value

Peter Jaquiery
Intellectual 635 points

Part Number: DK-TM4C129X

I'm working with uDMA on the TM4C129 series processor on the DK-TM4C129x development kit. The code performs a software memory to memory scatter / gather transfer then does a little clean up in an interrupt routine following the transfer.

I have this code working, but during development I noticed that the udma.h provided value for UDMA_INT_SW is 62. The correct value seems to be 60. The relevant parts of my working code are:

tDMAControlTable sUnpackTaskList[kMaxChan];

void UnpackSamples()
   {
   ...
   }

void DMAManager::SetupSampleTransfer()
   {
   ...
   // Note UDMA_INT_SW in udma.h seems to be incorrect (62)
   uDMAIntRegister(60, UnpackSamples);
   uDMAChannelAttributeEnable(UDMA_CHANNEL_SW, 0);
   }

void DMAManager::TransferSamples(...)
   {
   ...
   uDMAChannelScatterGatherSet(UDMA_CHANNEL_SW, 8, sUnpackTaskList, 0);
   uDMAChannelEnable(UDMA_CHANNEL_SW);
   uDMAChannelRequest(UDMA_CHANNEL_SW);
   }

The TM4C1294kcpdt Microcontroller datasheet lists "uDMA Software Channel Transfer" interrupt as 44 which is consistent with 60 as the exception number per the vector table shown in Figure 2-6 (60 = 44 + 16).

It seems unlikely that such an error in the udma.h header has gone unnoticed. Is there something silly I've missed here?

  • 0
    TI__Guru 72500 points

    Please update to the latest version of TivaWare, version 2.1.4.178. This issue is corrected in the latest version.

  • 0 in reply to Bob Crosby
    Intellectual 635 points

    Thanks for the quick feedback Bob. However it's not a magic bullet. Turns out I had already installed the current version of the library, but I couldn't figure out how to get my CCS project to use it (I still can't).

    Even had I figured that out, there would still have been pain waiting for me: the macro name has changed and the definition has jumped from udma.h to <processorHeader>.h (tm4c129xkczad.h in my case).

    As an interesting aside I noticed the following code in udma.c:

    void
uDMAIntRegister(uint32_t ui32IntChannel, void (*pfnHandler)(void))
{
    //
    // Check the arguments.
    //
    ASSERT(pfnHandler);

    //
    // Register the interrupt handler.
    //
    IntRegister(ui32IntChannel, pfnHandler);

    //
    // Enable the memory management fault.
    //
    IntEnable(ui32IntChannel);
}

    Note the "memory management fault" comment. I'm pretty sure that's not right!

  • 0 in reply to Peter Jaquiery
    TI__Guru 72500 points
    Thanks for the feedback on the incorrect comment. I will submit that issue to our bug tracking system so that it can be corrected in the next release.

    Would you like help converting to the latest version, or would you prefer to just continue using your corrected code?
  • 0 in reply to Bob Crosby
    Intellectual 635 points
    On the basis of "Don't fix what ain't broken" (for a given value of "ain't broken" in this case) I'll run with what I've got unless you have a compelling reason to change. ;-)
  • 0 in reply to Peter Jaquiery
    TI__Guru 72500 points
    I am also a strong believer in "If it not's broke, don't fix it". Thank you for your feedback.