SERIN2 Receiving Wrong Data

[rsocor01]

Hi, I have two devices communicating with SERIN2/SEROUT2. Device A, a PIC18F4550, sends data to device B a PIC16F19197. I'm receiving the data at device B using SERIN2, but like 1 out of 5 times I receive a wrong byte. I know that device A is sending the correct data because I can see the right data with my logical analyzer. So, the problem is with SERIN2.

I placed a 10k resistor in series to prevent either device to send power to the other device when one of them is turned off. Do you think that this resistor is the problem?



'Code at device B, PIC18F4550
SEROUT2 PORTB.7,32,[STR RFID_IN\7]

'Code at device B, PIC16F19197
SERIN2 PORTE.1, 32, 5, BOARDSEARCHFAILED, [STR ClockInDataArray\7]

[Ioannis]

Yes it could be a problem. Try with no resistor and see if the problem is in your code or just the lack of power on the link. Then try max 1K resistor.

But without more details like, type of cable, length and most important your code on both PIC chips, it is not easy to address the issue.

Ioannis

[HenrikOlsson]

Are these PICs on the same PCB or on each end of a long cable?
Cable (well PCB traces too of course) has capacitance, with a 10k resistor you're forming quite an RC-filter (relatively speaking) which slows down the rise and fall times of the signals.

If you have a scope, compare the signal on the sending and receiving PICs respectively.

[tumbleweed]

Another thing that could be causing problems is that SEROUT2/SERIN2 are software bit-banged (no hdw UART involved),
so device B must be sitting waiting at the SERIN2 for the first start bit before device A begins transmitting, else the timing won't be correct.

[rsocor01]

I tried removing the 10k resistor and I'm still having the same problem. The PICs are in two different PCB boards. The serial communication is taking place over a 3ft cable. The cable has 2.5mm mono plugs connectors at the end. I'm using a Baud rate of 19200. I'm going to try 9600 to see if that helps.

Each PIC has thousands of lines in code. I don't think there is a problem with the side sending the data because I can see the correct byte with the logical analyzer. The issue in in the receiving end.

[Ioannis]

Your best shot would be to post your code...

Ioannis

[rsocor01]

There is no much code to show here. I know device A is sending the right data because I can see it with a logical analyzer. I know device B, like 1 out of 5 times, is reading some bytes wrong because I can see these variables values in an LCD. That makes me think that it is a problem with the line. I'm still troubleshooting.



'Code at device A, PIC18F4550
SendData:
pause 5
SEROUT2 PORTB.7,32,[STR RFID_IN\7]
goto SendData

'Code at device B, PIC16F19197
ClockInDataArray var byte[7]

SERIN2 PORTE.1, 32, 5, BOARDSEARCHFAILED, [STR ClockInDataArray\7]
hours_0 = ClockInDataArray[0]
minutes_0 = ClockInDataArray[1]
seconds_0 = ClockInDataArray[2]
hours_1 = ClockInDataArray[3]
minutes_1 = ClockInDataArray[4]
seconds_1 = ClockInDataArray[5]

[richard]

I'm still troubleshooting.

alone, until you provide at least a minimal, complete and verifiable example [MCVE]

posting useless snippets is a good example of a worthless bad example


my guess for the nearest to the pot Calcutta is inadequate power supplies

[tumbleweed]

'Code at device A, PIC18F4550
SendData:
pause 5
SEROUT2 PORTB.7,32,[STR RFID_IN\7]
goto SendData


You're only allowing device B 5ms between transfers to receive the data and display it.
If device B is not finished and sitting back at the SERIN2 statement before device A does another transmission it will fail.
Try increasing the 'pause 5' to 'pause 500' and see if things get better.

You might also have to break the single SEROUT2 statement into something a little slower, like sending the RFID_IN array data a byte at a time with a pause in between the bytes to allow device B time to receive, save it, and be ready for the next byte. As I mentioned before, you're using a software SERIN2 on device B which is VERY timing-dependent and prone to failure. A hardware UART is much better suited for this, especially for receiving data.

You could also be having issues with osc accuracy between the two... on each end send a 'U' (hex 55) and measure the bit timing. At 19200 baud each bit should be 520us +/-15us, give or take (about 3%).

My bet would be on one of the first two above.

[Ioannis]

As Richard noted, the problem could be in any other part of your code. So you are alone on this as we cannot guess what may be happening there.

However, the part you posted does not somehow checks for valid incoming message. For example you could on the sending device use a string of "hey" and then the data.

On the receiving device wait("hey") and then collect your data. In this case you will not receive data in the middle of the transmission.

Ioannis

[tumbleweed]

Just to correct myself in #9...

At 19200 baud each bit should be 52us +/-1.5us, give or take (about 3%).

I was thinking byte times, not bit times.

[rsocor01]

Ioannis, yes I'm doing data validation checks all the time. The first byte of the array is always 174. If this condition is not met, then the reading is discarded.

[rsocor01]

Tumbleweed, I had very strong suspicions that the issues were in the communication lines. I changed the Baud rate from 19200 to 9600 and I haven't got anymore wrong data at the receiver. I remember from my EE school days that the higher the frequency, the more prone to line noise the data is. So, by lowering the Baud rate it worked. I was pulling my hair out for a few days. At first I thought that it was some kind of SERIN2/SEROUT2 software issue.

[tumbleweed]

By lowering the baud rate you're now allowing device B (and SERIN2) twice the time to receive the bits and assemble the byte.
That's probably what's helping a lot more than any line noise issue.

A software UART has a lot of potential timing issues, especially when it comes to receiving.

[rsocor01]

By lowering the baud rate you're now allowing device B (and SERIN2) twice the time to receive the bits and assemble the byte.
That's probably what's helping a lot more than any line noise issue.

There is probably a little bit of both. I did a search in the forum, but couldn't find anyone having the same issue.

[Ioannis]

What is the clock of each PIC you use?

Ioannis

[rsocor01]

What is the clock of each PIC you use?

Ioannis

The sending device has the typical 18F4550 USB setup and it is set to "Define OSC 48". The receiving device is set to "DEFINE OSC 16".

[Ioannis]

I guess then, the sending device is interrupted by the USB routines while sending and as a consequence the transmission of RS-232 at that time is corrupted.

Ioannis

[tumbleweed]

If you're using interrupts on either end then you shouldn't use SEROUT/SERIN as interrupts will upset the timing.
You should use the hardware HSEROUT/HSERIN routines, but then you will have to use the dedicated UART IO pins.

Also, you would be better off running the receiving end with a faster osc setting... try 32MHz instead of 16.

[richard]

I guess then, the sending device is interrupted by the USB routines while sending and as a consequence the transmission of RS-232 at that time is corrupted.

that can't be right because:)


I know device A is sending the right data because I can see it with a logical analyzer.

my next guess is that device A is running on 3Volts:D
this guessing game has got longer legs than i expected

[rsocor01]

If you're using interrupts on either end then you shouldn't use SEROUT/SERIN as interrupts will upset the timing.
You should use the hardware HSEROUT/HSERIN routines, but then you will have to use the dedicated UART IO pins.

Also, you would be better off running the receiving end with a faster osc setting... try 32MHz instead of 16.

The PIC ports with HSEROUT and HSERIN are already taken. Using a baud rate of 9600 instead of 19200 made a difference. It is now working fine. The USB Darrel's interrupt takes micro seconds to execute. I measured it once. I forgot the exact number, but it was very small. That shouldn't affect the SEROUT/SERIN.

[tumbleweed]

From an old DT post (https://www.picbasic.co.uk/forum/showthread.php/13356-USBSERVICE-serout2-problem?p=90526)



Anytime you are using interrupts (other than ON INTERRUPT), it interrupts things.
USB_ASM_Service uses USB interrupts that happen quite frequently.

Software timed routines like SEROUT2, PAUSE, PULSIN/OUT etc. Will lose time that they don't know about.

When using interrupts, Hardware devices should be use instead of software commands.
Instead of SEROUT2, use HSEROUT with the USART.

PAUSE ... use a timer.
PULSIN ... use a CCP module.
COUNT ... use a Timer

There are still many PBP commands you can use without problems.
But, if if they require specific timing thru software, that timing will be disturbed.

[Ioannis]

that can't be right because:)

my next guess is that device A is running on 3Volts:D
this guessing game has got longer legs than i expected

I think it can be right since Serout/Serout2 happens in a async rate. USB is fast but in any case the soft Serial is interrupted randomly.

The logic analyzer catches one instant of this.

Lowering the baud rate helped because of that interrupt thing. Lower baud has more time on every bit and the fast USB gets away.

I have long that I abandoned software serial port use because of such matters.

Ioannis

[rsocor01]

From an old DT post (https://www.picbasic.co.uk/forum/showthread.php/13356-USBSERVICE-serout2-problem?p=90526)

Yes, that explains everything. Unfortunately, I can't use the HSERIN/HSEROUT ports available in the 18F4550 because they are already taken doing the hardware communication. Increasing the baud rate worked.

[Ioannis]

Increasing the baud rate worked.

You mean decreasing ovbiously. But problem is not solved and at random time it is possible that will happen again. Maybe more seldom but it will.

Ioannis

[rsocor01]

You mean decreasing ovbiously. But problem is not solved and at random time it is possible that will happen again. Maybe more seldom but it will.

Ioannis

So far it hasn't fail yet with a 9600 baud rate, but I can live with a very low failure rate.