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.

MSP430FG6426: CTSD16 and DMA

Part Number: MSP430FG6426

Hello!

Help to understand a problem. Transfer of the data from ADC by means of DMA does not work at bit setting "Gie".
In the resulted text of the program and a global interrupt disabling//"__bis_SR_register(GIE+LPM0_bits)", all works normally.
At resolution of interruptions the line "__ bis_SR_register (GIE)" is included, the data is not transferred. Interruption arises and is processed. But data migration is not present.
For the test interposed a line "__ bis_SR_register (LPM0_bits)"; in this case works, the data is transferred interruption arises, but to me so does not approach. How it is possible to bypass it? That I do not truly. In slau208q it is told that all should work in any modes. Not clearly, why there is interruption DMA, in the absence of the data?

Text test program:

int main( void )
{
          
 WDTCTL = WDTPW + WDTHOLD;             // Stop watchdog timer

//Configuration of the analog unit
OA0CTL0|=OAM;    
OA1CTL0|=OAM;    
OA0PSW|=PSW0;
OA1PSW|=PSW0;
OA0NSW|=NSW0;
OA1NSW|=NSW0;
P6SEL|=BIT4+BIT5;            
P7SEL|=BIT4+BIT5+BIT6+BIT7;            

//Ref Configuration
REFCTL0|=REFON+REFOUT;    
P5SEL|=BIT0;   
//Configuration ADC
    CTSD16CTL|=CTSD16REFS;
    CTSD16INCTL0|=CTSD16INCH_15+CTSD16GAIN_16;
    volatile int  AdcWave1 [31];
    unsigned int i;  

//Configuration DMA
DMACTL0=DMA0TSEL_24;    //DMA 0 trigger select CTSD16.
__data20_write_long((unsigned int)&DMA0SA, (unsigned long)&CTSD16MEM0);   
__data20_write_long((unsigned int)&DMA0DA, (unsigned long)&AdcWave1);        
DMA0SZ = 31;
DMACTL4|=DMARMWDIS;
DMA0CTL|=DMADT_0|DMADSTINCR_3|DMAIE;
DMA0CTL&=~DMAIFG;
DMA0CTL|=DMAEN;
CTSD16CCTL0|=CTSD16SC;     //Start ADC
__bis_SR_register(GIE+LPM0_bits); //So works //__bis_SR_register(GIE); // So not works } #pragma vector=DMA_VECTOR __interrupt void Interrupt_DMA(void) { unsigned int mem=DMAIV; switch (mem){ case 0x0: {break;} case 0x2: { DMA0CTL&=~DMAIE; CTSD16CCTL0&=~CTSD16SC; //Stop ADC break; } case 0x4: {break;} case 0x6: {break;} case 0x8: {break;} case 0xA: {break;} case 0xC: {break;} case 0xE: {break;} case 0x10:{break;} } return; }

  • When you go into LPM0, execution halts there.

    Without the LPM0, your main() function returns, which undoes the stack -- along with your AdcWave1[] array. (The memory is of course still there, but it will be difficult to find.) After the return from main() the startup code will call exit() which will put its own data on the stack, most likely wiping out whatever is/was in your array memory.

    Going into LPM0 is actually a perfectly good method for waiting for the ADC to finish. An alternative would be a while(1){} which would also keep main() from returning, but would be busier about it. 

    Whichever you choose, I recommend (as a general practice) that you put any array that's used by the DMA in a global variable, i.e. declare it outside main().

  • Thanks for the answer!
    I found the overwritten traces in storage! Thanks for the answer!
    The decision with array transfer, to global variables helped! Thanks!


    Question №2. In Errata msp430FG6426 SLAZ669N there is data on DMA4, DMA7, DMA10. In the controler of this series is 6-channel internal DMA. What mean digits 4,7,10 in that case?

    Question №3. In document SLAU208Q User Guide, (DMA) Controller Module, it is not told, how controler DMA behaves by operation with the slow device. Mode DMADT=0. For example, UART at speed of 300 bits/seconds. It will retain CPU in mode Stop all time, while DMA0SZ Register! = 0? Or between accepted bytes will release bus CPU for data handling?

  • 2) The 4,7,10 have no particular significance, they are just tags to identify the respective Errata. One supposes that e.g. Errata DMA5 and DMA6 existed at one time, but were fixed.

    3) In User Guide Fig 11-3, the point of interest is the oval that says "Hold CPU", which is the only step in which the CPU is affected. After those "2x MCLK" ticks, the path goes either to "wait for trigger" or "idle" each of which are relatively long times.

  • Thanks for the answer. All is clear. Subject I close.

**Attention** This is a public forum