Hi Mark,
Very interesting, maybe nobody actually uses those slow rates any more — doesn't surprise me.
I'm attaching the UART datasheet which I used when working on the software, the modules we have here all have the identifier SCC2698BC1A84 on the chip which matches the Ordering Information on page 2. The
Clock Select Register values are shown on page 15. The driver sets
ACR[7] = 1 which page 17 of the data sheet documents, you could try setting if to 0 and re-test as the first set of rates also supports 1200 baud, but it changes some of the other rates. It's possible that newer modules might have a slightly different chip
with different settings there, is yours that exact same chip number?
- Andrew
Complexity comes for free, Simplicity you have to work for.
From:
Mark Rivers <rivers at cars.uchicago.edu>
Date: Friday, November 3, 2023 at 3:20 PM
To: Mrinal Bera <mrinalkb at uchicago.edu>, Johnson, Andrew N. <anj at anl.gov>
Cc: Goetze, Kurt <goetze at anl.gov>, Tech-talk <tech-talk at aps.anl.gov>
Subject: RE: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module
Hi Andrew,
I have done the same thing adding 300 and 600 baud. I see the same thing as Mrinal, all baud rates (including 300 and 600) work except 1200.
However, I have connected a scope to the loopback line and discovered a much more fundamental problem. All baud rates below 4800 are wrong, they are much faster than the nominal values.
I configured an asyn record as shown in the attached screen shot. It sends the letter U at 10 Hz with no terminator. U is 01010101 in binary so it is a nice square wave with 5 pulses.
I then measured the waveform on a scope with 100 microseconds/division horizontal and 5V/division vertical. The waveform is -10V to +10V. There is no measurable noise.
I have attached a slide that shows the waveforms at all 8 selectable baud rates. 38400, 19200, 9600, and 4800 are exactly as expected. At 9600 each pulse is very close to 100 microseconds wide. At 4800 baud
we only see 3 of the 5 pulses at this scope trace rate.
However, 2400 baud the waveform is actually faster than 38400, and 1200 is even faster. At 600 and 300 it slows down, but 300 is close to 19200.
There appears to me to be something fundamentally wrong with either the UART hardware or the EPICS driver.
Mark
From: Mrinal Bera <mrinalkb at uchicago.edu>
Sent: Friday, November 3, 2023 1:45 PM
To: Johnson, Andrew N. <anj at anl.gov>
Cc: Mark Rivers <rivers at cars.uchicago.edu>; Goetze, Kurt <goetze at anl.gov>; Tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Cannot do successful RS-232 communication with baud rates <2400 with VME and IP module
Hi Andrew,
Following your instructions, I have now added the 300 and 600 baud rates in the tyGSOctal.c code and recompile my apps. Interestingly, with both the baud rates (300 and 600) I could successfully communicate
with loopback but the problem still exists with the 1200 baud rate. Does this indicate that noise problems only exist with a 1200 baud rate? How can check this noise in a scope trace?
On Nov 3, 2023, at 12:32 PM, Johnson, Andrew N. <anj at anl.gov> wrote:
Without seeing a scope trace I wouldn't completely rule out the possibility of noise from the VME chassis or the IP carrier board.
The driver code for setting the baud rate is the routine below from tyGSOctal.c. You could add options for 300 and 600 baud, those would need register values of 0x44 and 0x55 respectively (110 baud would be
0x11).
LOCAL STATUS tyGSOctalBaudSet(TY_GSOCTAL_DEV *dev, int baud)
SCC2698_CHAN *chan = dev->chan;
switch(baud)
{ /* NB: ACR[7]=1 */
Complexity comes for free, Simplicity you have to work for.
-
The corruption may have something do with noise on the data line, say a few spikes that just happen to fall at the same time as some of the data bits at that specific baud rate.
I don’t think that can be the problem. We are seeing this with a 1” loopback wire from pins 2-3 on the Greensprings breakout. We are seeing the identical behavior on 2 completely different systems in 2 locations.
I also don’t understand why 300 and 600 baud say they are not supported, since the Ip-Octal-232 datasheet says it supports 18 baud rates starting at 50 baud.
Could it be the interface between drvAsynSerialPort and the Ip-Octal driver? The baud rate support in asyn has changed over time.
I have looked at the code in IPAC's tyGsOctal.c VxWorks driver and cross-referenced the bit-rate register settings with the UART data-sheet and I don't see why the 1200 baud rate shouldn't work. The only difference
is the 1 byte value written to one register. The corruption may have something do with noise on the data line, say a few spikes that just happen to fall at the same time as some of the data bits at that specific baud rate.
If I were investigating in detail I might try some different data patterns to see whether the data corruption is a fixed pattern or is somehow related to the data being sent out — a series of spaces and/or
'@' signs would only have one bit set in each byte. This might need a scope on the data line to look at properly though.
Complexity comes for free, Simplicity you have to work for.
I tested with my VxWorks system in the sector 13 electronics lab today. I reproduced the behavior Mrinal is seeing. This is all different hardware from Mrinal’s.
I put a loopback from pin 2 to 3 and used the asyn record to send a string and read the response. It works fine with the following baud rates:
300, 600, and above 38400 report that the baud rate is not supported on the VxWorks console.
1200 does not report that it is unsupported, but the readback is incorrect, it does not match the output.
If 1200 was previously working at APS beamlines then we need to figure out if there was a change to the driver that broke it.
Mark Rivers made the suggestion to change the settings. Which is a good suggestion of course. To that I would add, for me, the next thing I would do is get on the port and sniff the traffic.
Let’s go off-line (off tech-talk) for now, you can bring me your boards and I can test them if you want.
Although the RS-232 settings for Lakeshore 330 are (Baud rate:1200bps, Parity: Odd, Stop bits:1, Data bits: 7), I tried to test the loopback with your suggestions (data bits: 8, parity: none), and got different
input/outputs for 1200 baud rate as shown in the attached image. With 2400 and above baud rates the input/output values are the same as expected.
The IP-Octal modules I am trying to set are old modules from SBS. We have ordered some new ones (IP-520) from Acromag, but I haven’t yet received them. We will look into the Moxa option as well.
ioc3idb in sec.3 is running a LakeShore330 at 1200 baud, using the VME/IP-Octal.
Mostly these days we use Moxa “device servers” to run RS232 ports, I see some examples of the LakeShore330 being run this way here.
Just as a longshot, what company built your IP-Octal-232 modules? Did these come from the old supplier (SBS?), or did they come from an “Artisan” type company that does re-pops of legacy hardware? If the
latter, I would be suspicious.
IIRC we actually moved away from the IP-Octal-232 in favor of an Acromag (IP520?) board, towards the end of our VME era. These days much prefer a Moxa.
I checked the setup with two IP-Octal-232 modules, and they both showed similar behavior. I have been using Lakeshore so far but with soft IOC using on a Raspberry Pi computer. This is the first time I am
trying to interface it through VME and the IP-232 module. Can you tell me which beamline at APS is using Lakeshore through VME?
Your loopback test results suggest a hardware problem to me. Have you tried the test using a different (or new) IP-Octal-232 card? Also, I would send more and different characters, to see if any patterns
or other failure modes emerge.
LakeShore 330’s have been used here at the APS, at 1200 kbps, from what I can tell searching through ioc setup files.
Hello,
While configuring RS-232 communication through XM-octal breakout boards with TVME-200 (with IP-Octal serial module) and MVME3100 using EPICS 7.0 and vxWorks-6.9.4, I did some quick tests with asynRecord. I found the following:
1) With loopback communication(when I sorted the 2 and 3 terminals of the RS-232 ports) with the baud rates of 2400 and above, I received the same input and output values (as shown in the 1st attached image). That shows that RS-232 communication is OK.
2) With the baud rate of 1200, the Output and Input values of asyRecord are different (as shown in the 2nd attached image). I suspect either the tyGSModule or TVME-200 with IP-Octal Serial board has some issue with communication baud rates below 2400.
When I checked the IP-Octal Serial module documentation I found the baud rate information as ‘Programmable in 18 steps to 34.8kbps’. I dug further into the information regarding the baud rate of the chip used in the module (i.e SCC2698B). I found that the chip
supports 26 fixed baud rates from 50 to 38.4kbps. Hence, I think 1200 kbps should be supported by the chip and IP-Octal Serial module.
I need the baud rate of 1200kbps to interface the Lakeshore 330 temperature controller with EPICS on VME hardware. Did anybody try to interface Lakeshore 330 with VME and IP modules?
Best regards,
Mrinal
|