TMS320F28388S: TMS320F28388S SCIB Module - Parity Issue with SCI_setConfig() Using TI DriverLib

Hello,

I believe the SCI module will still send and expect to receive the parity bit even if parity is disabled. It will always transmit 11bits no matter the settings. When parity is enabled, it just allows the parity bit that gets transmitted to be meaningful and the parity check is also done on the received data. Does your Modbus tool remove the parity bit in its transmissions?

Best Regards,

Delaney

Hi Delaney,

Thanks for your response.

As per the TMS320F28388S datasheet, the SCI module does support None parity configuration. Additionally, in the logic analyzer capture, I can clearly see that with SCI_CONFIG_PAR_NONE setting, the SCI module transmits a 10-bit frame (1 start bit, 8 data bits, 1 stop bit), confirming that no parity bit is being transmitted but in receiving side it is unable to read with None parity frame from any tool.

I’ve attached the waveform capture for your reference.

All other scenarios and testing combinations (Modbus Poll, ModScan, different parity settings) have been detailed in my earlier mail.

Please let me know if you need any further information.

Regards,
Ramakrishna

Hi Ramakrishna,

I see, my apologies, I was mistaken then.

Ramakrishna Panda said:

the MCU receives corrupted data

Can you elaborate more on this? Are there RXERROR flags getting set in the SCI registers (break detect, framing errors, parity errors?). Or is the data being read just incorrect, and if so how - does it seem like it is shifted by one bit? I see your screenshot shows RXERROR is 0 but is this at the time that data is received?

Also, what baud rate and LSPCLK frequency do you have configured?

Best Regards,

Delaney

Hi Delaney,

Thanks for your follow-up.

As elaborated in my earlier mail, the RXERROR flags (break detect, framing, or parity errors) are not set—they remain clear during reception. The issue is that the data itself is incorrect, without any associated error flags.

There doesn’t appear to be a consistent pattern to the corruption. However, one thing I consistently observe is that the first byte (0x0A) is received correctly, while the subsequent bytes are corrupted, as shown in the rx_buffer snapshot shared earlier.

To confirm the configuration:

• Baud rate: 9600

• LSPCLK frequency: 50 MHz

Let me know if you need any additional captures or tests from my end.

Best regards,
Ramakrishna 

Hi Ramakrishna,

Thank you for the information. Your baud rate and LSPCLK combination should have a relatively low known error (.01%), so that eliminates any issues there. Are you able to share your code with me and a sequence of values to send so I can try to reproduce the issue?

Best Regards,

Delaney

sci_ex3_echoback.zip

Hi Delaney,

Thanks for the support.

I’ve uploaded the code.zip as requested. You can test the issue by sending the Modbus command [0A 03 00 00 00 03 04 B0] from any Modbus tool configured with None parity. I tested with Modbus poll and Modscan.
On the MCU side, the received data will be available in the ucRXBuf[].

For additional debug visibility, I’ve added a buffer g_debug_flow.isr_bytes[], where you can also observe the received bytes.

You may set a breakpoint inside the eMBRTUReceive() function in mbrtu.c, specifically on the first if check, to trace the data flow during reception.

Please let me know if you need anything else to reproduce the issue.

Best regards,
Ramakrishna

Hi Ramakrishna,

Thank you for sharing the reproducible code. I have not had the chance to test it yet but will respond back when I can.

Best Regards,

Delaney

Hi Delaney,

Any update on it ??

Regards,
Ramakrishna

Ramakrishna,

The expert is currently out of office and will get back to you when they return. Thank you for your patience.

Best Regards,

Aishwarya

Hi  Aishwarya,

Thank you for the update.

Is there any information available regarding the return of the expert from leave? Alternatively, if possible, could another expert assist on this matter? Our development is currently stuck due to this issue, and timely support would be greatly appreciated.

Looking forward to your response.

Best Regards,
Ramakrishna

Ramakrishna,

She will be back in office later this week. Will try to loop in another expert that can assist in the meantime.

Best Regards,

Aishwarya

Ramakrishna,

Looking at the codebase you have provided, I noticed the following comment in the xMBRTUReceiveFSM() function:

If you perform the comparison indicated in the code, what behavior are you seeing?

Regards,
Jason Osborn

Hi Jason,

Thanks for the response.
For debuging purpose, I added these points .
But in _rx_ISR the characters were not received correctly , All scenarios were perfectly explained in trail mails .you can follow .

On the MCU side, the received data will be available in the ucRXBuf[].

For additional debug visibility, I’ve added a buffer g_debug_flow.isr_bytes[], where you can also observe the received bytes.

You may set a breakpoint inside the eMBRTUReceive() function in mbrtu.c, specifically on the first if check, to trace the data flow during reception.



Regards,
Ramakrishna

I see- apologies, I'd misunderstood your earlier point.

I am unfortunately not currently able to download the ModBus application, but I was able to do a simple serial test, and I was not able to replicate the behavior- in an echoback setup with no parity bit, the C2000 device had no issues whatsoever. If you have a C2000 EVM, can you please use the echoback application and a simple serial terminal, such as the built-in CCS terminal or PuTTY, to verify echoback behavior?

Regards,
Jason Osborn

Hi Jason,

Thanks for your response.

If you notice, the project I’m working on is named sci_ex3_echoback, which is the same echoback example you're referring to. I’ve already gone through the steps you mentioned using both CCS terminal and PuTTY.

However, I’d like to highlight that the echoback test is not representative of real-world Modbus communication. In my application, where RX ISR is enabled for single character reception and Modbus protocol timings are involved (1.5 character inter-frame gap and 3.5 character frame gap), the issue arises specifically when RXRDY interrupts are used.

It would be helpful if we could focus on this real-world scenario with Modbus timing and interrupt-driven receive handling.

Hope this clarifies the context.

Best regards,
Ramakrishna

Hi Ramakrishna,

To update, I am still working to replicate this issue on my setup and trying to familiarize myself with your code as well as the modbus software. In the meantime, here are some suggestions from a software point of view:

1. One potential cause of the issue I see in the code: the prvvUARTRxISR() is calling SCI_clearInterruptStatus(SCI_BASE_ADDR, SCI_INT_RXRDY_BRKDT); every time it executes, which will software reset the SCI module at the end of every ISR. This is a flaw in our software driver that we have seen cause issues in the past. Can you remove the SCI_clearInterruptStatus() line from the ISR or add a check before calling this function in your code and let me know if this fixes the issue?
2. The framing error flag can indicate a loss of synchronization of the SCI module start/stop bits, however it is possible that this can be the issue even without the flag getting raised, as you are seeing. The SCI module will raise this flag on the following condition: "when an expected stop bit is not found. Only the first stop bit is checked." If there is a 1.5 bit idle time between each character transmission, the SCI could be mistaking this for a stop bit since they are both logic level high. Or, if the last bit in the transmission is high, it could be mistaking this for the stop bit as well. 
3. One recommendation: generally, it is best practice to enable interrupts globally as the last initialization step, it looks like your code enables interrupts globally before configuring the SCI interrupts which could cause some unexpected behavior.

Best Regards,

Delaney

Hi Delaney,

Thanks for the detailed update and suggestions.

Regarding your first point — could you please elaborate a bit more on the suggestion “remove the SCI_clearInterruptStatus() line from the ISR or do the clear manually”? Specifically, where exactly should I perform the manual clear? Should it be in the main loop or somewhere else after the RX ISR is triggered?

On the second point, just to confirm — are you observing the framing error flag being set on your setup? Because in my case, no error flags were raised during the tests. Still, I will cross-verify this once again and keep you updated.

As for the third point, I’ve already made the recommended changes related to global interrupt enable sequencing.

Once you confirm about the best way to handle the interrupt status clear in point 1, I’ll make the change and share all results accordingly.

Best regards,
Ramakrishna

Hi Ramakrishna,

Let me know if the above code change (note that I changed it slightly) fixes your issue and please upvote the response if it does.

Best Regards,

Delaney

Hi Ramakrishna,

Glad to hear the change resolved the issue. Below are my responses to your additional questions:

1. In this scenario, the Modbus application is sending an extra bit with each frame (the parity bit) that the MCU isn't expecting. It sounds like the extra bit time is enough for the receiver to properly SCI SWRESET and recover in order to not lose any meaningful bits the Modbus is sending. To know for sure what is going on here would require knowledge of exactly how long the SCI RESET is taking too complete, which I believe can differ depending on the state of the module so it's difficult to tell. 
2. The RXERROR interrupt can be enabled on the same line as the regular SCIRX interrupt. You can & any other error flags you want to check against the status register in the if statement. Then, if enabled, the RXERROR flags will trigger the same ISR and would go into the if condition. My recommendations in the case of RXERRORs is either:
   1. Use them for development/testing only - Modify the setup to avoid these errors by picking a lower error baud rate/LSPCLK combination, reducing noise on the receive line, or sending data from the transmitting device with more gaps in between characters.
   2. Another option is to handle them in real-time. To do this, you would have to send a message back to the transmitting device telling it to restart the sequence since there is known transmission data dropped. That way, it won't matter that the SCI SWRESET takes some time to complete since you are restarting the sequence anyways. 

In your case, I would add an ESTOP0 or breakpoint into the if statement and just make sure it isn't getting hit when you are developing and testing your code. If the if statement is entered, then you can diagnose the issue based on which flag(s) are set and make the necessary fixes in your implementation. 

The upvote will automatically close the thread but if you post an additional question after that, it will be reopened.

Best Regards,

Delaney