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

TM4C1294NCPDT SSI1 DMA burst stalls after first ARBSIZE transfer

Pete Carston
Expert 1100 points
Other Parts Discussed in Thread: TM4C1294NCPDT, SEGGER

What I'm trying to do: Send a 16byte packet out of SSI1 using DMA Channel 11 on a TM4C1294NCPDT MCU.

What happens:
A burst of data is seen equal to ARBSIZE and the data is correct. Then nothing. If ARBSIZE is changed the burst size seen changes to match it. Can anybody see why the DMA doesn't continue after the first burst?

In IAR EW, if I halt the program, the DMASTAT register STATE shows the DMA controller stalled at the 0x06 state, which means 'Waiting for μDMA request to clear.' If I manually set and reset the TXDMAE bit in the SSICMACTL register I can eject the rest of the data from SSI1 Tx, which is also correct data. After the correct number of data bytes for the DMA transfer the transfer ends and STATE in the DMASTAT register shows the DMA controller halted at an 0x01 state, as expected.

What I've tried:
If I write an IRQ service routine to reset and set the TXDMAE bit each time it gets called I can get the SSI1 TX to send the complete 16 byte packet but it causes the routine to be continuously called and it's not the right way to solve the problem. It's the first time I've used DMA and I'm expecting to be able to set up transfer that will happen in the background and not have to service it before it completes.

What I think is going on:
I think I have a setup problem here but I can't spot it. I've been through the registers and looked at their settings and they check out. I 'think' that for some reason that SSI1 doesn't continue the DMA for a reason I can't see.

It's written in assembler, and before somebody says it, I don't have any interest in 'C'. I have looked at some of the TIVAware DMA setup routines but they make little sense to me.

I can post code if it helps, but here's what happens in order of execution in English:

SSI1 module initialised as a master. (This works fine for polled and and interrupt based transfers) The TX FIFO is enabled.

DMA module enabled - RCGCDMA Bit0 = 1
DMA controller reset using SRDMA
Wait for DMA controller to be available by polling PRDMA
Enable DMA controller - DMACFG = 1
Program channel control table base address using DMACTLBASE aligned to a 1024byte boundary in RAM.
DMA channel 11 assigned to SSI1 TX - DMACHMAP1 Bits 12:15 = 0x01
Set DMA Channel 11 to default priority - DMAPRIOCLR Bit11 =1
Enable DMA Channel 11 primary control structure - DMAALTCLR Bit 11 = 1
Enable single and burst requests for the channel - DMAUSEBURSTCLR Bit11 =1
Allow µDMA controller to recognize requests for channel 11. - DMAREQMASKCLR Bit 11 = 1

DMA Channel 11 DMA_SOURCE_END_POINTER is set to the last byte to be sent (16byte buffer - 1)
DMA_CHANNEL 11 DMA_DESTINATION_END_POINTER is set to SSI1 data register as the DMA destination is not incremental

DMA control word setup:
Destination address increment = 0x03 = address not incremental
DSTSIZE. Destination data size = 0x0 =8bit.
SRCINC. Source address increment. = 0x0 =8bit.
SRCSIZE  Source data size. 0x0 = 8bit.
Bits 22:23 reserved. Set to 0
DSTPROT0. Bit21 = 0 = The write access is non-privileged.
Bits 20:19 reserved. Set to 0
SRCPROT0. Bit18 = 0 = The write access is non-privileged.
ARBSIZE = 0x02 = 4 to match FIFO level.
XFERSIZE =15  = transfer 16 items
NXTUSEBURST Bit3 = 0
XFERMODE = #0x1 = Basic mode

Enable DMA channel DMAENASET = 1
Enable DMA for SSI1 TX FIFO in SSI1 module, TXDMAE in SSIDMACTL set to 1
Enable TX DMA IRQ (DMATXIM) for QSSI1. In DMATXIM in SSIIM is set to 1



  • 0
    TI__Guru**** 244380 points
    Hello Pete

    If the issue is reproducible on the first run, then I would prefer the C code/project for debug.

    Regards
    Amit
  • 0
    Guru 117855 points

    Pete Carston said:
    before somebody says it, I don't have any interest in 'C'.

    Good for you, Amit!

    When one deliberately, "Culls oneself from the herd" the "herd" may not, "have any interest" in assisting...   (especially when the assistance is so gravely complicated)

    Poster's "adamancy" clearly missed the, "big picture" here - "What if each/every poster" demanded (only) DRM or ASM code review?   Would not this forum, "Grind to a Halt?"   Is that good - should it not be resisted?

    We feel for the poster - but he's "cast off" (knowingly) into high seas... rescue may not be quick/easy.   (as it surely could be w/(some) "C" interest...)

  • 0 in reply to Amit Ashara
    Expert 1100 points
    Hi Amit,
    The issue is 100% reproducible and it does nothing else. But like our troubleshooting of the EPI port the code is assembler and not C. If I could easily write C I'd of put it up.

    I was hoping that somebody who knew how the TM4C1294 worked at a fundamental hardware level, not an API level, would be able to spot what the problem was. I would guess the issue is with the SSI module setup as the data can be driven out of the SSI TX in ARBSIZE bursts each time the TXDMAE bit is manually reset and set again. So it would appear the DMA is setup, functional and active.

    To say "I don't have any interest in 'C'" is a personal choice and not a demand on the forum. Whether somebody chooses to assist is their choice. Granted, each person has their own workload and their own preference as to programming language. Fortunately the TM4C range is backed up by a good datasheet which is better than many, and assembler for it is easy to write, it's one of the reasons as to why I picked it.

    I've looked at learning C before, but find the syntax abstract, and divorced from the Silicon. I'd guess it depends on your intended application, but it doesn't help in much of what I'd want to write on such a device. For me, using a particular device starts with the datasheet and I like to use a programming language that directly reflects it.

    Amit has been kind enough to assist in the past and it's been much appreciated. But I don't expect somebody to spend a long time over the problem, but the ability to put something up for people to look at and maybe chip in, is most useful.
  • 0 in reply to Pete Carston
    TI__Guru**** 244380 points
    Hello Pete,

    I am that "somebody" (not being arrogant but having worked on the SSI). Even if you can share the bin file that is more than enough to see why the issue is happening. C language only gives it form to co-relate the HW and the SW.
    My main role here is to not only assist our customers but also look for an issue and make sure that if it is indeed one then we errata with WA.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1100 points
    Hello Amit,
    Thankyou for that. I'll strip the project right down to its bare bones which will much reduce what there is to look at, and post it up.
    I'm seeing a few posts on the group, some going back quite a while, some of which belong to TM4C123G that have similar issues and as I find them I try to remedy what's wrong, but just haven't hit it yet. I'll post again when I've got something for you.

    I'd love to be as proficient in C as some are but having tried to get into it a couple of times assembler is an easy fall back and I find it very easy to write.

    Pete
  • 0 in reply to Pete Carston
    TI__Guru**** 244380 points
    Hello Pete

    TM4C123x DMA-Peripheral Interaction architecture is different from TM4C129x. But there are some similarities as well. However this cannot explain why DMA stalls. Looking forward to your code.

    Regards
    Amit
  • 0 in reply to Pete Carston
    Expert 1100 points

    IAR EW v7.30 TM4C1294NCPDT DMA with SSI1 Setup.zipHello Amit,

    I've reduced the project down to a bare minimum code that demonstrates the problem. The code is 984bytes and half of that is redirection for unhandled vectors. The IRQ service routines I've previously experimented with are not included because I'm not sure they're valid. Much of the register writing has been simplified to single writes to compact the code, the original used read-modify-writes for everything. Again the change made no difference. The code currently attempts to output what ever is in the SRAM at the time and makes no attempt to set up the buffer contents.

    The Zip file contains the entire IAR Embedded workbench directory so if you do have access to that you should be able to import it. But I know you mainly use CCS.

    The binaries / ELFs the package drops are in the debug directory. Hopefully one of the those will be what you mention. If not give me a shout and I'll see if I can get it to output what you need.

    The code has been set up to try to write a 256byte buffer to the SSI1 TX FIF0. I haven't changed the SSI1 prescale values since the 1294 ran at 120MHz but the system behaves in exactly the same way, just slowed up since I've removed the PLL code.

    Any help much appreciated.

    Kind regards

    Pete

  • 0 in reply to Amit Ashara
    Expert 1100 points
    Hi Amit,
    Indeed it is different and I have a TMC123x board here too. When I've ground to a halt for ideas, sometimes reading about similar devices does provoke thoughts worth trying. It was some of the postings for TMS320 DSP, I think, that provided additional lines of attack to look at the TM4C1294 EPI problem when that was on the bench.
    The DMA > SSI1 code, I feel is one step away from running. There's several posts/problem on this forum, some of which you were instrumental in solving, that seem to revolve around a possibly similar issue but I've yet to realise what it is. To me it's what happens after that first burst write to the SSI1 - the exchange needs to something complete its cycle, which it doesn't get. If it was in one of the the other DMA modes I'd be looking at the alternate control structure for answers. My first suspicions were I was lacking something in the way of setup and it was fouling the works. This is still my suspicion. While it'd take me an age to code the DMA routines in C, with knowing the 1294 device well now, I can now read C setup stuff for it knowing what it's aimed at and make sense of it. Unfortunately the routines I found were for TMC123 and like you say it's not quite the same.
  • 0 in reply to Pete Carston
    Expert 1100 points

    Hi Amit,

     I've had a go at trying to convert the code to CCS. I couldn't use CCS6 as it doesn't support the Segger Jlink probe I have. So it's in CCSv5. I came to try to run it and then met the problem that the free version of CCS5 doesn't support the Jlink either despite it installing it. And then we were into licensing issues, so I've ditched that. The code is erm....a bit crazy. I realised that CCS doesn't support MOV32 pseudo-ops and for some reason I couldn't get it to be happy with .equ statements, so I stripped them out. So it's fairly butchered!

    I can't figure out how to declare an entry point. I was expecting to be able to declare a reset vector somewhere and that be enough. But how?

    No errors are trapped anywhere, so if it goes bananas, it really will go nuts.

    Is it fixable/usable? Without much effort?

    DMA_for_SSI1.asm

  • 0 in reply to Pete Carston
    Guru 117855 points

    Pete Carston said:
    Is it fixable/usable? Without much effort?

    One suspects that's (more properly), "Without much (more) effort?"

    I'm sympathetic to your cause - you've clearly made significant time/effort in your attempts.   Yet - I believe a very "flawed" initial decision has impaled you - and the wound is likely to spread!   Consider this:

    a) Most all forums exist to serve the majority - your use case is far outside that which is "normal/customary" here

    b) Amit has set records for, "number of posts answered each day."   Thus this must be a directive from management.   The effort your issue requires must cause other posts to "sit" - or will demand extra time/effort from Amit.

    c) For your personal projects & development - surely the declared, "Always & Only ASM" will lead to similar (rather predictable) "dead-ends!"   The "herd" codes in dreaded "C" - has for quite some time now - and each/every example is thus coded.   Your "avoidance" of that rather terrific (code asset) will prove harder & harder to justify.

    I'm hopeful - for both you & (friend) Amit - that he's able to (quickly) wade thru the (pardon) code swamp - and get you on track.

    That said - I believe a revisit to your (past) decision of, "ASM only" is very much warranted.   Surely you've made progress - had some success - but I guarantee that those same results would have been achieved spectacularly: "more quickly, more easily & more robustly" when "hooked" (and immensely aided) by the volumes of existing API code (w/examples) - which exist entirely in "C."

    While your post here appears a, "One time" issue - the "dead-end" you've encountered may well serve as a, "Wake-Up" call (and/or "alert") that it is time to, "Join the "C" herd!"

  • 0 in reply to Pete Carston
    TI__Guru**** 244380 points
    Hello Pete,

    The ARBSize must be set as 0x3 = 0x8 to match the FIFO depth. Also in the initialization sequence the SSI controller needs to be enabled before the DMAE bits are set.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1100 points

    Hi Amit,
    Thankyou for that one. :) I've just been testing it out, and yes, it fixes the problem. It needs both settings too. I was expecting it to maybe work just getting the order of the DMAE bit setting correct, having read what the datasheet says about bursting 4bytes max into the SPI FIFO. Really it's like an extra mode not mentioned in the sheet.

    So, just to clarify for folks that follow:

    Setting the Bit11 in DMAENASET and then the TXDMAE bit in SSICMACTL after the DMA and SPI interfaces have been initialised, when ARBSIZE is set to 0x03, has fixed the problem.

    Cheers Amit, you're a star.....again!

  • 0 in reply to cb1_mobile
    Expert 1100 points
    Hello cb1,

    Thankyou for taking the time to write. Even the sarcasm is appreciated :) It's not so much a wakeup call as out of necessity at the moment, I need something standalone with all the speed the 1294 can muster for a task with moderate intelligent and decision making, in some respects more of a logic replacement task.

    But I'm aware that 'C' is probably the predominant language for embedded design now and also that the TM4C range is supported more than most in this respect. It has a very good spread of APIs for it, which I would love to be able to use, especially as I move to systems that are more connected to the likes of Ethernet. I would also prefer to be contributing to bug fixing an existing widely used library rather than writing from scratch.

    With the advancing scale of things it's also very apparent that the interface to a lot of Silicon is now the API and the 'internals' stay internal. That has to happen for things to scale. So I guess what you're seeing here is somebody in transition from Assembler into hopefully something higher level, which hopefully/probably will be C when I get my head round it.

    Cb1, would you recommend a resource for learning more about the [dreaded] C? I have been looking round for one and the best I have come across is Miro Samek's YouTube course for Embedded Systems Programming. It was this that got me much further than the attempt maybe 10 years ago. Miro's teaching style and delivery is very accessible. I need to concentrate on how to actually use the APIs and general plumbing. The C syntax I'll have to bear with until it becomes second nature. At least I know what it's aimed at underneath.

    You'll also no doubt be reassured that I don't spend all my time in a high-level language such as Assembler. And for that I usually use a SuperCoder2000 keyboard as it speeds the throughput. I upgraded to the water-cooled version of it last year and it was well worth the extra 5 Shekels.
  • 0 in reply to Pete Carston
    Guru 47900 points

    May I note that we're delighted for you - and again kudos to Amit.

    With that said - one wonders if the API might have covered the (apparent) required sequence of function calls - in this particular instance.   My group has noted that in several other areas the "sequence" of calls - not just their inclusion - proves critical.     Again - the time-test API (usually) automates this process.

  • 0 in reply to cb1
    Expert 1100 points
    I would say that it's likely that the API will take care of the sequence of calls/settings, especially if the issue hasn't been raised before. And that I would also expect their order to critical to the process. But the fundamental offering on the device is its datasheet. It's already good, but maybe it just got better.
  • 0 in reply to Pete Carston
    Guru 117855 points

    Again - I'm glad for you (and for Amit) - and the others who (one day) wander across this thread.

    I don't believe I've been sarcastic - I write my beliefs - try my best to "justify" my recommendations & findings.   I continue in the belief that while you're no longer "dead-ended" here - your expansion into "C" will prove most worthwhile.  (if you'd be good enough to id any "sarcasm" - I'll review - and apologize if that's noted...)

    Most courses & texts have not yet advanced to embedded C - yet my quick visit to Google reveals 520 million "hits" in answer to, Embedded C.   As you know your learning style best - makes sense for you to scan 1st 5 or so pages - read excerpts.   Most of the programmers and/or engineers my small firm hires know C - two books my firm uses regularly are the "bible" "The C Programming Language" by "K & R";  "Programming in C" by Miller & Quilici; and "C Programming Guide" published by Que - which has a very useful, fold-out handout - for ready reference.   Unfortunately I've not encountered Miro's course - but if you enjoy it - and invest in 2 or so well liked C books - I don't see you regretting that action.

    I learned C before there were C versions for small MCUs - we could program (only) in beloved ASM.    And we "flew/dove" into C - just as soon as it moved from the PC to our tiny, enfeebled 8 bit Eprom coded beasties.   What will make your C learning so enjoyable is the presence of these small eval boards - which quickly/easily accept your small programs - and provide near instant "feedback."    Even an Led's "answering" your GPIO or PWM with its "glow" - still feels good.

    I've no doubt that, "Slow, steady learning works best."   Going too fast absorbs most of the joy - have fun and you'll (dare I say) never (well rarely) "Look back."