MibSPI with DMA

Hello Alex and thank you for your post.

I have asked one of our engineers who has created an example project of DMA-enabled SPI transfers to respond to your questions.  In the meantime, have you reviewed the example code for suggestions?   It can be found in the HalCoGen subfolder: C:\Program Files (x86)\Texas Instruments\Hercules\HALCoGen\vx.xx\examples

Hi Brian,

Thanks for the response.

I did look at the suggested example and I don’t see anything that I didn’t do per that example. However there are few components in that example that I don’t understand:

1. In my code I transfer bytes, so my element destination offset in the PCP is 4, but in your example you transfer 16 bit data, so to my understanding that offset should be 2, but you have it at 4. Why is that?

2. In your example the ICOUNT that goes to DMACTRL is 0 but the One Shot bit is set to 1. In the TRM it says that if this bit is 1, the length is defined by the ICOUNT in the MibSPI and not by the DMA controller. Why then the ICOUNT is set to 0?

3. The example does not show Buffer Mode settings since the function mibspiInit() is not provided and depends on setting done in Halcogen tool. What should be the Buffer Mode settings?

4. In the example AUTOINIT_ON = 1, in the TRM Auto-initiation mode is enabled when AIM = 0.

Which one is correct? Why example needs Auto-initiation mode enabled?

Hi Kumar,

In regards to you answers:

1. I understand now that the offset is always in bytes. I originally thought that the offset is in elements. It is called "element offset". It is a bit confusing. Maybe it can be clarified in the next TRM release.

2. In the example the buffer size is 127, so why is the ICOUNT set to 0 for 1 transfer?

3. My question was regarding the buffer mode (skip, suspend, always...). 

4. Clear.

Can you please provide answers to my fisrt email in this set (before Brian responded)?

Thanks,

Alex. 

Hi Sunil,

I got to retest this issue and it still doesn’t work for me as I expect. The DMA is triggered now by the SPI, but if I set ICOUNT in the SPI DMACOUNT register, the SPI will only transfer one element and the group will be suspended. If I set the SPI ICOUNT to 0 then the MIBSPI will work properly. The DMA will always transfer per the control packet ITCOUNT, but what is going to happen if the ITCOUNT in the control packet is greater than the MIBSPI buffer size? According to the TRM the DMA should work of the SPI ICOUNT, but if I don’t set the DMA’s control packet ITCOUNT the DMA won’t transfer. Herea are my settings and what I oserved:

 Just in case I modified the DMA channel to 3, so I will be under 8. Per the data sheet MibSpi1[3] is mapped to DMAREG[ 5].

I modified the defaults DMAREQx settings, swapping requests between channel 5 and 3 :

      dmaREG->DREQASI0 = 0x00010205;

      dmaREG->DREQASI1 = 0x04030507;

Then I set the following in the SPI registers:

    spiReg[0]->DMACTRL[0] = 0x89032000;

    spiReg[0]->DMACNTLEN = 1;

    spiReg[0]->DMACOUNT[0] = 63U << SHIFT16;

The control fields in the MIBSPI buffer is set to 0xB8 (suspend single transfer mode) in all data fields but last, where I raise the CS and release the lock bit.

Then I set the DMA control packet parameters (including ITCOUNT = 0x00010040).

Then I set DMA hardware trigger to channel 3

Then I set TXDMENA bit in spiReg[0]->DMACTRL[0].

At this point the DMA channel is triggered and it transfers data per its control packet ITCOUNT into the MIBSPI buffer ignoring the SPI ICOUT value.

Then I set TGENA bit in the proper TGxCTRL register. At this point one element is transferred via SPI and the group is suspended.

If I do not set the DMACOUNT and DMACNTLEN then the SPI transfers all 64 bytes.

I will summarize my questions here:

1. Why the SPI transfers only one element and then the group is suspended when the SPI ICOUNT is greater than 0, even though the DMA transferred all 64 entries into the MIBSPI buffer?
2. How the total transfer size should be set in the SPI ICOUNT and DMA’s control packet ITCOUNT?
3. Am I forgetting anything in the MIBSPI/DMA settings?

Thanks,

Alex

Alex,

Please excuse me for dropping the ball on this post.

Is it possible for you to upload or paste your routines for setting up the MibSPI and DMA transfers? I will have to try and replicate the behavior on my setup as I am not able to do so with a code example from our verification team.

I will answer some of your questions though:

1. Why the SPI transfers only one element and then the group is suspended when the SPI ICOUNT is greater than 0, even though the DMA transferred all 64 entries into the MIBSPI buffer?

1. How the total transfer size should be set in the SPI ICOUNT and DMA’s control packet ITCOUNT?

1. Am I forgetting anything in the MIBSPI/DMA settings?

>> Need to check once you paste/upload the code that sets up the DMA and MibSPI.

Regards, Sunil

Hi Sunil,

Thanks for the response.

I am attaching the driver files2055.MibSPI_DMA.zip.

I thought that I finally I understood how the MibSPI works, but what I tried after that, didn’t work either. I am currently using MibSPI/DMA only for writing data to MRAM. Here is how I understood the MibSPI/DMA should work:

1. The DMA is triggered when the TXDMENA bit is set and then the DMA transfers data per the element count in the DMA PCP to the SPI TG buffers.  The ICOUNTx+1 is loaded into the COUNTx after the TXDMENA is set.
2.  If the TG buffer is set to suspend mode, the SPI will begin transfer after the TG is enabled and new data arrived into the buffer (from the DMA).  The COUNTx should be decremented each time SPI transfers one data element.
3. If the BUFID in DMAxCTR is set to the last buffer number in the TG, then after the TG is transmitted and the COUNTx is not yet zero, the SPI will trigger the DMA to refill the TG buffers and the SPI will transmit again until COUNTx is zero. Then the TXDMENA is cleared and full block transfer is completed (ONESHOT mode).

If the process I described is incorrect, please correct me, or explain the process to me if all is wrong.

The problem I am having is this:

After I set the TXDMENA the DMA starts the transfer into the SPI TG buffers. After I enable the TG the ICOUNTx is loaded into COUNTx and the SPI is transmitting the first data batch. However, while the SPI is transmitting 64 bytes (size of my data is one byte), the COUNTx is decremented only one time. The TRM (spnu499 page 1543) claims that COUNTx represents the “actual number of DMA transfer that remain until the DMA channel is disabled”. Why COUNTx is decremented only once and never again?

The DMA is never triggered again and the TXDMENA is never cleared. No more transfers are happening on this TG after this one batch. The TG is waiting for new data to come from DMA and the DMA is waiting for SPI to trigger the DMA.  Shouldn’t the DMA be triggered when the last buffer in the TG is transmitted?

Thanks for helping,

Alex

Alex,

The MibSPI updates the COUNTx once each time that the buffer pointed by BUFIDx in the DMAxCTRL register is transferred through the MibSPI. The MibSPI does not keep track of how many buffers got transmitted before or after that particular buffer, so the behavior you are observing is correct. We will update the documentation to reflect this so that it is clearly explained.

In general, say the MibSPI needs to transfer 10 frames, each frame having 64 bytes of data. Then you need to configure MibSPI ICOUNT as 10, and the DMA controller needs to be configured to transfer 10 frames of 64 byte-elements. This way, each time the MibSPI requests a DMA transfer, there will be 64 bytes transferred to the MibSPI RAM. Also, the MibSPI will stop generating DMA requests after transmitting 10 frames.

Please also note that you need to enable the auto-initiation mode for the DMA channel being used for these transfers. Without this, the hardware channel enable in the HWCHENAS register gets cleared after the channel completes one block transfer.

Let me know if this helps.

Regards,

Sunil

Hi Sunil,

It finally worked for me. In addition to what you mentioned, I had to disable the Oneshot mode in TGxCTRL, otherwise the SPI won't work after the first transmission. I also had to clear the NOBRK bit, otherwise the other groups could never be transmitted after the MibSPI group is started.

One last question I have regarding this. Is there any way to automatically reset the chip select after the block is transmitted? In my setup I transmit the data to the MRAM after the chip select was enabled with the previous group, but the only way I can see to clear the chip select is to create an interrupt routine that will be called at the end of the transmission and will do it manually. Is there a better way?

Thanks,

Alex

Alex,

Thanks for the confirmation.

Are you driving the chip select as an I/O pin or as a SPI functional pin? If you are using the chip select as a SPI function, then you can drive it low and release it using the CSHOLD control field of the transmit buffer. You can choose to do this in the 64th buffer so that the chip select is released after every 64 transmissions. If you need to send multiple packets before releasing the chip select, you could trigger another DMA channel to write to the control field of the last buffer.

Regards,

Sunil

Hi Sunil,

  The only way I was able to disable the CS after the transfer,  is using the SPI interrupt. Your suggestion to use another DMA channel doesn’t work because the chained DMA channel will be triggered after the first DMA transfer and not the whole block. I don’t understand why it is like that, since I set the transfer mode in the DMA PCP to Block.

 I also tried to create another TG that is triggered after the  SPI data transfer TG and I set the NOBRK bit in DMAxCTRL. The additional TG  is resetting all CS, but the NOBRK bit set does not prevent it from transmitting at the end of the first data set. I was under impression, per the TRM, that this is exactly what it should do (not to let any other TG transmit until the all the data is transmitted and the COUNTx is 0). Do you have any explanation to that?

 The other problem I had that in Suspend-Single Transfer mode I was not able to clear the INTFLGRDYx bit, because the group was suspended after the whole data transfer is finished. Is that how it supposed to work? I had to change the buffer to Skip-Single Transfer mode and in that mode after I clear the TGENA bit in the interrupt routine, only then I can clear the associated INTFLGRDY bit.

 There is a very specific recipe to make this thing work and I spent a lot of time on it.  There is no way you can figure it out from the TRM. To my opinion there should have been an assigned bit in the DMAxCTRL to make the CS release automatic at the end of the transfer.

Thanks,

Alex

Hi Sunil,

Unfortunately, at this point I believe that MibSPI/DMA functionality is buggy on the processor I’m working on (TMS570LS3137). I thought that somehow I made it to work, but I did my test on two data sets of 64 bytes each and I believed that all I have to do now is increase the ICOUNT and Frame count to as many data sets as I need, but I was wrong. When I changed to three data sets it didn’t work already. In “skip” buffer mode, when NOBRK bit is not set, the group will generate INTRDY every two data sets, so you cannot use the interrupt for the transfer completion. When NOBRK bit is set, the number of actual SPI transfers is undefined. Although it works with two data sets, anything over that will give you unexpected results. Although, according to COUNTx it seems finishing the whole transfer, but from what you see on the oscilloscope you know that it is not true.  It looks like the DMA does work properly. I don’t have any other group running on that SPI during this transfer. If I don’t use an interrupt to detect completion, then with the NOBRK bit off it will complete the whole transfer, but how do I know when? This is not working the way it should.

Are you aware of those issues?

Alex

Hi Sunil,

Just to let you know, I was able to make it work eventually. I used DMA BTC interrupt to trigger the additional DMA channel that updates the buffer control field to release the chip select. Another thing that I found out is that the PCP of the DMA channel that does the transfer cannot be configured in Block mode, because then the DMA will transfer the whole block on each trigger. So although my code eventually works, please check with the developers the following issues that I found with the processor:

1. When NOBRK bit is set the MibSPI does not complete the transfer (if there are more than 2 transfers) and hangs somewhere in the middle.
2. When buffer is in Suspend mode, there is no way to clear the TG Complete or Suspend interrupts
3. When buffer is in Skip mode the TG Complete interrupt is set every two transfers and not when the whole set is completed. Also to clear it in this mode you need to clear the TGENA bit first (I don't think it should be like this). You should be able to clear the interrupt flag at any time.

Thanks,

Alex