UART RX bytes in wrong order

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello,
New to PSoC, just testing different components to see if PSoC fit our needs.
One of the tasks is to communicate with a Master over RS485 using MODBUS protocol. Baudrate is 921600.
Master send a request packet to Slave (PSoC) twice every second and expect updated values as reply.
Master request send 0x02, 0x04, 0x01, 0x13.
After some testing I've concluded that PSoC save the bytes in wrong order:0x04, 0x01, 0x13, 0x02.
That is so weird that it took some time to even believe.
Tried to read documents, examples and forum posts without finding a reason for this to happen.

   

Missing something essential?
We're using CY8CKIT-043.
I'll attach minimal bundle .zip file.

0 Likes
6 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

You can be quite sure that the UART does not save the received bytes in a wrong order, no way.

   

What I presume is that you miss the first byte which gets appended in the next round as the last one.

   

Your code looks quite ok, but you do not check for errors which would be done when you use the API provided.

   

I would suggest to check for overruns.

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

You can be quite sure that the UART does not save the received bytes in a wrong order, no way.

   

I know...

   

I'll attach two scope pictures. RS485 pin is just used for testing.

   

IdleTimerFlg.jpg is where RS485 pin is set to same value as IdleFlg which is used to catch first byte after bus was idle. Which also lead me to ask, is there no UART interrupt to detect that bus was idle for at least one frame?

   

Second scope picture (HiOnFirstByte.jpg) RS485 pin is set high when detecting byte 0x02 and set low for the other three bytes.

   

As you can see signal is set high ~6µS after last stop bit in packet arrived. This is where I loose it, why is first byte in packet detected as last one??

   

Pavloven: Thanks for your files. We already have several products successfully running MODBUS, I've just copied needed functions from our existing code.

0 Likes
EvPa_264126
Level 7
Level 7
500 replies posted 250 replies posted 100 likes received


Unfortunately, I can not evaluate the project, but I can offer my variant solutions for MODBUS
PSoC4:   PSoC 4ModbusSlave.cywrk.zip      
PSoC5LP: PSoC5LP_ModbusSlave.zip
Read more here(russian):  http://mylab.wmsite.ru/moi-razrab/cypress-psoc/modbus/
I used the achievements Sam Walsh:
https://github.com/EmbeddedSam/Modbus-Slave-for-PSoC4

0 Likes
EvPa_264126
Level 7
Level 7
500 replies posted 250 replies posted 100 likes received

This is very similar to the presence of the capacitor at the output tx_en  (Baudrate is 921600).
you can check for Baudrate 9600?

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Since this baud rate is quite high to handle in software - you really need to check for buffer overruns. When you use the scope for checking, you need to look at the first transmission and see whether it gets handled correctly or not (otherwise Bobs scenario happens).

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

After some rethinking PSoC device reply to the request from Master.

   

Code execution is too slow to evaluate one byte at a time.

   

Had to save complete request packet to ComBuf and enter SW_ISR after last byte was detected.

   

Unfortunately this lead to a delay of  ~100µS before sending reply which forced me to increase Master timeout waiting for reply.

   

Need to decrease that delay if we want to use PSoC in production. Still very early stages of testing...

   

This topic can be closed. I've attached the project as it is now in case its useful for someone.

   

/Richard

0 Likes