Curious RS-485 Problem!

[jseidmann]

I am currently using the PIC18F452 in a product which has been in use for quite a while now.

When I communicate with the PIC on RS-485 it works great 99% of the time, but I find that occasionally something happens and it does not get the RS-485 command. I am testing this by sending the same commands over and over and over again. The PIC sends back a response when it gets a valid command, and sends nothing when it gets an invalid command.

My PIC is used in a monitoring application. If i turn the 'monitoring' off, and just leave it in standby (where it can still communicate and so several other things), it works flawlessly for hours on end. I am using the RS-485 interrupt (RDA). There is a higher priority interrupt (timer2) which I use, but i have switched the priorities of the two and it does not help.

My feeling is that this should not be happening because there is an interrupt that should be interrupting anything else thats happening! The timers are never disabled in the code, so I do not know what i can do to find out what is causing this problem. Are there known routines that disable the interrupts like reading/writing to the EEPROM?

Any help would be extremely helpful!

If you have any questions about this, I will respond very quickly!

[Neutone]

How are you sending the commands?
Do you wait for a reply before sending another command?
Does the PIC delay before sending a reply?

[treitmey]

As a test, cut down all 'other ' ISR to a get-in and get-out shell. Then we KNOW that this isn't a case of a bad ISR taking up too much time. And the int_RDA/int_tbe won't be missing a char

[jseidmann]

Neutone: I am sending the commands through a VB program, and I do wait 3 seconds before i consider the command 'unanswered'. The PIC sometimes delays for over a second when responding (which is huge!). Remember, the RS-485 works without a problem when the system is in 'standby'.

Treitmey: I will try that test overnight to see if it is the other ISR that is causing problems.

[Neutone]

Is there some reason why the time to reply would have a huge variance. If the time to reply can vary to more that 3 seconds it would apear to have timed out. I would look for the cause of the variance.

[SherpaDoug]

That one second delay is a big red flag. Could the PIC delay that much if it wanted to? I strongly suspect the PC and VB end of the communication. Can you put a scope on the RS485 lines to verify the timing of the querry and responce at that point?
_________________
The search for better is endless. Instead simply find very good and get the job done.

[jseidmann]

I do not suspect the VB code because it works without any problem when the system in in 'standby' mode. I do not know if anyone has had problems with this before, but the ROM is 99% full,and the RAm is 85% full. There is a lot of computation going on, and I will try to see if this problem is caused by the interrupts and I will test that tonight.

[Ian McCrum]

Couple of things about RS485, serial code and PICs

(a) occasionally some serial PIC code of mine would hang or freeze, usually permanently sometimes for a second or two. I think this was due to various error conditions occurring - it was necessary to clear the error bits in the uart and then I never saw it hang again.

(b) with RS485 there is sometimes brief periods of time when the line is floating. You can add a pullup and pull down resistor to +5v and gnd at one place in the network to "bias" the network to the idle state. This is in an old app note and probably does reduce your noise immunity a bit - but it works.

(c) you MUST use termination, twice! physically at each end of the party line. If you have drop lines or spurs then this gets difficult. Drop the baud rate in that case.

(d) Because of (b) and also to allow a simple PC to be used as a monitor I usually ended up implementing "4 wire RS485" - one master always transmitting on one pair, received by all slaves and all slaves transmitting on the secondary pair to the one receiving chip in the master. This allows you to use a PC for a master since its transmitter can be permanently enabled. As a side effect it improves problem (b) above.

(e) Of course once you transmit a byte there is a time delay before it actually leaves the usart - your transmit software must either (i) wait with a time delay (ii) listen to itself transmitting or (iii) depend on bits in the UART control register to tell it the buffers are all empty and the byte has left the building. Most code then tristates the RS485 buffer - But it can hep if you add a delay before tristating - provided the far end delays before responding...

Sorry for the core dump - I have not read the thread carefully - hope it helps someone...


_________________
Ian McCrum, email address held at
www.eej.ulst.ac.uk/~ian

[asmallri]

There are two more things to consider

Lots of PC applications expect to receive a string terminated with carriage return linefeed (0x0d and 0x0a respectively). A common mistake is to mix the order: