• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 1463 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.

uDMA and SPI: unspecified interrupt source SSI_DMATX?

Janos
Intellectual 570 points

Hello friends,

i am using the uDMA module to transmit data via SPI. The processor is the TM4C1231H6PMI. To determine, when the transfer is complete, i have got the information from somewhere, that i can use the SSI interrupt SSI_DMATX, e.g. 

SSIIntEnable(SSI0_BASE, SSI_DMATX);

This works well enough. However, now i want to get deeper into analyzing the timings here, and since the interrupt seems to be thrown a little bit earlier than the actual data transmission is complete, i want to know how exactly this interrupt source is specified.


Surprisingly, SSI_DMATX doesn't seem to be specified at all. May this be the case?

In the TivaWare™ Peripheral Driver Library USER’S GUIDE it only says:

Description:
This function enables the indicated SSI interrupt sources. Only the sources that are enabled
can be reflected to the processor interrupt; disabled sources have no effect on the proces-
sor. The ui32IntFlags parameter can be any of the SSI_TXFF, SSI_RXFF, SSI_RXTO, or
SSI_RXOR values.

In the driver library, the macro resolves to the bit 0x20 in the interrupt register:

// ssi.h
#define SSI_DMATX               0x00000020  // DMA Transmit complete

However, in the datasheet (DS-TM4C1231H6PM-15553.2700), the bit 0x20 is specified as reserved in Register 6: SSI Interrupt Mask (SSIIM), offset 0x014.

I need to know the exact behaviour of this interrupt, though. Am i using the documentation incorrectly, or is my documentation not up to date?

Cheers,

Janos

  • 0
    TI__Guru**** 244400 points

    Hello Janos,

    The SSI_DMATX bit is not there for TM4C123 but for TM4C129 onwards. Also when the DMA is used only the error interrupt is allowed to go to the CPU, while the DMADONE is routed on the same peripheral interrupt vector.

    So to get around this, when the DMADONE is asserted, the CPU should wait for the SSIBusy to deassert, which would indicate all data bits have been transmitted as well

    Regards

    Amit

  • 0
    Guru 117855 points

    Janos said:
    i have got the information from somewhere

    You are proving to be both thoughtful & determined - great addition to this space.  And - our group suffered from that exact, (inexact?) "from somewhere" data harvesting dilemma.  But no more!

    We now keep "Word/similar" always open - at the ready - and, "demand/enforce" that any/all such, "data harvests" be duly pasted - with source clearly/completely identified!  Spectacular improvement results - and this process can be very well: managed - categorized and updated by, "part-time" or young/new intern staff.  Those items captured via conversation,  seminar or other non-PC methods may be handwritten or phone/tablet entered - and then routed to the appropriate data assembler.

    Organization proves critical to small biz - wasted time/effort is hard to recover - this is one method to reduce/prevent such...

  • 0 in reply to Amit Ashara
    Intellectual 570 points

    Hi Amit,

    thanks for your advise. I can now see why i didn't find information about the interrupt sources.

    Could you please clarify what you mean by "DMADONE"? I don't find that term anywhere in the TM4C123 documentation, and neither see any similar interrupt source that can be used.

    Quite the opposite, for the TivaWare driver library, there are only the two interrupt sources UDMA_INT_SW and UDMA_INT_ERR available. The error source is only for uDMA errors, and the UDMA_INT_SW source signals the end of transmission for the software channel.

    TivaWare™ Peripheral Driver Library USER’S GUIDE said:
    Note:
    The interrupt handler for the uDMA is for transfer completion when the channel
    UDMA_CHANNEL_SW is used and for error interrupts. The interrupts for each peripheral
    channel are handled through the individual peripheral interrupt handlers.


    Following the instruction and using the peripheral interrupt handler - SSI_TXEOT for the SSI peripheral - seems to have the same effect as using the unspecified SSI_DMATX source. This works ok and the specification for this EOT source is sufficient.

    I wouldn't need any busy waiting for SSIBusy() anymore, and could start the next uDMA transmission to this peripheral right away, is this correct?

    cb1_mobile said:
    You are proving to be both thoughtful & determined - great addition to this space.  And - our group suffered from that exact, (inexact?) "from somewhere" data harvesting dilemma.  But no more!

    @CB, i should feel flattered here - but to be honest i doubt to get your point here completely. Admittedly, my attempts to roll out my sources as much as possible totally lacks when it comes to "from somewhere". I should have mentioned, that after all the TivaWare library itself suggests to use that interrupt source, specifying the macro in the ssi.h header file. For me, it is not uncommon to use source/header files as documentation. I should have also mentioned, that the code works very well, and i only wanted to understand more about it, e.g. how it works.

    Could you please clarify on your comment? I'd be very interested in that!

    Thanks for all your support!
    Cheers
    Janos

  • 0 in reply to Janos
    TI__Guru**** 244400 points

    Hello Janos,

    Quite simply, the DMADONE is the signal indicating that the DMA has completed the task as programmed in the task list.

    In TM4C123 the DMA Completion interrupt is given on the Interrupt line for the peripheral it is transacting with, As an example if the DMA is doing a transfer to/from SSI, then on DMADONE, the interrupt Handler for SSI will be called. Int he Interrupt Handler the CPU has to check if the DMACHIS is set for the SSI channel. During this time the SSI TX and RX interrupt Source will be masked.

    The EOT is the true indicator of the last bit being moved out from the SSI Shoft Buffer, so it would be OK to have the same. But do note that SSI TX and RX interrupt sources do not work when DMA is being used.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 117855 points

    Amit Ashara said:

    The EOT is the true indicator of the last bit being moved out from the SSI Shift Buffer...  do note that SSI TX and RX interrupt sources do not work when DMA is being used.

    Amit - hi and thanks for this.  I'm unclear! (maybe others, too)   Are you saying here that the SSI's EOT indicator does not work when SSI is used as one element of a uDMA transaction?  (wording quoted leaves that in doubt)  Merci...

  • 0 in reply to cb1_mobile
    TI__Guru**** 244400 points

    Hello cb1,

    Irrespective of the EOT bit being set the interrupt is given on the SSI_TX interrupt status. When the DMA is being used and EOT is clear we would get only DMA completion interrupt. When the EOT bit is set, and looking at the transmission and interrupt assertion, a second interrupt will be asserted when transmission is cleared from the buffer.

    Regards

    Amit

  • 0 in reply to Janos
    Guru 117855 points

    Janos said:

    Could you please clarify on your comment? I'd be very interested in that!

    Attempt follows - our group uses ARM MCUs from multiple sources - making us even more vulnerable to the, "Reduced ability to "refind & further examine" an earlier found & logged tech fact or nugget."  (Say What?)  For example - we insist that tech staff review tech files (always) w/Word or similar open.  When a key piece of data is found w/in (say the MCU manual) we simply, "copy/paste" that key data into Word.  The resulting word document thus serves as a, "repository" (library) for key tech data - and by being smaller is far easier to use and contains the "essence" of our needs and objectives.

    At the same time those key sentences/paragraphs are copy/pasted - we insist that the source's full identification be logged - right then - right there.  Thus - your earlier, "found somewhere" is avoided!  That's critical - especially when the sources are many - and dynamic. (rev a,b,c etc.)  We learned this trick (and many others) while being coached as we were, "going public" w/past tech firm.  Financial, legal, tech - all cascading around you - if you cannot efficiently manage the data - you're sunk!  Dealing w/tech clients today - we see endless examples of, "cannot find, cannot resolve issue & perform" when such discipline is not regularly and formally applied...

    Anticipating the potential problem - implementing an effective safeguard - seems preferable to, "Where did we find this!"  (not to ask the (past) source of that quote...)

  • 0 in reply to Amit Ashara
    Intellectual 570 points

    Amit Ashara said:
    The EOT is the true indicator of the last bit being moved out from the SSI Shoft Buffer, so it would be OK to have the same. But do note that SSI TX and RX interrupt sources do not work when DMA is being used.

    Thanks Amit, that makes sense.

    I just noticed that the EOT interrupt source isn't available on the TM4C123 either. The results that i'm seeing is just as you described earlier, that is, my interrupt routine is invoked on the so-called DMADONE event.

    That is quite suffiecient for me, and if i wanted to know the actual end of transmission (EOT), with the TM4C123 i would have to go with busy waiting from there.

    @CB

    Thanks for your great explanation! That makes a lot of sense, and your teams approach should be a good example for me and for others.

  • 0 in reply to Janos
    TI__Guru**** 244400 points

    Hello Janos,

    The EOT is not available as a separate interrupt source but the TX interrupt bit has two meanings.

    If EOT is cleared then it is a buffer level interrupt.

    If EOT is set then it is the actual EOT interrupt

    Regards

    Amit