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.

TMS570LS0714: How to clear MIBSPI rx RAM received flag/status without reading MIBSPI RAM ...

Expert 2035 points
Part Number: TMS570LS0714
Other Parts Discussed in Thread: HALCOGEN

How can I clear up the RX RAM ready or received status/flag, _WITHOUT_ reading out that MIBSPI RAM contents?

It is automatically cleared, If you have read out that RAM, BUT,  if not, I cannot find how to clear it alternative way, with the result that, after my TGx complete finishes, there is NO more interrupts coming as I don't read out the contents of those buffers/RAM.

I wanted to see/ time how long the my MIBSPI isr/notification takes without MIBSPI RAM access, and cannot seems to get around of reading out the contents MIBSPI RAM...

  • Hi V01d,

    Do you means the RXEMPTY status? RXEMPTY is set after CPU reads out the RXRAM or writes a 1 to clear the RXINTFLG bit in the SPI Flag Register (SPIFLG).

  • What i mean is :

    If I do not call HalCoGen's mibspiGetData() on every group that triggers notification,  then i do NOT get notifications anymore.

    So I'm trying to understand which flags get cleared by invoking that method, and I see none : i just reads from MIBSPI RAM. So I assume somewhere/how, they get cleared from reading out the words.

    But I don't want to read the out, just clear the interrupt / acknowledge it and carry on.

  • If I do not call HalCoGen's mibspiGetData() on every group that triggers notification,  then i do NOT get notifications anymore.

    You will get notification, but the RXOVER flag is set, and RXEMPTY flag is not set.

  • You will get notification, but the RXOVER flag is set, and RXEMPTY flag is not set.

    If I do not get the notification (ISR) callback,   then .... how do I get it ?  Because I do not. 

    If I read that mibspiRAM, then I do get callback/ISR.  

  • There are 4 interrupt for Multi-buffered SPI:

    1. TG Transfer complete

    2. TG Transfer suspend

    3. Receive Overwrite 

    4. Transmission error

    The mibspiGroupNotification() is called when TG compelete interrupt occurs. It is not dependent of your read the data out from  the RX RAM. If the data is read out, the new incoming data will overwrite the current data in RX RAM, and  the RXOVRN flag is set.

  • @QJWang

    How does then the buffer mode 6 - wait until RX is empty -  work then, for a TG ?   I mean, there are multiple buffer modes, as skip transmit for example, to avoid overwriting the buffer yet move on with other transmissions. If it always overwrites MIBSPI RAM / buffer, then.. well what's the point of it at all of that group setting.

    I do not fully get what is going on with my interrupt, but I have confirmed it now multiple times, if I do not specifically read out the mibspiRAM for the groups in question i'm using, there is no more interrupt coming in, and,  no more transmissions - i listen on the bus. 

  • And i get now same behaviour when I setup DMA transfer out of MIBSPI RAM - the transfer from that RAM Must have happened, else no more SPI transfers and frame interrupts. 

    So specifically, if you configured say, buffer id 11 to trigger DMA transfer, Unless that specific MIBSPI RAM is read out, no more DMA. 

  • Hi V01d,

    If the MibSPI is a SPI master, and TG buffer mode is 6 or 2, the MibSPI sequencer won't transmit data if the RXEMPTY of it's RXRAM buffer is not set. It is expected. If you want to keep the RXRAM updated, and don't mind if the data is lost or not, you'd better no to use bufer mode 6 or 2.

    If the MibSPI is in slave mode, and TG buffer mode is 6 or 2, the MibSPI transmits data if there is clock from SPI master isde even the RXEMPTY of it's RXRAM buffer is not set, the contents of the RXRAM is overwritten by the new received data. 

  • If the data is read out, the new incoming data will overwrite the current data in RX RAM, and  the RXOVRN flag is set.

    I am sorry for the typo. "If the data is read out" should be " If the data is not read out"

  • If you want to keep the RXRAM updated, and

    Ok, so it seems, per this suggestion, it is NOT possible to clear out, thus, by your statement there, " you'd better not use .. ", this implies one cannot basically acknowledge to the SPI controller any other way that I have "handled" that RXRAM (as if read out) , but explicit RAM read seems necessary -  as I assume you confirming with that last post.

    All wanted , as I tried to explain,  to Ack to the controller as-if it was received (clear isr flags where needed), but Not access its memory (no reads from MIBSPI RAM)   ( so I can compare how long that MIBSPI ram access actually takes vs rest of my ISR )