TMS320F28384D: FSI: Buffer operation, Buffer Overrun, and Buffer Underrun

Hi kevin,

You can try fsi_ex8_ext_p2pconnetion_Xx projects which is available in C2000ware.

Using circulating buffer causes data to flow in circular motion. For example, If you set set the nword length to 6 it should loop the circ buf every 6 words and calling the FSI_setRxBufferPtr function and setting it to 0, it will always receive the first byte to position 0.

fsi_ex8_ext_p2pconnetion_Xx project does not treat the buffer as circular.

To your first comment: My understanding is that setting the length to six should set the outgoing message to 6 words. If all messages were six words, the buffer will wrap on the third message, as the buffer is 16 words. Right?

Regarding Tx Underrun: Are you saying a Tx Underrun is triggered with a length of zero?
Regarding Tx Overrun: Are you saying a Tx Overrun is triggered when over 16 words are loaded in into the buffer regardless of the position of the buffer pointer? Or data is loaded from the buffer ptr location wraps and then goes past the buffer ptr?

Now can you address my original questions in the context of receiving?
 
Regards

Hi Kevin,

As mentioned earlier, it depends on if calling the FSI_setRxBufferPtr function and setting the value.

If above function is not called, your understanding is right.

Kevin Eschhofen said:

Regarding Tx Underrun: Are you saying a Tx Underrun is triggered with a length of zero?

Yes

Kevin Eschhofen said:

Regarding Tx Overrun: Are you saying a Tx Overrun is triggered when over 16 words are loaded in into the buffer regardless of the position of the buffer pointer? Or data is loaded from the buffer ptr location wraps and then goes past the buffer ptr?

Sorry, I didn't quite catch that.

But here is the simplification:

TX

 Underrun: Buffer underrun occurs when the transmitter tries to read data from a location which has not yet be written to by the CLA, CPU, or DMA.

Overrun: Buffer overrun can occur if a piece of data is overwritten before the data has been transmitted

RX

Underrun: This condition occurs when software reads an empty buffer.

Overrun: new data is received but old data is not yet read

Thanks,

Susmitha

Referring to the TRM (spruii0e): The TRM indicates the init process. In another section it refers to a Synchronization/flush process that needs to be done after init or re-init on error recovery. This uses a ping frame. This has to done in addition to init before comms can start (Rx). Is a Ping frame and or WD frame required to maintain synchronization and communications, and if so, how often does it need to be sent?

The following is in regard to reception:

CURR_BUF_PTR – From testing this appears to be pointing to the next location data will be stored?

CURR_WORD_CNT – The TRM says this is the number of data words not read. Does this go down as I read words out? If not what resets it? Does it just change on every new message (TRM says it’s words not read out, so reading make it update) or does it updated on frame done clearing?

Are these buffer indices updated on every Reception?

What happens when the buffer is not Circular and the buffer ptr is reloaded or set back to zero on each Rx and before every Tx?

I am interpreting that the buffer BUF_OVERRUN and BUF_UNDERRUN errors will be generated as the buffer pointer is being forced to a value and making it disagree with what the FSI controller thinks they should be?  The TRM say you “CAN” ignore these events in this case (32.3.3.7). I am thinking that the user HAS to ignore these events as they may be artificially generated from the buffer pointer is being forced back to zero or to another location out of circle. Is this the case?

Hi Kevin,

Kevin Eschhofen said:

Referring to the TRM (spruii0e): The TRM indicates the init process. In another section it refers to a Synchronization/flush process that needs to be done after init or re-init on error recovery. This uses a ping frame. This has to done in addition to init before comms can start (Rx). Is a Ping frame and or WD frame required to maintain synchronization and communications, and if so, how often does it need to be sent?

You just need to perform one Flush sequence anytime the FSI RX module is reset. After that the FSI RX can receive any type of frames and you can continue with normal communications. How you use PING, Error, or data frames is up to you and your application.

There is PING and DATA frame watchdog feature designed into FSI. It's not required to use but is a nice feature.

Kevin Eschhofen said:

CURR_BUF_PTR – From testing this appears to be pointing to the next location data will be stored?

Yes for the RX module. Section 32.3.3.7 Buffer Management below has important related info.

Kevin Eschhofen said:

CURR_WORD_CNT – The TRM says this is the number of data words not read. Does this go down as I read words out? If not what resets it? Does it just change on every new message (TRM says it’s words not read out, so reading make it update) or does it updated on frame done clearing?

Correct. It will decrease as you read data out of the buffer and increase after a full frame is received with new data.

Kevin Eschhofen said:

Are these buffer indices updated on every Reception?

Yes, but if overrun / underrun occurs then they won't be valid and you need to reset the FSI RX module. So you need to ensure overrun / underrun is avoided in your software.

Kevin Eschhofen said:

What happens when the buffer is not Circular and the buffer ptr is reloaded or set back to zero on each Rx and before every Tx?

See register descriptions below. CURR_BUF_PTR will not be immediately valid and you need to essentially receive or transmit a frame for it to be correct.

Kevin Eschhofen said:

I am interpreting that the buffer BUF_OVERRUN and BUF_UNDERRUN errors will be generated as the buffer pointer is being forced to a value and making it disagree with what the FSI controller thinks they should be?  The TRM say you “CAN” ignore these events in this case (32.3.3.7). I am thinking that the user HAS to ignore these events as they may be artificially generated from the buffer pointer is being forced back to zero or to another location out of circle. Is this the case?

Yes, it can create a false flag depending on what / when you reset the buffer pointer.

Best,

Kevin

There seems to be a discrepancy regarding the handshake sequence. I am referencing the spruii0e TRM section 32.4.1.1, spracm3e Application Note section 3 diagrams, and the example code. The issue is when the ““Lead”” sends ping tag0, the “Follow” device or node responds with a ping tag1. The application note depicts the response as ping tag0 (in the one diagram it seems to contradict itself, figure3-2). The example code seems to agree with the TRM in that the “Lead” sends a ping tag0 then the “Follow” device does a flush and replies to the “Lead” with a tag1.  

With TRM 32.4.1.2, for the “Follow” device (or slave), the “Follow” must wait for ping tag0 before doing the flush?  Is that correct?

As normal operation I am not planning on sending ping message on a regular basis (reduce interrupts to the software). I am using all the ports. If it is needed by the “Follow” for handshaking process, I may have to detect a comm fail and then send a ping tag0?

Possible option seems to be, I can set an auto ping Tx at the “Lead” and generate a Ping WD time out on the “Follow” and then start the “Follow” handshake?

Regards,

Kevin E.

Something else. With figure 3.2 in the application note:

1. At power up: The Lead proceeds when it receives any ping tag1 back from any of the follows. Being there is no identity in the ping back this seems to be the case?
2. During operation: The Lead has to know when a Follow needs handshaking. For instance, if a Follow were reset (1 out of 3), the Lead would have to recognize this and start sending the ping tag0, so that the receiver can start its flush handshake. The ping message itself does not have identification within it. This can be done with other means.
3. Regarding 2 above, I suppose the guess the ping tag 0 could be sent automatically and then manual send a ping tag1 in addition?
4. Regarding 2 above; while a Follow is needing and getting the handshake process, does the Lead need to stop sending/Txing other traffic (i.e. data frames)? If so at what point does normal traffic (i.e. data frames) to all the nodes need to stop?

Hi Kevin,

Agreed with you. If ““Lead”” sends ping tag0, the “Follow” device or node should respond with a ping tag0.

Kevin Eschhofen said:

With TRM 32.4.1.2, for the “Follow” device (or slave), the “Follow” must wait for ping tag0 before doing the flush?  Is that correct?

Yes, that's right. The lead device sends the flush sequence to the node1 by a ping frame with Tag0. Node 1 receives it and sends the flush sequence to the node2 by a ping frame with Tag0....Repeats until it gets back to the lead device.

Kevin Eschhofen said:

As normal operation I am not planning on sending ping message on a regular basis (reduce interrupts to the software). I am using all the ports. If it is needed by the “Follow” for handshaking process, I may have to detect a comm fail and then send a ping tag0?

It depends on user to either use handshake mechanism or not. Implementing handshake ensures both the lead and node devices are ready to send/receive data. 

Thanks,
Susmitha

Something else:

1. It seems that point to point handshaking is different than Lead and Follow handshaking. The TRM section 34.4.1.1 and 34.4.1.2 seems to only describing handshaking for two devices. The TRM section 34.4.1.1 and 34.4.1.2 seems to only describing handshaking for two devices. Figure 3.2 in the application note, seems to be describing a Lead to several Follows (the different code examples seem to support this). I don't see anything indicating why the process is different. Why are they different? Also there is an error in figure 3.2 in the application note. The Follows are replying with ping tag0 but the lead receives a ping with tag1.
2. With figure 3.2 in the application note: During normal operation, the Lead has to know when a Follow needs handshaking. For instance, if a single Follow were reset (1 out of 3), the Lead would have to recognize this (loss of comms tracking) and start sending the ping tag0, so that the receiver can start its flush handshake. Is this correct?
3. Regarding 2 above; while a Follow is needing and getting the handshake process, does the Lead need to stop sending/Txing other traffic (i.e. data frames)? If so at what point does normal traffic (i.e. data frames) to all the nodes need to stop?

Hi Kevin,

Kevin Eschhofen said:

It seems that point to point handshaking is different than Lead and Follow handshaking. The TRM section 34.4.1.1 and 34.4.1.2 seems to only describing handshaking for two devices. The TRM section 34.4.1.1 and 34.4.1.2 seems to only describing handshaking for two devices. Figure 3.2 in the application note, seems to be describing a Lead to several Follows (the different code examples seem to support this). I don't see anything indicating why the process is different. Why are they different? Also there is an error in figure 3.2 in the application note. The Follows are replying with ping tag0 but the lead receives a ping with tag1

Point to point connection is where you have single lead and single node. Star and daisy connections are used when you have multiple devices connected.

In all the cases, the sent ping Tag should be same as received pint tag to ensure nodes are working.

Kevin Eschhofen said:

With figure 3.2 in the application note: During normal operation, the Lead has to know when a Follow needs handshaking. For instance, if a single Follow were reset (1 out of 3), the Lead would have to recognize this (loss of comms tracking) and start sending the ping tag0, so that the receiver can start its flush handshake. Is this correct?

If any slave is in reset, it will not send back the ping tag to lead. This communicates that connection is lost.

Kevin Eschhofen said:

Regarding 2 above; while a Follow is needing and getting the handshake process, does the Lead need to stop sending/Txing other traffic (i.e. data frames)? If so at what point does normal traffic (i.e. data frames) to all the nodes need to stop

Lead shouldn't send any data until it receives the acknowledgment from the slaves ensuring proper link is established.

Thanks,
Susmitha