ZBasic Forum

I've had a ZX40 running on a breadboard for a few thousand hours. Recently, I've been having trouble downloading applications to it. Being a testbed, it's had it's share of downloads, a few thousand at least.

I'm downloading using the No DTR option, through an FTDI FT232R.

Most of the time the device just doesn't respond. Performing a power cycle and trying again fixes the problem for 1 download. Sometimes, it works the first time without a hitch. The issue is not code specific, so the running application is not, as far as I can tell, interfering. To be thourough, the currently running application offers the following when it's diagnostic routine is run:

Application output wrote: 2.3.0.
Ram Size 1536
Ram Start 160
Ram Used 323
Heap End 1696
Stack Pointer 522
Fault Type 0
Fault Data 1 0
Fault Data 2 0
Stack Margin 6
Reset Flags 8

To make things more interesting, today, I received an error that I had never seen before

IDE wrote: >C:\Program Files\ZBasic\IDE\..\zload -c3 -a04 -v "D:\Projects\uG\Software\ZBasic\ZXOnly.zxb"
Download completed successfully.
.
No verify ack from device.
>Exit code: 1

I immediately tried again and received the standard "Device failed to respond..."

Same for the third try.

Cycle the power and try again gives the "No verify ack..." error, and the device hangs.

After a reboot, the application is again active and performing normally, but the device no longer accepts downloads.

So I'm wondering if the ZX is getting flaky, or if the FTDI chip is to blame. Both of them have about 3000 hours of runtime. Currently, I'm rewiring to use a MAX232 to try downloading using the DTR.

Edit: The No DTR response error as been appearing intermittently for a while, but the new error has only been present since the V2.3 VM and compiler update was installed. Perhaps a bug has crept in?

-Don

Don_Kirby wrote:the new error has only been present since the V2.3 VM [...] was installed.

What serial EEPROM are you using? If it is other than the default type (e.g. AT25256A) it may be that the EEPROM configuration was not restored after the firmware update. If that is the case, you can reset the EEPROM configuration using the IDE or the zload utility.

If that is not the problem, we'd be happy to send you a new ZX-40 (or ZX-40a as the case may be) to see if that has any effect.

The EEPROM is the standard AT25256A.

After a few dozen attempts, reboots, and errors, it seems to be working properly. 1 attempt didn't work and the next one did. I'm not familiar enough with the underlying AVR hardware or software to even guess at the cause of the problem.

I appreciate the replacement offer. I think that I'd prefer to keep using the device until its complete failure (if it does) in order to learn a bit more about the failure modes. The more I learn now, the better equipped I will be to handle the support calls later.

Also, can you explain the compiler error message? The description seems to indicate that the data transfer was complete, but not enough time had passed to support that.

-Don

Don_Kirby wrote: [C]an you explain the compiler error message?

If you're referring to the message "No verify ack from device.", that is actually from the downloader that is part of the IDE. It means that during the verification pass the device failed to give an acknowledgement to a record.

The preceding message indicates that the download phase completed successfully. If verification is enabled, a second pass is performed, sending the records of the download file again. During the verification pass, the ZX compares what's in memory with what's in the verification record. It is supposed to send a positive acknowledgement for each record that matches and a negative acknowledgement when a record fails to match.

Hi All,
I'd like to ask advice on a problem similar to that reported by Don_Kirby about 12 months ago, whereby I have been trying to download to a ZX40 via a Lantronix UDS1100 serial-to-ethernet converter.
After finding that the DTR just doesn't get handled by the Lantronix at all, I then went on to try DTR-less downloading.
I've found that if I make a normal download to the ZX40 via the normal DTR serial programming, and then change over to the Lantronix with DTR-less programming, it will take the program the first time.
Then I f I try and download the program a second time, it gets to ~50 records, and then reports a failure to respond.
If I then try and download a program to the ZX40 thereafter, the IDE simply comes back saying the ZX didn't respond to the ATN character (I've set it up to be 9).
HOwever, if I then change back to the normal serial downloader (using DTR), the ZX takes the program. Then, if I change over to the Lantronix again, and download using DTR-less programming, the same thing happens - it takes the program the 1st time, then chokes at record 50 the second time, and then won't take anything at all for any subsequent attempts.
Anyone got any clues?
Any advice appreciated.
Cheers,
GlenJ

I went through a spate of downloading using Lantronix and Moxa ethernet to serial converters. What I found was that these do toggle DTR et al but don't do so with the timing accuracies assumed by the ZBasic IDE/downloader. I change the source code to the downloader and got some success. But at that time, this and other things triggered the DTR-less download option and that's worked reliably.

stevech wrote:... What I found was that these do toggle DTR et al but don't do so with the timing accuracies assumed by the ZBasic IDE/downloader. I change the source code to the downloader and got some success. But at that time, this and other things triggered the DTR-less download option and that's worked reliably.

Thanks for the feedback, Stevech. I've checked the signal levels on the UDS1100 DTR line with a CRO, while sending out a programming command, and it doesn't move at all.
Not quite sure about your last comments - what source code changes can you make to the ZBasic downloader (presumably through the IDE)?
Also, if 'other things' triggered the DTR-less download option, isn't that a false triggering?

Would appreciate any advice on why the DTR-less download works first time, only partly the second time, and not at all thereafter? Any thoughts?
Cheers, GlenJ

As I recall there are three ways to initiate a download.

1. Toggle DTR

2. Use a special character in the serial stream.

3. Use the API

#1 is hardware dependent and even normal hardware serial ports can sometimes be troublesome. I have W98 and Debian on an older machine. W98 sometimes has troubles with USB/Serial adapters. Surprisingly, Debian is just the opposite, working with the USB/Serial adapter but not with the standard ports.

#2 runs the risk of accidentally triggering it if your datastream happens to include the special character. My datastreams tend to include all possible byte values.

#3 is best but requires writing your own downloader.

GlenJ wrote:

stevech wrote:... What I found was that these do toggle DTR et al but don't do so with the timing accuracies assumed by the ZBasic IDE/downloader. I change the source code to the downloader and got some success. But at that time, this and other things triggered the DTR-less download option and that's worked reliably.

Thanks for the feedback, Stevech. I've checked the signal levels on the UDS1100 DTR line with a CRO, while sending out a programming command, and it doesn't move at all.
Not quite sure about your last comments - what source code changes can you make to the ZBasic downloader (presumably through the IDE)?
Also, if 'other things' triggered the DTR-less download option, isn't that a false triggering?

Would appreciate any advice on why the DTR-less download works first time, only partly the second time, and not at all thereafter? Any thoughts?
Cheers, GlenJ

I abandoned making changes to the C source code for the downloader, to try to lessen the timing dependencies, so that the ethernet to serial coverters can work with the DTR-toggling scheme for invoking a download. I gave up and went to the DTR-less method where you setup a special character in the Zxx module and ensure that character never occurs in your data streams while the DTR-less mode is enabled. I assume you've read about how to use that capability. I was trying to modify the C code before the DTR-less scheme was available.

Many thanks for your suggestions. Yes, I'm not that familiar with programming with the API. However, I still haven't found any other way to get either the UDS1100 working with DTR, or the ATN-less downloading to work. I've been told that Perle make an ethernet to serial converter that does have good DTR control, but it's priced at several $100. May have to try it, but a bit of a waste if it still doesn't toggle the DTR line correctly. The Lantronix XPort looks attractive, but have been told it's also got difficulties transmitting DTR correctly.
Cheers,
GlenJ

GlenJ wrote:I still haven't found any other way to get either the UDS1100 working with DTR

I'd be interested in taking a look at the signals ending up at the ZX when using the UDS1100. Would you be willing to send it to me for a few days? If you indicate in the affirmative here I'll send you a separate email with shipping/mailing instructions.

Hi Don,
Thanks very much for your kind offer, and I'd like to take you up on it. Unfortunately I've got the unit in service to receive information from a remote system which I'm commissioning. I wouldn't be able to free it up for another month. Can we return to the prospect of sending it to you then?
Cheers, GlenJ

GlenJ wrote:Can we return to the prospect of sending it to you then?

Sure. In the mean time, I have an XPort on order that I can experiment with.

Don,

I have an XPort mounted on a breakout board that can plug into a breadboard. You can borrow it if it will save you some time. I should also have a spare breakout board if I can find it.

dlh wrote:I should also have a spare breakout board if I can find it.

Thanks for the offer. I had ordered a breakout board, too. They should both be here some time next week.