DMA Parallel Port Output/Byte Stream with seperate ADC capture

I would like to discuss the use of DMAE0 in more depth - how can I use it?

So far I have, 

1. Place first byte on the port
2. Start Timer
3. Make a CCR set the WE pin high on the first clock edge (flash write strobe)
4. Make a second CCR set the DMAE0 high to trigger DMA to transfer next byte from RAM to the Port. As the DMAE0 is an enable pin - the DMA gets to work.
5. CCR0 resets the time once enough clock edges have been to allow the DMA to complete its single-repeated transfer.

How long should I give the DMA to complete a transfer? I will wait for the DMA ISR in lpm0 so 5 clocks seem right to you guys?

My question - what would the settings?
TAx.CCR0 = 2 + 5 (DMA Clks?) -1 (because I get a free edge due to timer reset)
Tax.CCRx (DMAE0) = 2 (probably could be a one)
Tax.CCRy (write)     = 1

Thanks for your help. 

James Hillman said:

DMA0 ISR (buffer full) -> Triggers DMA1 to transfer RAM Ping to RAM Pong
DMA1 ISR (transfer done) -> Set main flag to setup flash write (which uses DMA2)

DMA0 can trigger DMA1 without ISR.

Also for DMA1 -> DMA2 but probably you need some setup ISR and then it becomes tricky, if now ADC is ready the DMA trigger will be lost and end of game.

James Hillman said:

2. Experiment with the external DMA trigger - as suggested by Leo. However, the manual says "

When DMALEVEL = 1, transfer modes selected when DMADT = {0, 1, 2, 3} are recommended because
the DMAEN bit is automatically reset after the configured transfer."  Will this be a problem for me if I use the mode 4 (repeated single transfer) as I do currently. I just need the DMA ISR to fire when DMAxSZ and then I will stop the DMA2 as soon as I can - I don't mind if it overruns. 

This was just an idea I don’t have experience with it, you have to check it.

Hi everyone,

I have now convinced myself that the ISR is the cause of my DMA issue. However, the discuss so far has leaned towards the idea of the DMA missing a trigger during an ISR firing. The impact of this is that the data on the parallel bus does not change and it would be repeated into the flash. However, what I actually see is that I lose a byte - you will see below that I should have received two 0x00 bytes. To me, this is either caused by the DMA starting at the wrong address, the dma triggering correctly but the flash didn't see the WE or that the dma falsely triggered. Thoughts? 

e.g. expected  0x00, 0x02, 0x04 (sent  00, 00, 02, 00, 04, 00) and I get ( 00, 02, 00, 04, 00 06) which is 0x0200, 0x0400, 0x0600. 

This happens once every few writes. 

James Hillman said:

Therefore I am not using the ADC as the DMA trigger. 

Sorry, I misunderstood your setup.

Well, as I wrote, CPU execution, whether in main or inside ISR, is interrupted by DMA the same way. The CPU has no "I'm in ISR" mode where it behaves differently from any other code where GIE is disabled.
The only moment where it doesn't follow a normal CPU operation is the initial ISR latency, when it reads the vector and prepares for running the ISR. I don't know whether a DMA at this moment might cause problems. But it would be surprising.
You may try setting the RMWDIS flag.

In a different thread, someone noticed that accessing the UCA0 registers during an UCB0 DMA transfer causes the DMA to deliver corrupt data. This issue hasn't been solved yet.

Well, DMA seems to be a bit more sensitive than it should.

For your situation, what do you think of this setup:

Timer triggers ADC. ADC results are moved by DMA0 to RAM in repeated single transfer mode, triggered by ADC.
DMA0 triggers DMA1 when the buffer has been filled. DMA1 moves a config byte to enable the transfer trigger mechanism for DMA2 (e.g. start the timer).
DMA2 ISR resets the transfer trigger and re-arms DMA2 while DMA0 and DMA1 in repeated modes are already armed.

Only one ISR that has nothing to do than to disable the trigger for DMA2 and rearm DMA2. And it is not time critical.

However, this setup only works if you're using just one ADC channel, as DMA0 cannot loop the source address by 16 and the destination by 8k.

James Hillman said:

"When DMALEVEL = 1, transfer modes selected when DMADT = {0, 1, 2, 3} are recommended because the DMAEN bit is automatically reset after the configured transfer " Will this be a problem for me if I use the mode 4 (repeated single transfer) as I do currently

The problem is that with DMALEVEL=1, Transfers will be done with maximum speed as long as the trigger is set. That means there is only a small time window in which the external hardware can detect the write and clear the trigger, or you'll be sending with MCLK/2 Hz.

With internal peripherals, this might work. However, DMALEVEL=1 is only recommended for external trigger DMAE0, not for peripherals. Maybe exactly for this reason:

"For proper operation, level-sensitive triggers can only be used when external trigger DMAE0 is selected as the trigger. DMA transfers are triggered as long as the trigger signal is high and the DMAEN bit remains set."

Likely, the DMA might have started the next transfer already, when the peripheral notices the transfer and resets its IFG bit. Especially if the trigger comes from the destination (e.g. TXBUF).

James Hillman said:

1. Look at one of the MSP430 5 series which has more RAM.

Interesting detail: 16 of the 64k are mapped to low memory as well as high memory. So you could use up to 48k for buffering, using 20 bit DMA addressing, while your program only uses small data model with 18k low ram.

Jens-Michael Gross said:

For your situation, what do you think of this setup:

Timer triggers ADC. ADC results are moved by DMA0 to RAM in repeated single transfer mode, triggered by ADC.
DMA0 triggers DMA1 when the buffer has been filled. DMA1 moves a config byte to enable the transfer trigger mechanism for DMA2 (e.g. start the timer).
DMA2 ISR resets the transfer trigger and re-arms DMA2 while DMA0 and DMA1 in repeated modes are already armed.

This is almost the current scenario!

Jens-Michael Gross said:

Only one ISR that has nothing to do than to disable the trigger for DMA2 and rearm DMA2. And it is not time critical.

What you don’t want to understand is; Triggering the DMA directly from another peripheral and also using, any, ISR will lock the DMA! James has, as I believe, slowly on recognized this issue now.

The DMA has an edge-sensitive trigger, which means (in this case) a low to high transition triggers the DMA, when this happens during servicing an ISR the transition will not been seen by the DMA. If any difference, setting the RMWDIS bit will make it only more worse.

Hi Leo and Jens,

Thanks for spending your energy on my problems! 

Leo Bosch said:

What you don’t want to understand is; Triggering the DMA directly from another peripheral and also using, any, ISR will lock the DMA! James has, as I believe, slowly on recognized this issue now.

Leo - I have come to believe this is the case. But why? Is this TI official? How did you come to know of this? I feel it is rather big flaw - do you agree? 

I personally feel I must be doing something wrong... my most recent idea has been to move my time critical code out of main and split it across the appropriate ISRs - as its only once every few page writes which suggests some variation in timings. Would you happen to agree with this statement?

Something like this:

DMA0 ISR = ADC has reached the pre-filled point in the RAM BUFFER. Reconfigure DMA0ISR for remaining bytes. Also, start the write send within this ISR which ultimately enables DMA2. *This way I remove the latency of the main loop. However, I might miss a sample!

DMA0 ISR fires again, the buffer has been filled. Reconfigure. *okay, so this might 'lock up' the DMA but now some of the jitter has been removed, it might, just might, be always working.

DMA 2 ISR fires - DMA write complete, wrap up flash write.

James Hillman said:

Is this TI official? How did you come to know of this?

Same as you; Spending a lot of time on it. I have a product with a stressed MCU with a few time critical ISR’s, and in-between the ADC data needs to be saved and tries to do that with DMA, no way! Searching TI site and try’s to understand how DMA works learns me not to use DMA in such a cases. And have to deal with some missing ADC data.

In your case I would try:

Timer starts ADC.

ADC ISR stores data to the right place, like your DMA0 supposed to do. Check if DMA1 = ready and trigger DMA2 if needed. Count the stored ADC data and if complete trigger DMA1, exit ISR.

Hi Leo, 

1.Could you please re-explain your suggestion - I am generally confused...

Timer B -> ADC -> ADC ISR -> RAM BUFFER.

ADC ISR -> RAM BUFFER FULL -> ????

2. Your experience

Do you think this issue could cause an extra trigger too? I am not seeing a missed trigger but the DMA seemingly doing a transfer before the first trigger?

Many thanks,

Let’s first confirm what exactly has to be done (maybe I’m lost):

You want to read, let’s say 5 ADC-channels, store them to RAM buffer. This 100 times so you have 500 readings and copy these 500 to a flash device and start over again. Is this correct?

Leo Bosch said:

This is almost the current scenario!

Almost. The key difference is that there is only one ISR and it is triggered when the buffer has been sent. With lots of time. It could as well be polled by main without timing problems.

However, thinking again about the whole topic, there is another possible explanation. It has nothing to do with ISR or not. It could be that accessing a peripheral during a DMA transfer causes problems. Any peripheral, perhaps. In case of peripherals with waitstates (e.g. hardware multiplier), this is a know erratum. Not really coincidentally, chance that a peripheral register is accessed during DMA is much higher in an ISR because usually ISRs are called to handle some peripheral event.

Hi Jens, Leo and others! 

I have been busy and found the root cause. I had not configured my sampling timer (Timer B, which triggers the ADC) correctly: as I had intended. It was configured to trigger the DMA and to call the ISR. The code went from this:

TB0CCR0 = 1; //roll over
TB0CCR1 = 1; //trigger adc
TB0CCTL1 = OUTMOD_3+ CCIE; // CCR1 set/reset mode 
TB0CTL = TBSSEL_1+TBCLR + MC_1+ TBIE; // ACLK, Up-Mode

to this:

TB0CCR0 = 1; //roll over
TB0CCR1 = 1; //trigger adc
TB0CCTL1 = OUTMOD_3;// CCR1 set/reset mode 
TB0CTL = TBSSEL_1+TBCLR + MC_1;//ACLK, Up-Mode

This ISR was implemented - but I found even if I removed code from it, it still corrupted my parallel port writes which are DMA based and synchronized to a timer output (for the write strobe).

However, why did this ISR firing (on every sample) corrupt my DMA? 

The suggestion thus far is interrupts - however I have produced various test harnesses and found that the DMA did not corrupt the data when the msp430 was loaded with the same ISR demands. Only, when I configured the timer to trigger the ADC AND call ISR. I believe this setup to be invalid - is that right? What are your thoughts on the impact of doing such a thing?

Thanks,

TB0CCR0=1? Quite tight (only two timer ticks per cycle).

However...

In another recent thread, it was suspected that accessing USCI registers (USCIA0) during an ongoing DMA transfer (USCB0!) was corrupting the DMA transfer. Dropping the access to the USCIA0 registers made the DMA working again.

But I don't know why this could happen. I could imagine that on modules with read waitstates (such as the MPY) a DMA transfer while the CPU is in a waitstate could cause problems (and in fact, I think I remember an erratum about this). But for normal periperals... this would render DMA quite useless.

Especially if the DMA source/target and the module accessed inside the ISR (or main code - I don't see a difference here between the two) are not related.

The only thing I could imagine is that a DMA being triggered during an ISR entry sequence could cuse problems. This again would make DMA rather useless.

Since you're the second one now with a similar problem, this issue should be investigated further, perhaps form 'official' side.

It shouldn't be a problem to use the timer as trigger for ADC and a timer ISR simultaneously. However, the ADC runs on faster clock than the CPU by default. It may be that the ADC is ready with the conversion before the ISR init sequence (triggered at the same time) is done. And the DMA happens while the CPU is still in the proccess of entering the ISR. Possibly the CPU is not stopped by DMA in this case, and a bus collision happens.

What happens when you pick a longer ADC12SHT time or a slower ADC12CLK?