Oscillator stops when touching with a wire

[Wilbert Ingels]

Dave,

You're right, it is a firmware problem. The clock is not stopping but following is happening:

This is the instruction causing problems:
debugin 50,rs485_cont,[WAIT("ST"),rs485string[5],rs485string[4],rs485string[3],rs485string[2],rs485string[1],RS485string[0]]

When a not connected wire is touched to one of the connection, a small spike is generated on the RS485 bus. This what i think that happens than: The Debugin receives 1 bit and is endless waiting for the other bits to come. I've the impression that the timeout only works if a full byte is received.

Is my statement correct? How can this be resolved?

Many thanks !

[Jerson]

Wilbert

Good snooping. The glitch is causing your firmware NOT to see the ST sequence. So, you go on waiting till you catch it .... and guess what -- it doesnt come again!

A better technique would be to
1. Wait for byte1=S
2. Wait for byte2=T
3. Process packet

I hope you can fix this yourself.

Jerson

[falingtrea]

in the 485_receive part of your code you have a debugin without a wait value. I would put timeouts in all your serial communication calls just to be safe.

Another thing you can do is output some debug messages to the serial port showing where the program is. Once it locks up you can look at the last message and see where the code was when it died.

[Wilbert Ingels]

Hi Tim and Jerson,

I'm working in 2 modes: Live mode and initialization mode. In live mode, the processor will wait endless untill he receives "ST" with instructions from the bus master. In initialization mode, he will look at his inputs and also looks if broadcast information is received on his RS485 bus.

I've tried your suggestions but he's still going into a endless loop when a spike arrived on the bus. It looks like when one bit arrives, the timeout value doesn't count untill a full byte is arrived. He only succeed to release (via timeout) when information flows again on the RS485 bus (and bytes are being received).

It seems that timeout only works when full bytes arrives. If a single bit (spike) arrives on the RS485 network, the debugin timeout statement is not working ...

Does serin2 works different than Debugin (-> timeout bit versus byte)?

Any other suggestions?

Many thanks guys !!

Wilbert

[skimask]

Why not "SERIN" all of your characters into a 'sliding buffer string' and keep that in a tight loop. You can keep track of it and keep checking if the beginning of that 'sliding buffer string' contains the "ST" that you're looking for. When it does, you save the data and act on it accordingly.
That way, you should be able to avoid the timeout and glitch problems that you're having.
I thought I had a good idea for you...lost it...can't find it again

[Wilbert Ingels]

Hey Skimask,

Thanks for your reply !

I'm still struggling how to do it. If i use a tight loop with timeout which receives character by character, i'm afraid if only one bit is send (my famous glitch ), the timeout statement won't work and the endless loop will start (untill additional information is received)

I'm going to try it and will keep you in touch. If you remember you other suggestion, you're more than welcome

Take care

Wilbert

[Wilbert Ingels]

If i look in the manuel on page 135 (serin2) "if the serial input pin stays in the idle state during the timeout time, the program will exit the SERIN2 command and jump to label". In my case, the input pin doesn't stay idle because it received one glitch ...

Same for Debugin on page 58 ...

Hum, i don't see it yet how i can solve it