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.

TMS320F28377S: spi and dma receive stuck

Part Number: TMS320F28377S
Other Parts Discussed in Thread: TEST2, C2000WARE

Tool/software:

Hi:

I used 28377s ,spib and dma5 to read 1024 words from flash and trigger a DMA interrupt. Then continue with the next reading.

My DMA initialization code is as follows:

void sInitDma(void)
{
    // refer to dma.c for the descriptions of the following functions.


    //Initialize DMA
    DMAInitialize();


    DMA4Addr = (volatile INT16U *)Test4;
    DMA5Addr = (volatile INT16U *)Test2;
    DMA6Addr = (volatile INT16U *)Test1;


    // configure DMACH4  for spib TX
    DMACH4AddrConfig(&SpibRegs.SPITXBUF, DMA4Addr);   //
    DMACH4BurstConfig(7, 1, 0);           // Burst size, src step, dest step
    DMACH4TransferConfig(127, 1, 0);      // transfer size, src step, dest step
    DMACH4ModeConfig(DMA_SPIBTX,PERINT_ENABLE,ONESHOT_DISABLE,CONT_DISABLE,\
            SYNC_DISABLE,SYNC_SRC,OVRFLOW_DISABLE,SIXTEEN_BIT,CHINT_END,CHINT_ENABLE);


    // configure DMACH5  for spib RX
    DMACH5AddrConfig(DMA5Addr, &SpibRegs.SPIRXBUF);   //
    DMACH5BurstConfig(7, 0, 1);          //  size, src step, dest step
    DMACH5TransferConfig(127, 0, 1);     // transfer size, src step, dest step
    DMACH5ModeConfig(DMA_SPIBRX,PERINT_ENABLE,ONESHOT_DISABLE,CONT_DISABLE,\
            SYNC_DISABLE,SYNC_SRC,OVRFLOW_DISABLE,SIXTEEN_BIT,CHINT_END,CHINT_ENABLE);


    // configure DMA CH6 for spia TX
    DMACH6AddrConfig(&SpiaRegs.SPITXBUF, DMA6Addr);
    DMACH6BurstConfig(7, 1, 0);
    DMACH6TransferConfig(127, 1, 0);
    DMACH6ModeConfig(DMA_SPIATX,PERINT_ENABLE,ONESHOT_DISABLE,CONT_DISABLE,\
            SYNC_DISABLE,SYNC_SRC,OVRFLOW_DISABLE,SIXTEEN_BIT,CHINT_END,CHINT_ENABLE);




    // Ensure DMA is connected to Peripheral Frame 2 bridge (EALLOW protected)
    EALLOW;
    CpuSysRegs.SECMSEL.bit.PF2SEL = 1;
    EDIS;


    EALLOW;
    DmaRegs.CH4.CONTROL.bit.RUN = 0;
    DmaRegs.CH5.CONTROL.bit.RUN = 0;
    DmaRegs.CH6.CONTROL.bit.RUN = 0;
    EDIS;


    //Enable DMA interrupt
    PieCtrlRegs.PIEIER7.bit.INTx4 = 0;      // Disable INT7.4
    PieCtrlRegs.PIEIER7.bit.INTx5 = 1;      // Enable PIE Group 7, INT 5 (DMA CH5)
    PieCtrlRegs.PIEIER7.bit.INTx6 = 1;      // Enable PIE Group 7, INT 6 (DMA CH6)
    IER |= M_INT7;                          // Enable CPU INT6
}

My SPI FIFO initialization code is as follows:

void SpiBFifo(void)
{
    INT16U m;


    // FIFO configuration
    SpibRegs.SPIFFCT.all=0x0;               // place SPI in reset
    for(m=0;m<3;m++);
    SpibRegs.SPIFFRX.all=0x2040;            // RX FIFO enabled, clear FIFO int
    SpibRegs.SPIFFRX.bit.RXFFIL = 8;        // Set RX FIFO level
    SpibRegs.SPIFFTX.all=0xE040;            // FIFOs enabled, TX FIFO released,
    SpibRegs.SPIFFTX.bit.TXFFIL = 8;        // Set TX FIFO level

    // SPI configuration
    SpibRegs.SPICCR.all = 0x0007;//0x000F;  //Reset off, rising edge, 16-bit char bits
    SpibRegs.SPICTL.all = 0x000e;           //Enable master mode, delayed phase, enable talk, and SPI int disabled.

    SpibRegs.SPIBRR.all = 0x0006;
    SpibRegs.SPISTS.all = 0x0000;
    SpibRegs.SPIPRI.bit.FREE = 0x0001;      //Transmission not affected by emulator
    SpibRegs.SPICCR.bit.SPISWRESET=1;       
}

DMA isr:

// INT7.5
void DMAIntCh5ISR(void)       // DMA Ch5
{
    EALLOW;                                 // NEED TO EXECUTE EALLOW INSIDE ISR !!!
    DmaRegs.CH5.CONTROL.bit.HALT=1;
    PieCtrlRegs.PIEACK.all = PIEACK_GROUP7; // ACK to receive more interrupts from this PIE group
    EDIS;
}

I restart by executing halt=1 within the DMA interrupt and then RUN=1 outside the interrupt.
In most cases, it runs fine, but in the latest test, DMA has been stuck 

DmaRegs.CH5.CONTROL.bit.RUNSTS keep 1, but the reception is not complete and no interrupt is generated. and SPI RXFFOVF=1.

This issue can be 100% reproduced in specific situations and appears to be unrelated to hardware. The specific register data under the conditions of running OK and running NG are as follows.

OK-dma registerOK-SPI register

NG-DMA registerNG-SPI register

Could you please advise on the possible reasons for this issue?  

  • Hi,

    The expert is currently out of office until after the holidays. Please expect a delay in response. Thank you for your patience.

    Best Regards,

    Aishwarya

  • Thank you for your reply. Looking forward to your guidance.
    I would like to add that this issue is very sensitive.
    In my CCS project, I have tested several places: adding a line of code, the problem will not occur 100%, and deleting this line of code will cause the problem to occur 100%.
    And the added code has nothing to do with SPI and DMA, such as the variable a++;

  • Could anyone help answer this question

  • Hello , Has the expert returned from holidays?

  • Hello,

    I apologize for the delay. I am looking into your query now and will have a response back by tomorrow.

    Best Regards,

    Delaney

  • Hello,

    A note:

    spib and dma5 to read 1024 words from flash

    The DMA module does not have access to flash memory. It can only access GSRAM and registers for specific peripherals (including SPI registers). I'm assuming if you have the transfers working during some runs that Test4, Test2 and Test1 are located in GSRAM, which means this isn't the issue.

    What I suspect is the issue: Are you setting breakpoints anywhere in the code in the errored case? Sometimes this can mess with the timing of the DMA since it pauses the CPU execution, but the DMA is still running (DMA is set to run free even when a breakpoint is set since you are calling the DMAInitialize() function). When running without any breakpoints, is the issue fixed?

    Best Regards,

    Delaney

  • Hello:

    “spib and dma5 to read 1024 words from flash” ,the flash means external flash ,not internal flash, so this isn't the issue.

    This does not occur during debugging, so there are no breakpoints. Then I tested the same code on 5 different chips, one of which was 100% reproducible. The other four are normal. So does it mean it's just a chip case?

  • Hello,

    On the failing chip, are you seeing issues with the functionality of other peripherals besides the SPI and DMA? If so, then it is probably a hardware issue. 

    If not, it seems to be something related to the timing of the DMA operation.

    Best Regards,

    Delaney

  • No, other peripherals  seems operate Normal .

    "If not, it seems to be something related to the timing of the DMA operation."

    DMA received 1016 bytes, less than 1024, so no DMA interrupt was generated. This should be normal?
    But why does SPI's RX FIFO get stuck? It seems to be a problem with SPI RX FIFO

  • What do we need to do to quickly identify, determine, and solve problems

  • Hello,

    I will need to look more in depth at your configurations; at first look I don't see any issues. Unfortunately, I will be out of office for the holidays until next Monday 12/30 so I cannot look into this until after that. For now, I recommend taking a look at the SPI DMA example in C2000ware and checking your configurations against that. The example can be found in the SDK path: [C2000ware install]/driverlib/f28p65x/examples/cpu1/spi/spi_ex5_loopback_dma. The example is made for a different C2000 device (F28P65x), but the SPI and DMA module across the devices are the same.

    Best Regards,

    Delaney

  • Hello,

    I apologize for my delayed response; I am still catching up on everything since the holidays. Is the issue still open? If so, please let me know and I will look in depth into your configurations as soon as possible.

    Best Regards,

    Delaney

  • Hello,

    Yes, the issue is still open. Thank you for taking the time to pay attention to this issue!

  • Hello,

    I apologize again for the delay. I've looked into your settings, and your configurations look good.

    then RUN=1 outside the interrupt

    Where exactly in your code (under what conditions) are you re-enabling the DMA channel? It is probably that the DMA is not being re-enabled before the SPIB RX FIFO is overruns, in which case the DMA CH 5 never gets the trigger. I would not recommend this approach.

    If you have continuous data being received by SPIB, I suggest re-enabling the channel at the end of the ISR so no triggers are missed. Any data processing of the previously transferred data can be done inside the ISR before this line to prevent data loss.

    Also, as another note, if continuous mode is disabled, there is no reason to halt the DMA channel inside the ISR. This will be done automatically at the end of the transfer.

    Best Regards,

    Delaney