Shop OBEX P1 Docs P2 Docs Learn Events
URGENT - Serin WAITING forever — Parallax Forums

URGENT - Serin WAITING forever

dazzaldazzal Posts: 4
edited 2005-03-29 18:47 in BASIC Stamp
Hello,

Please read the e-mail I have recently sent PARALLAX below:


Dear sir/madam,

I wrote you an e-mail on the 9th of this month through your web form but I did not get a reply and I would appreciate
a prompt response this time.

We have a recently developed problem with one of our instruments which uses a STAMP 2 Interpreter chip as the processor
as explained below...

Our instrument has an RS232 interface (Rx, Tx and GND) but does not·use an RS232 driver chip, so we use a 22K resistor
in series with Rx as suggested in the Stamp manual(s).

When the instrument powers up, the first thing it does is WAIT for an RS232 sequence ("cal") with a timeout of·5 seconds. Below is
the startup code (see line ** THIS IS THE LINE OF INTEREST **):

TimeOut·····con····5000··' 5 seconds timeout period in serial comms
Baud_2400···con··· 396+$4000
RS232RxPin··con····7
Serial_RX···var····byte(8)

Serin RS232RxPin,Baud_2400,TimeOut,Main,[noparse][[/noparse]Wait("c","a","l"),Str Serial_RX\6\cr]··' ** THIS IS THE LINE OF INTEREST **

Main:

' main code here...

What we are finding all of a sudden, is that the instrument is HANGING forever on this SERIN line if no RS232 connection is made between
our instrument and a computer (i.e. if the connection is left open).
If I put a pull·up resistor (on the computer side of the 22K resistor) of say 39k to PLUS POWER (which could be anything from 10 to 24V)
then this cures the problem. HOWEVER, we cannot just fit a resistor because the instrument is approved as intrinsically safe, therefore
any modifications made MUST be approved before the instrument can be shipped. So this is a MAJOR problem for us.

We assume that there has been some kind of electrical change to the I/O pin(s) of the PIC16C57 but this has not yet been confirmed
by Microchip.
- If this is the case, then your suggestions of using a 22K resistor on the Rx are no longer valid as the PIC is (intermittantly) hanging
on SERIN commands.

PLEASE reply urgently with any suggestions or comments you have on this matter. Thank you.



I would appreciate being e-mailed directly for a quicker response to darrenl@michell.co.uk

Thanks all

Vbr,
Darren

Comments

  • BeanBean Posts: 8,129
    edited 2005-03-29 13:02
    Sounds like you have a floating input.
    If you don't have the input pin pulled high or low, then it will pickup noise. The noise will keep the SERIN line from timing out because it thinks it is getting data.
    If it worked before, then there must be something causing more electrical noise than before.
    You say you have a 22K in series with the Rx line, what is the other end connected to ?
    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "SX-Video Display Module" Available Now.

    www.sxvm.com

    "A problem well defined, is a problem·half solved."
    ·
  • dazzaldazzal Posts: 4
    edited 2005-03-29 13:15
    Hi,

    Yes I understand what you are saying and it makes sense.

    My concern is that this problem has only just reared it's ugly head (the instrument has been on the market for a good 8 years with no problems!).. it's only recently

    Normally, while in use in the field there will be NOTHING connected to the RS232 interface, i.e. Rx will indeed be floating

    The only time RS232 is required is for setting the instrument up after manufacture. The customer doesnt need it

    I assume then that TIMEOUT does not work if single bits appear on the input?

    Im also concerned that the STAMP manuals do not mention any possible problems that we are currently experiencing. Surely Parallax should have advised a pull-up resistor as well as the 22k in-line!?


    confused.gif



    Vbr,

    Darren
  • BeanBean Posts: 8,129
    edited 2005-03-29 13:19
    I assume the 22K goes to some kind of DB connector ?
    If so, can you make a "plug" that goes into the connector with the resistor on it ? Or will that still require re-testing ?
    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "SX-Video Display Module" Available Now.

    www.sxvm.com

    "A problem well defined, is a problem·half solved."
    ·
  • allanlane5allanlane5 Posts: 3,815
    edited 2005-03-29 13:21
    Wow. I thought the SERIN as you have it would time-out at 5 seconds whether it was recieving data or not. You'd get whatever had come in during that 5 seconds. This sounds like a job for Jon and Parallax.
  • BeanBean Posts: 8,129
    edited 2005-03-29 13:23
    No I believe the timeout ONLY happens if NO data is coming in. As long as the line is toggling the timeout will not happen.
    I may be wrong, but I thought I was wrong once...but I was mistaken [noparse];)[/noparse]
    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "SX-Video Display Module" Available Now.

    www.sxvm.com

    "A problem well defined, is a problem·half solved."
    ·
  • allanlane5allanlane5 Posts: 3,815
    edited 2005-03-29 13:30
    And Bean's suggestion of adding a 'dummy plug' which will connect the RX pin directly to ground is an excellent one. That should guarantee 'silence' on the line, and you can remove the 'plug' when you want to calibrate. I would hope a 'dummy plug' on a programming port would be relatively simple to get approved.
  • BeanBean Posts: 8,129
    edited 2005-03-29 14:01
    Another "fix" would be to change the code to check for the "c" "a" "l" yourself, instead of using the "wait" modifier. You would still need the timeout, but if you get junk the SERIN will end and you can handle it in code.
    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "SX-Video Display Module" Available Now.

    www.sxvm.com

    "A problem well defined, is a problem·half solved."
    ·
  • dazzaldazzal Posts: 4
    edited 2005-03-29 14:27
    Hi again,

    We could add the resistor but indeed the instrument will require a re-test which is time consuming and costly, so we'd rather avoid this route

    I dont understand your "fix" post above Bean (@ 6:01 AM), could you please expand on this

    Do you agree with me that perhaps parallax should have added something in the manual re. a pull up resistor?. Otherwise, my opinion is that the information provided is misleading

    I am of course still mythed as to why this problem is only apparent now, several years on!

    Vbr,
    Darren
  • BeanBean Posts: 8,129
    edited 2005-03-29 14:43
    The software fix is do this:

    Instead of:

    Serin RS232RxPin,Baud_2400,TimeOut,Main,[noparse][[/noparse]Wait("c","a","l"),Str Serial_RX\6\cr] ' ** THIS IS THE LINE OF INTEREST **

    Use:

    Count=100 ' Adjust as needed
    SerCheck:
    · Count=Count -1
    · IF Count=0 THEN Main ' Give-up
    · SERIN RS232RxPin,Baud_2400,TimeOut,Main,[noparse][[/noparse]char]
    · IF char <> "c" THEN SerCheck
    · SERIN RS232RxPin,Baud_2400,TimeOut,Main,[noparse][[/noparse]char]
    · IF char <> "a" THEN SerCheck
    · SERIN RS232RxPin,Baud_2400,TimeOut,Main,[noparse][[/noparse]char]
    · IF char <> "l" THEN SerCheck
    · Serin RS232RxPin,Baud_2400,TimeOut,Main,[noparse][[/noparse]Str Serial_RX\6\cr] ' ** THIS IS THE LINE OF INTEREST **

    Main:

    I haven't checked this code, but you get the idea.

    I don't work for Parallax so I can say this: You are ultimately responsible for your design PERIOD.

    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "SX-Video Display Module" Available Now.

    www.sxvm.com

    "A problem well defined, is a problem·half solved."
    ·
  • dazzaldazzal Posts: 4
    edited 2005-03-29 15:00
    Bean,

    Thanks for that, however i dont see how this is any different to the original code. You still have SERINs' that are WAITing and noise could still hang any one of those lines right?

    Waiting for three successive characters worth of noise in one line is surely the same as waiting for each character worth of noise individually?

    Vbr,
    Darren
  • Tom WalkerTom Walker Posts: 509
    edited 2005-03-29 15:04
    dazzal,

    I think that this one falls squarely into the realm of a design error. The Parallax help file for the SERIN command (at least in the 2.1 version I have on this machine) states "Here's a very important concept: this timeout feature is not picky about the kind of data SERIN receives; if any serial data is received, it prevents the timeout. "

    Keeping a line from floating (and potentially confusing the program into thinking that data is there...as Bean has noted) is something that can (and should be) handled in the hardware as a matter of good design. I think that Parallax is innocent in this case.

    One thing to consider... Has there been any equipment moved near the offending device recently? Even something like a new flourescent light can potentially provide a great "signal" for your SERIN "antenna." I recall working in customer support and investigating multiple incidences of a hospital computer crashing... due to a certain sweater being worn by an operator.

    HTH

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Truly Understand the Fundamentals and the Path will be so much easier...
  • BeanBean Posts: 8,129
    edited 2005-03-29 15:08
    dazzal,
    There is no "wait" in any of the SERIN lines.
    If there is no signal the serin will timeout and jump to "Main", if there is noise, then "char" will be set to a junk value and serin will still end and eventual the "count" timer will jump to "Main" but it will NOT hang.


    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "SX-Video Display Module" Available Now.

    www.sxvm.com

    "A problem well defined, is a problem·half solved."
    ·
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-03-29 17:19
    allanlane5 said...
    Wow. I thought the SERIN as you have it would time-out at 5 seconds whether it was recieving data or not. You'd get whatever had come in during that 5 seconds. This sounds like a job for Jon and Parallax.
    Allan,

    ·· The e-mail was addressed with the same response as Bean posted in reply to the OP.· As for the timeout, the counter that handles the time is reset each time data is received.· Theoretically you could receive garbage data contiuously and never timeout under these circumstances.· My guess is it's environmental noise issues, but I don't really have enough data other than what's been posted.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage

    Parallax Tech Support
    csavage@parallax.com
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-03-29 17:38
    Darren,

    ·· We apologize that you're having problems with your application using our product.· We strive to provide the user with all the information necessary to utilize the product without problems, but being such an inherently diverse product, it's almost impossible to address all the possible issues that can arise in a particular application.

    ·· As Tom pointed out, design issues can be a real pain when issues show up in the field, but that doesn't indicate you were misled.· The information we provided isn't guaranteed to work in all applications, and in fact there are some guidelines listed in the Stamp manual regarding error correction and flow control.· Including the use of resistors as needed.

    ·· In fact the manual states that, "Serial communication, because of it's complexity, can be very difficult to work with at times."· Then it provides guidelines to help.· Please see this section for possible solutions to future design issues.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage

    Parallax Tech Support
    csavage@parallax.com
  • allanlane5allanlane5 Posts: 3,815
    edited 2005-03-29 18:10
    Very clever solution Bean -- the problem seems to be coming from using BOTH the open input AND the 'WAIT' keyword. If Darren doesn't use the WAIT keyword, then the 'random noise' coming in will force the SERIN to end once one byte of 'noise' has been recieved.

    Otherwise, the SERIN statement will not time-out, because it IS getting something, but will not complete, because the WAIT condition is never met.

    So your solution removes the 'WAIT' clause, and should solve the problem nicely.

    I'd still like to know if a 'dummy plug' tieing RX to ground would be possible for Darren to implement. And yes, even a new 'noisier' flourescent fixture installed in the same room as the device could trigger this.
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2005-03-29 18:14
    Hi Darren,

    A couple of things about this puzzle me. First, when you say, "if the connection is left open", do you mean that there is no cable or anything of the sort connected to the serial input? This sort of noise coupling only occurs when there is attached that can act as an antenna. If there is no unterminated cable, no antenna, the noise level would have to be HUGE to cause this problem. The problem can also arise if you leave an intrument (notably a modem) attached to the serial input, and the noise originates from that outside connection. But I infer that you don't have anything like that going on. Right, no cable, no connection to anything at all?


    I don't think you can attribute this to any change in the PIC16C57 or in the BASIC Stamp p16 interface. The rxd input to the Stamp has a 10 kohm resistor to ground. Actually, 10k to the base of an NPN transistor and another 10k from the base to ground. That is why it takes a relatively large and low impedance source signal to drive that input. You say you connected a 39k resistor to PLUS POWER and that got rid of the artifact. A resistor to ground is a better idea. The resistor to (+) could put the system in a BREAK state, which believe me you do not want.

    How did you determine that the system is hanging on the serial input line? For example, if the whole system is resetting and starting the program over from the top, it might look the same.

    To troubleshoot I would hook this up to a 'scope and add a PULSOUT at the very top of the program to probe for resets, and I would look at the signal at pin 2 on the PIC to see if there are in fact noise artifacts coming through and to track down where they are coming from.

    Does this happen in every single unit you have now, at every location? Or is it localized, and/or restricted to boards you have recently manufactured? Maybe there was a change in your power supply or a bad component in you latest batch?


    [noparse][[/noparse]quote]What we are finding all of a sudden, is that the instrument is HANGING forever on this SERIN line if no RS232 connection is made between
    our instrument and a computer (i.e. if the connection is left open).
    If I put a pull up resistor (on the computer side of the 22K resistor) of say 39k to PLUS POWER (which could be anything from 10 to 24V)
    then this cures the problem. HOWEVER, we cannot just fit a resistor because the instrument is approved as intrinsically safe, therefore
    any modifications made MUST be approved before the instrument can be shipped. So this is a MAJOR problem for us.

    We assume that there has been some kind of electrical change to the I/O pin(s) of the PIC16C57 but this has not yet been confirmed
    by Microchip.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • allanlane5allanlane5 Posts: 3,815
    edited 2005-03-29 18:16
    Well, Tracy, from his code you can see he is using Pin 7 as his 'Rx' signal -- putting a 22 Kohm resistor in series as he should have. This is not a 'port 16' RS-232 port problem -- which is what it sounds like you are talking about.
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2005-03-29 18:47
    Oh, right Alan. I hadn't noticed the pin 7 declaration. So, the pullup resistor is okay. Indeed, it should be part of the design.

    That does change the picture. A floating Stamp input can jump all over the place in response to weak coupling from internal or external noise sources.

    As a retro fix, to avoid having to retrofit a pullup resistor, I would try setting the pin HIGH just before executing the SERIN command. That at least would charge the pin to a solid initial value. The SERIN command will turn the pin back to an input at the last possible instant.

    HIGH RS232RxPin    ' initialize pin as solid high output
Serin RS232RxPin,Baud_2400,TimeOut,Main,[noparse][[/noparse]Wait("c","a","l"),Str Serial_RX\6\cr]  ' ** THIS IS THE LINE OF INTEREST **



    A floating pin can usually hold a charge for a few seconds before drifting down to the switching threshold. Make the timeout as short as possible, say 3 seconds instead of 5 seconds.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
Sign In or Register to comment.