RM48L952: MibSPI inter-micro communication synchronization

Hello Valerio,

If you are using a similar methodology as described in the application note where you are completing the DMA transfers on blocks of data as they come in, the one shot may not be performing as expected because the TG never truly gets filled because you are moving data out almost as fast as it is coming in. This, in effect, is double buffering the incoming data.

Some ideas to try instead of transferring data in small blocks as it comes in would be to setup the TG as a one shot mode and to trigger an interrupt when full, process the data from the TG storing results in RAM, then only re-enable the TG after data is processed. This may lose some efficiency but would allow you to continue to use the TG in one shot and eliminate the use of the DMA.

A second option would be to continue as you are but, instead of allowing the MibSPI logic to control the nENA pin, set it up as a GIO and manually hold off the master until processing is done by manually manipulating the nENA pin as a GPIO.

A third option would be to forego using a TG at all in the slave. i.e., set it up as a standard SPI receiving one byte at a time. Each byte received would then be transferred to the RAM buffer and, when full, commence processing before triggering the next DMA transfer of the next received data byte in the SPI Rx Buffer. Holding off the read of the Rx buffer would cause the ENA to hold off the master until the slave could read the received byte.

And one final option, create another buffer for data that is being recieved. i.e., have a buffer one and a buffer two. When buffer one if being processed, buffer 2 can be in the process of being filled and vice versa. This would require the reconfiguration of the DMA transfers after the full receipt of each buffer.

Well, it seems that I have a lot attempts to implement ;-)
I'll be back with my results.

Thanks Chuck!

1. “If you are using a similar methodology”

Yes the methodology is similar with double DMA transfer, but I have a transfer group of 128 buffers and I transfer data to SRAM with two DMA transfer, each applied on 64 buffers.

2. “the one shot may not be performing as expected because the TG never truly gets filled”

This does not seem true. I tried to completely disable DMA transfer but the TG does not get disabled anyway. I see that the 128 MibSPI buffers are filled with new data from master (overwriting the old one) but the TG is still active. In fact if I send again data from the master I find new data again in slave buffers. I'm not able in any way to automatically disable the TG on slave side. What am I missing?

 3. Your idea 1 (Eliminate the use of DMA and transfer data from MibSPI buffers with CPU, re-enable the TG after data is processed)

Also giving up with DMA (which is something I would like to avoid), currently it doesn’t work for me because of the problem in point 2

 4. Your idea 2 (nENA pin set up as a GIO)

This doesn’t seem to fit my needs, if I understood well. If I manually enable the transfer, I cannot guarantee that the slave is fast enough to manually disable the ENA and avoid the second transfer.

Anyway this opens another strange phenomenon: if on the slave side ENA is set as GIO and DMA transfer is enabled, one or two data word get lost. The slave receives well the first 64 buffers which triggers the first DMA block transfer, after that the second or third data are never received, in this way the second block of 64 buffers never gets filled, as a result slave become desynchronized. It seems like that if a MibSPI is under DMA transfer is somehow busy and lose incoming data. This does not happen if I set ENA as functional or I disable DMA transfer. Can you find any reason for this?

5. Your idea 3 (forego using a TG, set it up as a standard SPI)

This seems an option but I would like to leverage on the big relaxing of time requirement that MibSPI buffers give.

6. Your final option (create another buffer)

If I understood right what you are saying, it is more or less what I’m currently doing. I have 64 buffers which trigger a DMA transfer and another 64 buffers which trigger another DMA transfer. But again this does not guarantee synchronization with master.

So if you have any suggestion on point 2 I would like to give it another try, otherwise I will choose another way following your ideas unfortunately renouncing to some of mibSPI capabilities.

Thank you for your attention,

Valerio

Hello Valerio,

Have you been able to resolve this issue or is there still the ongoing issue?

Hi Chuck,
unfortunately not in the way I wanted. Since no answer came from TI and TRM documentation is lacking about MibSPI topic, I'm trying another way.

My solution is similar to the one described in https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/158061/1978463.

I'm using DMA chain to get a circular buffer: one DMA channel transfers data and the other (in chain) transfers a counter into a variable. Reading that variable I know how many frames DMA has transferred.

This works but I don't like:

• nothing automatically stops the transfers, there is the possibility to overflow the buffer overwriting old data. As you read in my previous posts, this is something I'd tried to managed through MibSPI (oneshot tranfer + ENA)
• though this approach is used by other people on the forum, It seems to me like a little undocumented hack

So currently I think I will go this way managing the occurrence of buffer overflow along all the dataflow. This is delayed by MibSPI buffers and DMA circular buffer, but still possible.

Valerio