• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 1260 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28075: SCI / UART: Stop bit discrepancy not detectable

Frank Perge
Prodigy 40 points
Part Number: TMS320F28075


Hi,

I configure the SCI peripheral of two microcontrollers of the aforementioned type to

  • a baudrate of 300 bits/s
  • 8 bit data length
  • no parity

but, one microcontroler is set to one stop bit while the other is configured with two stop bits. When those two communicate to one another, in the code, in the RX ISR the error handling is done like that

// RX Error
		if (SciaRegs.SCIRXST.bit.RXERROR == 1U)
		{
			// RX Break Detection
			if (SciaRegs.SCIRXST.bit.BRKDT == 1U)
			{
				// Handle error ... 
			}
			// SCI framing-error flag
			if (SciaRegs.SCIRXST.bit.FE == 1U)
			{
			    // Handle error ... 
			}
			// SCI overrun-error flag
			if (SciaRegs.SCIRXST.bit.OE == 1U)
			{
			    // Handle error ... 
			}
			// SCI parity-error
			if (SciaRegs.SCIRXST.bit.PE == 1U)
			{
			    // Handle error ... 
			}
			SciaRegs.SCICTL1.bit.SWRESET = 0U;
			SciaRegs.SCICTL1.bit.SWRESET = 1U;
			return;
		}
 

In the manual from Sept. 2019, p. 2164, field FE, it says "The SCI sets this bit when an expected stop bit is not found. Only the first stop bit is checked." I cannot see, that any error occurs and the communication also works in both directions. Is my code wrong or is this kind of error situation not detectable?

One stop bit:

Two stop bits:

  • 0
    Prodigy 40 points

    Part Number: TMS320F28075

    Hi,

    In the manual from Sept. 2019, p. 2163, field BRKDT, it says "The SCI sets this bit when a break condition occurs. A break conditionoccurs when the SCI receiver data line (SCIRXD) remains continuously low for at least ten bits". Here is a careless mistake btw. 

    The code handles errorsin the RX ISR like

    // RX Error
if (SciaRegs.SCIRXST.bit.RXERROR == 1U)
{
	// RX Break Detection
	if (SciaRegs.SCIRXST.bit.BRKDT == 1U)
	{
		// Handle error ... 
	}
	// SCI framing-error flag
	if (SciaRegs.SCIRXST.bit.FE == 1U)
	{
	    // Handle error ... 
	}
	// SCI overrun-error flag
	if (SciaRegs.SCIRXST.bit.OE == 1U)
	{
	    // Handle error ... 
	}
	// SCI parity-error
	if (SciaRegs.SCIRXST.bit.PE == 1U)
	{
	    // Handle error ... 
	}
	SciaRegs.SCICTL1.bit.SWRESET = 0U;
	SciaRegs.SCICTL1.bit.SWRESET = 1U;
	return;
}

    When I tie RX to GND I get a FE and not a BRKDT. How can I trigger a BRKDT?

  • 0 in reply to Frank Perge
    TI__Mastermind 19795 points

    Hi Frank,

    Thanks for your question! Merging your two threads since we're discussing the same code with related issues.

    For the BRKDT question, my understanding is that if you tie RX to GND, you may cause the low signal to occur in the middle of a valid byte (assuming values are being transmitted). This would cause a FE before the BRKDT.

    For the second question regarding the stop bits, the stop bits are high valued, and so from the bus receiver(s) perspective, stop bits appear identical to idle time after the last bit is transmitted. 2 stop bits allow extra idle time between bytes, but from the perspective of a receiver, it knows that the transmission has ended (since it received the last data bit before the stop bit, as well as at least one stop bit) but cannot differentiate between the first stop bit and normal idle time (since both idle time and stop bits are logic high).

    Let me know if that clears up your questions!

    Regards,

    Vince

  • 0 in reply to Vince
    Prodigy 40 points

    Hi Vince,

    Thank you for your answer.

    BRKDT
    Can you tell me how I can test my code then? How do I cause a BRKDT error? And I also tried to tie RX to GND w/o transmitting anything. This does not cause a BRKDT, but FE in my case.

    Stop bits
    This means, your TI SCI/UART peripheral in that microcontroller is not capable of detecting if there are too few stop bits received? It will never complain as long as it captures the rising flank of the first stop bit? Or does it mean that I always need one stop bit, no matter how many stop bits the receiver is configured to. Can you sort this out for me?

  • 0 in reply to Frank Perge
    TI__Mastermind 19795 points

    Hi Frank,

    Thanks for the clarification questions! See below responses:

    Frank Perge said:
    BRKDT
    Can you tell me how I can test my code then? How do I cause a BRKDT error? And I also tried to tie RX to GND w/o transmitting anything. This does not cause a BRKDT, but FE in my case.

    Side note: I do find it a bit weird that no BRKDT error occurs at all (I would expect both FE -AND- BRKDT, potentially others), but my guess is the order of the if statements in your code is causing it to never reach the BRDKT check before the error is cleared.

    My suggestion for causing a break detect only would be to use the other device (the one that is inserting a 10 bits of low) to send a valid byte first. Then, once the valid byte is sent, if the device is configurable like C2000, change the device output to low-logic-level for ~10 bits (9.625 to trigger BRKDT).

    If this still ONLY causes an FE, then my potential suggestion is (without knowing what is in the if-statements): we may need to re-arrange the if-statements according to priority, or maybe prevent clearing of the errors till after all if statements have been checked.

    Frank Perge said:
    Stop bits
    This means, your TI SCI/UART peripheral in that microcontroller is not capable of detecting if there are too few stop bits received? It will never complain as long as it captures the rising flank of the first stop bit? Or does it mean that I always need one stop bit, no matter how many stop bits the receiver is configured to. Can you sort this out for me?

    The first and last questions are true (of all UART-protocol devices I believe, given how UART-protocol uses high-logic level for both idle-time and stop bits). But the middle question is not true.

    Middle question:

    Frank Perge said:
    It will never complain as long as it captures the rising flank of the first stop bit?

    At least one stop bit must be detected including the actual pulse of that stop bit, so it WILL complain if it only receives the rising flank of the first stop bit. It must receive at least 2/3 of the 8 strobes-per-bit of the first stop bit, otherwise errors will be detected. The diagram in the "SCI Communication Format" section of the Technical Reference Manual does a better job of explaining it visually, but for a bit to be detected, a "majority vote" on the 8 strobes of the bit is used to determine the value of a bit. The stop bit is included, and so must be included in the overall frame. If that high-logic level bit is not detected, then an error will flag. The second stop bit may or may not be idle time, but the important part of the communication (the data) was successfully received since we have a start and end of the data.

    Essentially, you still are required to have a full 1 stop bit minimum otherwise you will get errors on the bus. But the second stop bit can be viewed as essentially a little extra idle time inserted between packets. The second stop bit is more of a transmitter-side configuration to provide more processing time for the receiver before it sends another byte to that processing receiver, receiver side is simply looking for the data packets. Extra side note: In most cases with low-speed UART and a high system clock speed, that extra processing time of 1 bit is probably not needed, if the SCI interrupt is not doing any "heavy" processing, which it really shouldn't be doing.

    Let me know if I misunderstood your questions and I'll provide a follow-up!

    Regards,

    Vince

  • 0 in reply to Vince
    Prodigy 40 points

    Hi Vince,

    BRKDT

    I did exactely as you said. I think either something is misconfigured or the SCI peripheral works different than I would expect. The SciaRegs.SCIRXST.all register is read in the RX ISR when SciaRegs.SCIRXST.bit.RXERROR == 1U. The register value is 208.

    Hence, RXERROR, RXDY and FE are HIGH. BRKDT is LOW. The waveform on the RX looks like this:

    I send "p" and "o", after that the TX line is muxed to the GPIO peripheral and set to LOW (50 ms corresponds to 15 bit @ 300 Bd). Can you reproduce this and find out that BRKDT cannot be caused like that or tell me that it must be a mistake in my configuration (we talkin about very old code here that I am supposed to fix/understand atm)? So maybe BRKDT occurrs and is cleared before I realize. There is no other way to clear it than

    SciaRegs.SCICTL1.bit.SWRESET = 0U;
SciaRegs.SCICTL1.bit.SWRESET = 1U;

    is there?

    Stop bits

    Very well. Thank you for that competent answer!

    EDIT:

    So, I claim that I found the issue. The problem is, that FE causes an interrupt and the condition that causes BRKDT always causes FE to be set first. Unfortunately, the easiest solution is, that I need to wait in the interrupt spawned SWI in case of an error to find out if the flag will be set after 10 bits. Can you confirm this behaviour, Vince?

  • 0 in reply to Frank Perge
    TI__Mastermind 19795 points

    Hi Frank,

    Thanks for the follow up, I will confirm with the design team to ensure that this is the actual behavior in the hardware, but my gut feeling is that you are correct in the order of errors that you observed.

    Please allow me till Monday end-of-day CST to get back to you with a response from our design team. I will let you know if they will need additional time for verifying.

    Regards,

    Vince

  • 0 in reply to Vince
    TI__Mastermind 19795 points

    Hi Frank,

    Simulations are underway, but is taking longer than expected, please wait till Friday for an additional update.

    Regards,

    Vince

  • +1 in reply to Vince
    TI__Mastermind 19795 points

    Hi Frank,

    Thanks for your patience! After verifying with simulations, we can confirm that FE does indeed always occur before BRKDT, -EXCEPT- when RX is in sleep mode.

    Let me know if you have any additional questions!

    Regards,

    Vince