ATN Timing - can it be less precise

[stevech]

I've been using a Moxa NPort to access a ZX24 that cannot be near the development PC. It's worked fine for a long time. Suddenly, the IDE now gets gets a lot of ID sequence failures- says Failed to respond to ATN. Indeed, the menu choice for RESET works and with a program running in the ZX24, I am able to communicate. Then all at once the downloads work repeatedly again.

So I conclude that the expected timing for toggling ATN is too critical for the delays through the wireless LAN and perhaps the virtual COM device on the PC. Odd, this worked for weeks and hundreds of downloads. Comes and goes, maybe WiFi channel access contention.

Ping times are 4 or 5 mSec and reliable.

Any chance that the IDE could be changed to be a more tolerant of delays?

[dkinzer]

Any chance that the IDE could be changed to be a more tolerant of delays?

My conjecture is that it is probably not the IDE, but it could be. To come up with a remedy we first need to determine what the problem is. For this purpose, it may be useful to have a serial comm monitor on either or both ends. On the PC end, I've used the free HD Software Serial Port Monitor to good effect. It allows you to see the data and timing on both the transmit and receive sides. It may also be useful to utilize the ZLoad sample utility (contained in the new installer) along with Visual Studio to determine what's going on.

[stevech]

Any chance that the IDE could be changed to be a more tolerant of delays?

My conjecture is that it is probably not the IDE, but it could be. To come up with a remedy we first need to determine what the problem is. For this purpose, it may be useful to have a serial comm monitor on either or both ends. On the PC end, I've used the free HD Software Serial Port Monitor to good effect. It allows you to see the data and timing on both the transmit and receive sides. It may also be useful to utilize the ZLoad sample utility (contained in the new installer) along with Visual Studio to determine what's going on.

I have HD Softare Serial Port Monitor - I'll see what it says.

thanks

[stevech]

Update - I found by trial and error, that at least for the Moxa Nport and its MS Windows XP Pro virtual COM device driver, that choosing an ATN period of 10 rather than 20mSec seems to cure the intermittent failure to ID the ZX module type.

Let me see if the cure persists though! It seems to consistently fail with 20mSec and not with 10mSec.

It is near Halloween though.

[dkinzer]

I'm certain that the default period is 10mS in both the IDE and in zload. Did you mean to say that 10mS works and 20mS does not or vice versa?

[stevech]

sorry if I got the default wrong.

I just now checked again...

10mSec works. 20mSec does not.
Duty cycle set to 50%

[stevech]

well, doggone. The intermittent problem where the IDE says "failed to respond to ATN" still comes and goes. Sometimes it works.

This is the situation where the ZX24a is connected to the serial port of a Moxa Nport which connects to the Etherner or WiFi network. A special COM driver on windows talks IP. With a direct RS232 connection no problems occur.

So this episode, I found this information:

with Zload -c4 -a5:50 -i

it works every time. when I choose -a9:50 or more, it does not work. Changing the duty cycle has no affect (50 or 1, same).

Though Zload -a5:50 works, the same settings in the newest IDE do not. Unrelated, the IDE will not let me choose less than 5.

The ZX4a is resetting reliably. The problem area is some assumption the IDE or Zload or the DLL make regarding pulsing DTR via Windows and my virtual COM driver and the IP connection/delays. Odd though, that it often works. I thought it might be WiFi latency due to interference. But the same things happen when I direct-connect to the 100BT LAN via a switch then on to the router. I don't know, but some LAN traffic might add latency, but it seems that it would be small.

The DTR goes true from the NPort whenever the COM port is opened. I suppose it stays true until the IDE/DLL begin to toggle it during the ATN sequence. I think a direct serial port connection also sets DTR true when the port opens (in Windows XP by default).


So something in the ATN logic in the DLL/IDE is intolerant of imperfect conditions.

Code: Select all

C:\Program Files\ZBasic>zloadSpecial.exe -c4 -a9:50 -i
Device failed to respond to the ATN signal.

C:\Program Files\ZBasic>zloadSpecial.exe -c4 -a5:50 -i
ZX24a v1.4 1251,cef5

C:\Program Files\ZBasic>

Ping the Moxa NPort (however, this isn't via the WIndows COM driver)

Code: Select all

Pinging 192.168.1.213 with 32 bytes of data:

Reply from 192.168.1.213: bytes=32 time=1ms TTL=255
Reply from 192.168.1.213: bytes=32 time=1ms TTL=255
Reply from 192.168.1.213: bytes=32 time=1ms TTL=255

[stevech]

another clue to the serial-over-ethernet occasional problem - whenever the PC gets in the "mood" to say the ZX module ID cannot be determined (by toggling DTR) - even though the ZX does reset - I now discovered that rebooting the PC cures the problem. Rebooting the ethernet-to-serial unit (NPort) doesn't.

I discovered that when in this no-workie condition, if I close the com port in the ZBasic IDE and go open a terminal program, then toggle DTR on/off a few times, leaving it off, that the IDE works.

Speculation: the virtual COM driver in the PC and the Nport device get out of synch on the actual state of DTR. You'd think this would have no impact to the ZBasic downloader, since the module's detection is a capacitor-coupled edge detector (rising edge). Maybe there's a situation where the number of pulses is off by one if DTR is toggling in an opposite phase than the IDE thinks? Would cause the wrong number of pulses?

I wonder if the problem would be fixed if the DLL did a three ioctls() in a row, with a delay between each , to set DTR true then false and again false, before starting the toggling for purposes of module ID.

Perhaps the toggling gets out of phase across the ethernet because one or more toggles are ignored if they come to quickly.

It's speculation.

[stevech]

update: speculation, above, that the ATN fails due to some DTR state out-of-synch ... wrong.

I believe the problem is in the Moxa Nport windows virtual COM driver. Rebooting the PC fixes the problem where the IDE will not ID the module.
Every other thing I've tried doesn't work or works inconsistently. (No newere version of sofware from Moxa).

I should try the Lantronix WiPort (I have one) or the Xport. They have a virtual COM driver too.