SCI baud rate upper limit on an F28335?

Mark,

See comments embedded below in your post.

Regards,
Vamsi

Is there an upper limit of the baud rate on the SCI ports on an F28335?

Vamsi:  Max baud rate allowed is LSPCLK/16 (info given in Table 2-5. Baud-Select Register Field Descriptions of SCI reference guide).  Max LSPCLK value is 75MHz as given in “Table 6-4 Clocking and Nomenclature” of F28335 datasheet (SPRS439H).  So, SCI baud rate upper limit on F28335 is 4.687 Mbps. 

I'm connecting two F28335s over an RS-485 link in half-duplex mode (each with an RTS signal).  I have the signals timed properly such that only one DSP drives the link at a time, taking care for extra time at the end of a transfer to make sure the stop bit is properly sent (there are about 2 1/2 stop bit-periods before changing the RTS states).  I've noticed that the TXEMPTY bit goes high long before the stop bit has been fully sent, btw, contrary to the documentation.  Both DSPs use identical send/receive driver code and both have 30 MHz oscillators with stability and accuracy measured in parts per million (150 MHz SYSCLK) so they have nearly identical low-speed clocks for driving the SCI circuitry (SCIA in particular) and the error should never be large enough to cause a problem.

At 115200 baud - which works out to 115740 or so given integer rounding in the BRR calculation - the link works fine.  At 230400, however, the "master" DSP repeatedly (though not always) registers framing errors on a simple 4-byte "ping" followed by a 2-byte "ack" separated by 20 us (the "slave" always responds so it must not be generating an error.)  The inputs to the SCI pins are clearly sufficient for proper reception of the data, i.e., there is a start-bit, followed by 8 data bits, a stop bit, a start bit, 8 more data bits and at least 2 1/2 periods of stop bits at the end.  The waveform resulting in an error condition is identical to that of a properly received bit insofar as I can tell by visual inspection on a 'scope.

Vamsi:  Slew rate limitations affect the sampling/detection of the baud signal at higher baud rates as baud period decreases.  RS485/RS232 transceivers slew rate performance differs by transceivers and capacity load on the circuit.  At higher baud rate the SCI bit width will be narrow and hence internal SCICLK ticks used for sampling might fall in to SCI baud bit edge transitions instead of the baud bit level.       

In fact, the EMU buffer register actually contains the second byte of the "ack" and the RXFFST register bits indicate the presence of 2 bytes in the FIFO.  Since the FE bit has been set I cannot extract both bytes through RXBUF.  Once a framing error occurs, all subsequent transfers fail as well (even after a SWRESET) until after a system reset.

  Vamsi:  After an FE is set, SCI continues transmitting and receiving data but the received data has to be checked for correctness to see whether it is as expected or not.

The only documentation I can find on the SCI port timing is the GPIO timing which indicates higher speeds should be possible.  I've seen some mention of speeds of up to 961 kbaud for similar 28xxx parts, though nothing in particular for the 28335.

Thoughts?

Mark

Capture this thread to a wiki.

I realize that slew rate and bandwidth will impact performance though I am quite certain neither is a problem (unfortunately, since that would be the easy answer.)  As noted, I've captured the signal at the SCI input pins on the chip itself and the signal is clearly sufficient for proper demodulation, particularly given the "majority vote" architecture of the sampler.  The part I'm using has a minimum rate of 500 kbaud and I don't notice any significant increase in slew rate until I surpass that rate (which I would expect to cause failure of the link.)

What I've noticed when the FE bit gets set is that the RXBUF data is all zeros though the EMU buffer contains the last byte (which is correct.)  I can recheck the data to verify this behavior as I have since added another layer of error checking to the driver.

Thanks for the reply...

Mark

I've noticed the exact same behaviour on my 28335 SCI communication. For example: if the SCI baudrate is 115200, and we send from PC a frame with 57600 baudrate, than the RX ERROR is detected (FE error to be exact) as expected and we do SW RESET of SCI. But, when right after this we send frame with 115200, and with the third byte equal 0x00 then the FE error is still detected. When the same  frame is send one more time it is received correctly. Please notice, that if the frame does not contain this zero byte it is OK, even if this is the first frame received after detecting FE and SW RESET.

We are using idle line communication with FIFO. In some previous tests we also set the SLEEP=1, in the case of detecting RX ERROR (so we did SW RESET and SLEEP=1), and in this case it was much worse: the frame with 0x00 third byte, sent with the proper baudrate, must have been sent even 20 times (the same frame continuously repeated) just to "fix" the SCI and stop reporting FE error. The 21 frame was received properly and the problem was gone, communication was ok from this moment (the 20 frames is just an example, it can be 5 or 10 frames).

I've also noticed when testing this, that different frame (it was 4 byte frame without any 0x00 bytes in it) was received just fine. It was like this:

1. send frame (about 10 bytes) from PC to SCI with 57600 baudrate (the "wrong" baudate)

2. the SCI reported RX ERROR (FE). We do SW RESET and SLEEP=1

3. we send the same 10 bytes frame (with third byte equal 0x00) from PC to SCI    with 115200 baudrate (the "proper" baudate)

4. the SCI  reported RX ERROR.  We do SW RESET and SLEEP=1

5. we send 4 bytes frame (no zeroes)   from PC to SCI with 115200 baudrate (the "proper" baudate)

6. the SCI receives it correctly. No FE.

7. we send the 10 bytes frame (with third byte equal 0x00) once more with 115200 baudrate

8. the SCI  reported RX ERROR.  We do SW RESET and SLEEP=1

... and repeating steps 5-8 in loop. After maybe 10 times, the SCI "fixes" and both frames are received correctly from now on.

I thought that this is somehow connected with the errata to SCI, but we are not using address mode.

We are now stil investigating what is going on.