MSP430F67751A: Problems on DMA transfers

It may possible have problem with ADC. Can you do some ADC detection test without DMA?

Please refer to this document, to check if it is the same problem. www.ti.com/lit/pdf/snaa354 

Hi, thank you for your help Eason.

Eason Zhou said:

without D

We examined the document you shared. But we think this is not our case because we only Read 0 value at adc unlike the data provided in the document table 3.1. And we see it very often like in every 2 seconds. The faulty results can not be seen at every step of the operation. So ADC is working fine while processor load low and some interrupts not in use.

1. For DMA7, it will cause loss interrupt. Do you think if the DMA don't work for 1 or 2 time, it will cause one of the channel result be 0? Can you changing the sampling time or something else? I think you can read the interrupt flag in CPU to see whether it is DMA7 bug.

 2. It seems that not all of the products meet this problem. Can you give a number?

3. It seems to be easy to recreate this problem. Can you do it through debug mode?

Hi Eason,

1. I've decreased the sampling period, which did not change anything. I also enabled the ADC10 interrupts which I think blocks DMA transfer and that caused a "0" value at my all readings. Furthermore, I've made a log table for interrupt callers to understand the loss in interrupts, and I saw no DMA transfer interrupt between some ADC readings. (For example, Timer1_A1 (which is the highest priority interrupt in the software after system and nonmaskable ones) starts ADC conversion. I tend to expect a DMA Interrupt Call between two Timer1_A1 interrupts, but sometimes I do not see it in that log. But I could not be sure about the reliability of the logs since higher priority interrupts may cause a cut at lower priority interrupts, and it might return later. Can not examine these conditions in logs.)

2. We faced this problem in a ratio of approximately 2 in 1000 products.

3. We couldn't create this problem with working products. But yes it can be seen in debug mode too. Also, examining in debug mode for a long time even though I do not stop software in DMA processes made readings worse.

I couldn't find a proper way to check raw ADC data transferred by DMA. Since the problem occurs randomly in debug mode I do not have a chance to examine raw transferred data because when I see the effect of false reading it is always too late, new conversions are finished and data perishes.

I think if DMA transfer 0 data, it should not happens when the DMA miss trigger. It should happens when the data is not prepared by ADC. Can you double check it?

If it right, maybe you can use one timer to trigger DMA, one timer to trigger ADC.

Hi Eason,


Sorry for the late answer. I was trying to examine what you said, and I came to the conclusion that DMA and ADC both work fine and precisely. I created a log table with brute force while debugging and examined the last 8 seconds of the ADC readings from DMA output. Everything was fine, as you guessed. But the reason behind error behavior is a bit complicated.


We use a thread-like structure in our project. Timer1_A1 interrupt fires a 1milisecond flag for every interrupt for the general function handling part. According to this 1ms flag, this general structure handles different threads. There are a few timeshift occurrences that are well expected, but that is not an issue for us since our project does not have to be real-time. There are also a couple of interrupts at the parallel.


The problem is we sample ADC readings from Timer1_A1 interrupt, which also fires a 1ms flag for a thread-like structure. We sample 80 readings before calling the thread for ADC, which operates cumulative summation in the function. In erroneous devices, I examined that before the wrong process of ADC data, the thread is called after 150 or more samples. Which means the handler calls the thread. At the start of the process, interrupts occurs, which creates a "shiftstorm" and ends up with more than 80 samples. No problem more sample more accurate data, but since 150 samples were taken (more than 4 times the ADC thread call time, also one of the highest priority threads), the handler automatically starts to operate the ADC thread again without looking for other threads. As a result, ADC thread works without any sample. I inserted many conditional checks to prevent this kind of behavior, which ended up worse. This time, other threads explode.


In addition, we use nested interrupts, but only for one specific interrupt. Which is a part of Serial Communication. Does activating global interrupts in one of the interrupts, enable nesting for all interrupts? I think not because I could not examine that kind of occurrence while debugging. You might guess that is a very specific and hard-to-solve situation. There might be more than one source for this problem. But which drives me crazy that 1000 products working fine under exact same conditions without no problem. But these 2 products have that kind of behavior. Reducing threads, or optimizing interrupts, is my first thought on this problem. But how software changes its working behavior and starts the overflow for some products? Do you have any advice about debugging that kind of structure or nested interrupts?


I appreciate your help, have a nice day

1. The easy guess, may lies on the clock frequency which cause the problem. Maybe you can do some check on this part.

2. It is really said to hear that news. To understand what is you problem also spend my some time. The best solution is to understand what the time sequence of every thread. However, it is really hard to do that, because it only happen on some devices. I just think if you can ignore the ADC empty result?

Hello Selim,

To comment on your nested interrupt question, when entering an ISR, the MSP430 auto clears the GIE bit, thus disabling the ability to be interrupted during an ISR. Enabling nested ISR functionality is done via enabling the GIE bit while inside an interrupt. At that point, any interrupt enabled in the system can and will interrupt you, thus nesting. Although technically possible, it is not recommended to use nested interrupts in MSP430 devices. 

Hello Jace,


Thank you, we are doing it by using the same procedure you described, but I am asking to confirm that the second ISR which interrupts the first ISR also clears the GIE bit again. Is it true?

Yes, it is true: