TMS320F28069: Is it possible to use "SCI-LOOPBACK" feature and develop code for multi-processor serial link on single PC?

Sayee,
I don't know why this wouldn't work, however I have never done it. I will inquire about this and let you know.

Regards,
Cody

Hello Cody

For over two days, I have tried implementing multiprocessor SCI on a standalone system. I could achieve only a limited success.

I have only single stepped through TX / RX ISRs and could no go to "free run" as few issues could not be resolved.

Few observations:

1. Only addr mode and not iidle-line mode was working.

2. At the place of issuing TXWAKE, if we do not simultaneously enable RX, by making SLEEP = 0, there is data loss at RX side.

3. The FIFO and TX and RX data progress(steps delay (shift and reconstruct) is not helping the approach stated in step 2.

4. The RX ISR fires the moment TX ISR clears SLEEP bit, resulting in wake up of RX one word prior to correct frame ( start of address word).

5. The application has no way of knowing if this RX word is start of a new frame. In address mode, the address bit can not be checked - only this will help RX sync to start of a new frame. Otherwise, it can by mistake (due to a matching data pattern in data payload) sync wrong.

6. There is no way to flush TX or RX pipeline individually! SCI RESET flushes both!

Inference:

With the current implementation of SCI (documented interface) it is not possible to implement / simulate and test multiprocessor SCI - in a standalone, unless some undocumented features are available in the reserved bit fields!

If you have any observation in contra, please do let me know. I will be happy to try it out!

Disappointing though!

Sayee

Sayee,

after reading your points I think you should try looping SCIA to SCIB. This will allow you to have a fully self-contained debug setup that should avoid some of the issues you highlighted. See my comments on your points below.

1/2/3. Check if looping SCIA to SCIB solves the issues you are having, The way you are testing it one SCI module is acting as a "master" and a "slave" which may be causing issue like in number 4 below. 

4. I *think* this is because the receiver is woken up when the SCI begins to transmit... I didn't foresee this, that would suggest that you cannot test SCI's Multiprocessor modes with internal loopback. If you would still like to have a fully self-contained debug setup you can loop SCIA and SCIB together, use one SCI module to exercise and send messages to the other.

5. There is a bit in every message to indicate if that frame is an address or a data frame, for data frames this must be 0.

6. You can separately flush the FIFOs with TXFIFO RESET and RXFIFO RESET, does that satisfy your requirement?

Sorry for your disappointment, try some of the suggestions above and let me know if you're still having issues. Hopefully not, but if so we can continue debug from there.

Hope it helps,
Cody

Hi Cody

your observation of point #4 is not correct. The receiver continues to sleep when TX is invoked. That is why there was loss of data bytes. That is why I mentioned that for an address frame TX, the TX-ISR should not only issue a TXWAKE but also reset SLEEP to avoid the loss of data bytes by RX module.

But THE ONE AND ONLY ISSUE PENDING FOR ME in succeeding with my current effort is that the RX module is woken up one word prior to start of next address frame (because SLEEP reset is is handled by TX-ISR along with TXWAKE and that is a sort of pre-trigger for RX module which wakes it up one word prior!).

I can do a bit of dirty coding to even skip the last data word and then sync to the next address word. But I want to write a clean interface that will work in both stand-alone and multi-processor environment.

The conditional comilation should only be for LOOPBACK enable (so obvious) and SLEEP reset in TX-ISR (not so obvious!)

I think looping SCI-A and SCI-B is a good suggestion. There are two things about it. One, it is a physical external wiring. I presume it is a simple wiring of SCI-A tx to SCI-B rx and vice vesa. Correct? The second is about availability of SCI-B for this. In my project, it is not. It is used up for another communication.

Note that the address bit is taken away at the shifter level itself and application has no interface to know (NO BIT TO CHECK!), if the RX-ISR is invoked on receipt of an address frame or data frame.

FIFO FLUSH does not handle the data in the shifter which will complete the work in progress and report.

Obviously, when TI designed the SCI and then enhanced, the support for multi-processor mode (like reporting receipt of ADDRESS byte) was not given much thought.

I hope I have made the matters clear.

Thanks

Sayee

Sayee,

to connect SCI-A to SCI-B you are correct, SCIATX->SCIBRX and SCIARX<-SCIBTX. This connection is vary rarely helpful in an actual application, I am only suggesting it to help debug your SCI setup and protocol.

There is a lot of information in your post! It will be helpful for me if you could provide direct questions.

Regards,
Cody