Another Case Of Verification Error On Download

IRQ

New Member
I'm getting the common "verification error" when trying to download a program to my PICAxe and I'm looking for assistance. I'm trying to program the little 08M2 surface mount servo module using an AXE027 download cable. I recently bought everything from Robotshop, so it should all be legit parts and not bootleg.

I've done a bunch of searching here on the forum and understand that most of the problems are power supply related, and with that in mind, I've already put additional capacitance in place with no effect. I'm powering the module with a powered breadboard power supply which should have plenty of oomph and I've placed both large (330uF) and small (.22uF) caps right where the board plugs into the breadboard. The SMT servo board also comes with a small ceramic SMT cap soldered right next to the PICAxe chip.

I've scoped the communications lines and the waveforms (with an old non-storage analog) scope. Voltage levels look good, and as best as I can tell without storage, the signals look clean.

I've also tried plugging the AXE027 cable into all of the different USB ports on my machine. No change.

Here's a couple pics of the problem(s). Here's what happens when I download a program. The byte number for the error location jumps around, but I can't get a full clean download:
error1.jpg

I get the same error just trying to erase the part:
error3.jpg
 

IRQ

New Member
I also get the same error using both AXEpad and Editor 6:
error4.jpg

And here's what happens when I run a loopback test of the AXE027 cable:
loopback.jpg

Is it potentially as simple as a bum cable?
 

techElder

Well-known member
Voltage levels look good,
Is this only on the ONE PICAXE? Does it do this on any other PICAXE parts? Could be a bad PICAXE memory location.

What voltage is the PICAXE operating on? 5V or 3.3V or ?

I've had this happen with a loose power supply wire. Sometimes dropped the voltage while the programming was going on, but it wasn't "every time."
 

IRQ

New Member
Thanks for the input Tex,

I have two of the little SMT 08M2 boards and I get the same behavior with both. So I don't know if ten parts would do the same thing, but I'm two for two with the parts I currently have at my disposal.

As for power supplies... I've tried on both a regulated 5V supply and a variable supply (set at approx. 12V) which I locally regulated down to about 5V with an LM317.

I also tried using the variable supply cranked down to 3.5V and got the same issue.

I haven't tried three 1.5V batteries, and I guess for completeness I should, but I just can't believe that would do anything different.
 

techElder

Well-known member
Sounds like you need to try replacing the cable based on your loopback test and that its the only other thing you can simply change out.
 

IRQ

New Member
Seems weird though as the cable seems to be pretty much bulletproof for everyone else. I found a couple vague references on the forum of people suggesting bad connections in the cable, but couldn't turn up anything definitive.

Have you seen cases of verified bad AXE027 cables? And if so, was the failure location identified? Was it a simple wiring connection issue, or a problem with the electronics molded into the USB end?

Reason I ask is that ordering a new cable will take time, money, and I'll probably end up in discussions with the vendor about whether the cable was defective or not. If I can fix the one I have, I'd rather do that. This simple project is turning into a big ordeal!
 

hippy

Senior Member
Is it potentially as simple as a bum cable?
It does look that way from your cable test results. A signal getting disconnected intermittently could give the sort of verification issues you are seeing.

The AXE027 is generally pretty robust and we've shipped thousands which have worked without problems but I believe there have been a couple of cases where the contact between wires and jack plug has failed.

It may be worth trying the cable test again, perhaps gently flexing the wire near the jack to see if that makes things better or worse.
 

IRQ

New Member
It may be worth trying the cable test again, perhaps gently flexing the wire near the jack to see if that makes things better or worse.
Thanks Hippy. Will do.

But this time I think I'm going to take one of the female phone jacks back off a servo board and solder some wires directly across the Tx and Rx pins so I can rule out flaky connections from alligator clips. That way I can plug the phone jack end back into the female socket and flex the cable without having to worry about an alligator clip moving around and giving a false failure.

Thanks again for all the assistance, and I'll post results when I get that done.
 

IRQ

New Member
Here's the loopback test results with the phone jack inserted into a shorted receptacle socket. I still see the occasional error, but flexing the cable did not seem to make it any better or worse.

I tried to find a flex location somewhere on the cable that would make it better or worse, but couldn't find any location that caused a noticeable change:
loopback3.jpg
 

IRQ

New Member
I do wish you had mentioned "alligator clips" at the beginning. {sigh}
You don't have to worry about the clips. I had high confidence in the connections I was making before, but now I have very high confidence.

Any suspicion of the clips is a red herring. Unfortunately.
 

hippy

Senior Member
Interesting that the error was in 12 and 19 as before, though not elsewhere. Will have to think on what that may mean but suspect it's more coincidence than clue.
 

IRQ

New Member
I was thinking the same thing. Prior to capturing that screen shot, I re-ran the test a number of times and the failures seemed to be relatively random, but they rarely started right away and often seemed to occur in the same locations.

The failures also seem to be of similar "type", like maybe one dropped bit. I haven't dug out my old ASCII chart, but I suspect I'm dropping or adding the occasional bit here and there. That kind of behavior is what makes me wonder if I'm looking at a traditional broken connection kind of failure here.

I already verified that I can measure the two 10K resistors to ground in the cable, and I have verified that the phone jack tip is connected to the shield shell at the USB end as well as one of the pads inside the USB connector.

If there's anything else you can think of to test, please let me know. I appreciate the help.
 

IRQ

New Member
I re-ran the loopback test a bunch more times making sure I did not disturb the cable at all. On two consecutive runs, I got these two results.

I do not think we are dealing with a complete random situation here. This is one run:
loopback5.jpg

And after cancelling and restarting the test routine utility, I got this:
loopback6.jpg

They aren't identical, but just too close to be random failures. Another potential clue is that if I did not restart the whole cable test wizard (and just used the back button to restart the numbering sequence to message #1), then it did not seem to follow the same pattern.
 

hippy

Senior Member
Do you have, or can borrow, another computer or laptop to try it on ?

As you say it does look too much like coincidence to be simply random but it's hard to guess how it could be something systemic.
 

IRQ

New Member
I will see if I can try it on another computer. Might not be able to do that for a couple days, but I'm working on it.

I also dug out an old Win 2K laptop that still had a nine pin serial port*. If I can't figure out how to get the USB thing working, I might be able to use that old machine with the older native serial cable, right?

I did manage to get that old machine to boot, but that's about it so far. Haha!! Do you know if the AXEpad software will run on a 2K machine? :)

* and a CD ROM drive, AND a 3.5 inch floppy drive!!
 

IRQ

New Member
Thanks for the suggestion.

Yes, I tried rocking that latency number around with no effect. At least as far as 10 and 22. In the end, I put everything back to default (16).

I haven't tried another computer yet, but I'm hoping to be able to do that today. Fingers crossed! :)
 

IRQ

New Member
So I got my hands on another computer and tried everything again. Different machine, different OS, fresh install of everything. And the result?

Got the same kind of errors on the loopback test, and downloading to my target resulted in the same verification errors. So, I assume I'm most likely looking at a cable problem, right?

Here's what I got for loopback test on a second computer. Really doesn't look completely random:
loopback7.jpg
 

hippy

Senior Member
It does seem bizarre that the error tends to be in the same place but I would guess it is some sort of cable fault.
 

IRQ

New Member
I agree. Really intriguing to see such similar errors on two completely different installs.

I've seen the schematic of what's molded inside the USB end of the AXE027 cable, but I have no visibility into what's inside the chip. I know pretty much nothing about the protocols involved, but it seems likely that there's at least some internal buffering of data through on-board RAM, etc.

So, I bought all my stuff from Robotshop. Do you think I should just tell them about the cable and buy another one, or is this cable something you would like to see?
 

PhilHornby

Senior Member
There's an FT232R in there - the only modification from standard being that TXD,RXD,RTS & CTS are set to "Inverted". You can use the FTDI FT_PROG, available here: http://www.ftdichip.com/Support/Utilities.htm#FT_PROG to query it.

I have successfully used a fake FTDI adapter to program a Picaxe, just by altering those settings. To be clear, in the case of your AXE027, I'm not suggesting you make any changes!
 
Last edited:

hippy

Senior Member
So, I bought all my stuff from Robotshop. Do you think I should just tell them about the cable and buy another one, or is this cable something you would like to see?
It would probably be best to contact Robotshop to let them know of the issue, ask their advice on what to do, and to determine what their procedure for returning and/or replacing goods believed to be damaged or faulty would be.
 

IRQ

New Member
Thanks for the help guys.

Phil, Thanks much for the info on the FTDI chip innards. I think I'm going to contact Robotshop first before I go poking around inside the AXE027.

But before I do either, I'm going to try programming my target from my old Win2K machine that has a real DB9 RS-232 port on it. That way I can at least determine for sure if my issues have absolutely nothing to do with my target board(s).
 

IRQ

New Member
Update: I was able to download error free from my old machine through the native serial port. So Phil, apparently the answer to your question is 'apparently not'. No changes to the target required other than attaching wires because I wasn't using the phone jack on the end of the USB adapter cable.

So this confirms that my power supply is fine and my target is healthy. Another finger pointing at the cable.

Unfortunately, that old machine is a little flakey and unreliable or I would just stick with it instead of the newer one. It's also not on any network (and I don't want to put it on one). I will still need a better "real" solution. but at least I have more info.
 

PhilHornby

Senior Member
Another finger pointing at the cable.
Just to eliminate the Picaxe-related software, how does the cable respond to other Comms. software?

I tried Putty and Realterm, with a simple loopback on the jack plug (i.e. short "a" and "b" the two nearest the body of the plug). Realterm would send a string of characters that were echoed back successfully, even @ 921600 baud. (It has a "Send" function and a "Repeats" field). In Putty you can send the contents of the paste buffer, by right-clicking in the Window.

With AXE027 I used, I couldn't generate any visible errors.
 

IRQ

New Member
I don't have any of those terminal emulators loaded.

Which one is the smallest, simplest, easiest to use? I'm a simple, low feature kind of guy. :)
 

pxgator

Senior Member
You could use the terminal within PE6. Just click on the 'PICAXE' tab then
click the terminal icon. It's very simple and easy to use. It is very easy to
configure the serial port, baud rate, etc.

Cheers to All
 

PhilHornby

Senior Member

Janne

Senior Member
Remember, if you're doing loop testing on AXE027 it will not detect a fault in the ground wire.
Way back in time, my first thread on the forum was about download problems. They were finally solved only after I ground open the usb-plug, traced the cable and finally found a bad ground wire on the 3.5mm plug.
 

IRQ

New Member
You could use the terminal within PE6.
I believe the original suggestion was an attempt to eliminate the PICAxe related software, thinking that maybe the errors I was seeing were actually caused by something in the PE6 environment.

However... Skipping to the punch line, I tried the terminals in both PE6 and Axepad, and could not get the errors to recreate there.

So I don't know what's going on. I continue to see errors when I use the loopback diagnostic test built into PE6, but I cannot get similar errors when just entering text into either terminal window. And (in Axepad at least) I was able to load up the output buffer with hundred lines of text and watch them come back without incident.

I've also made contact with Robotshop, and they have been extremely responsive so far. All I did was fill out a ticket and tell them I thought I had a bad cable, and next thing I know, I get a notice that they've shipped me out another cable. So, I guess I'll wait for that other cable to come in and see if it does the same thing. If it works, I'll send them back the screwed up one. But if the second cable does the same thing as the first, I think I'll have to beg their forgiveness and keep looking for the real problem.
 

IRQ

New Member
Remember, if you're doing loop testing on AXE027 it will not detect a fault in the ground wire.
Way back in time, my first thread on the forum was about download problems. They were finally solved only after I ground open the usb-plug, traced the cable and finally found a bad ground wire on the 3.5mm plug.
Janne,

Thanks for the help. I understand, but there are two things here that might rule out that kind of ground issue. First is that I've seen errors while using the loopback test built into PE6, and for that test, the tip of the 3.5mm plug is left as a no-connect. That test does not use the ground signal that far down the cable.

Second, I did put an Ohmeter on the tip of the phone jack and verified I've got good connection to the shell of the USB plug even when bending and twisting the cable. If I run out of ideas, I may end up splitting open the USB plug like you did, but not quite yet.

Do you have any pics of the problem you found? Or a link to your old thread?
 

premelec

Senior Member
FWIW for years I've used a USB to D9 CH340 converter / adapter with my old serial D9 to phone plug cable I started with before the AXE027 existed- hope you get it working - annoying problem!
 

PhilHornby

Senior Member
FWIW for years I've used a USB to D9 CH340 converter / adapter with my old serial D9 to phone plug cable I started with before the AXE027 existed
I've only used AXE027 with the Picaxe and was surprised to find no mention of any level-shifting, or protection diodes when working with the older 'RS232C' interfaces. Actually I was expecting a MAX232 to be somewhere in the mix ... :confused:

Out of curiosity, I had a look at the output of a Prolific USB to RS232C converter I own :-
Prolific.jpg

While not as bad as I thought it might be, there's still in excess of ±6V floating around ... surely a sin to knowingly connect such a thing to a Picaxe :p

Incidentally, as a complete aside - the AXE027 has a 10K resistor to GND, across both its input and output (when compared with a genuine fake FT232R). Anyone know why?

(I'm endeavouring to get an AXE027 to talk to an ESP8266 ... I finally figured out how to make the ESP invert its serial levels, but the 10K resistor stops it booting).
 
Last edited:

hippy

Senior Member
While not as bad as I thought it might be, there's still in excess of ±6V floating around ... surely a sin to knowingly connect such a thing to a Picaxe :p
The 22K resistor of the download interface limits the current into the PICAXE so damage is not done even though the voltage coming in is higher than the PICAXE supply.

Incidentally, as a complete aside - the AXE027 has a 10K resistor to GND, across both its input and output (when compared with a genuine fake FT232R). Anyone know why?
The 10K pull-down on the FT232R input will keep it low when detached from the PICAXE. The 10K pull-down on the FT232R output will keep the input to a PICAXE low if the FT232R output is ever floating, which could happen if disconnected from the PC or during driver initialisation.

The presence or absence of the resistors won't indicate whether an FT232R is fake or not; those resistors are specific for the AXE027 cable.

(I'm endeavouring to get an AXE027 to talk to an ESP8266 ... I finally figured out how to make the ESP invert its serial levels, but the 10K resistor stops it booting).
That doesn't sound surprising. Similar to how the Serial In of a PICAXE can be used as a digital input; it won't boot until it's at the right level, and then the pin can be configured as a digital input by the program.

You may have to use a hardware inverter or reprogram the polarity of the FT232R in the AXE027 cable.
 

IRQ

New Member
So my second cable arrived from Robotshop, and...... Taa Daa... It works fine.

I can switch back and forth between the first and second cables, and the first one always fails while the second one always succeeds. I can also switch back and forth on the loopback test and still see errors during the test with the first cable, while the replacement cable does not have the same behavior.

So, I have no idea what's going on inside that first cable, but there's clearly something wrong with it. And it does not appear to be completely random.

Last time for me to send the defective one direct to someone for autopsy before just I send it back to Robotshop? Anyone want a look? :)
 

IRQ

New Member
The 22K resistor of the download interface limits the current into the PICAXE so damage is not done even though the voltage coming in is higher than the PICAXE supply.
I didn't spend a lot of time looking at the communications waveforms, but I believe I saw that on the scope. The waveforms looked like they were amplitude clipping at the PICAxe end of things presumably because they were forward biasing the protection diodes on the Picaxe and clamping one diode drop above the rail.

I know it's off topic of the original discussion, but I actually have an application for something just like that and was considering doing just that on purpose. I felt funny about starting a discussion where I was admittedly (and purposely) exceeding the voltage ratings on the pin. Maybe I can say that if you did it, then I can too. ;)

Other ideas I've considered are resistor divider, zener clamp, and maybe using an external Schottky so I didn't stress the on-chip protection diode. At this point, I know the resistor divider works but is two components. The zener didn't work right because the current is too low, and I haven't tried the Schottky yet, but I have high confidence.
 

techElder

Well-known member
Other ideas I've considered are resistor divider, zener clamp, and maybe using an external Schottky so I didn't stress the on-chip protection diode.
Usually, clamping input signals is best done in a controlled way externally of the PICAXE without the possibility of ruining a PICAXE. There's probably an economic incentive there, too. :D
 

hippy

Senior Member
maybe using an external Schottky so I didn't stress the on-chip protection diode.
The internal diode clamps are usually able to carry an absolute maximum of 25mA and a suitably high current limiting resistor will deliver far less than that. Even +/-25V RS232 through 22K is only just over 1mA.

There will always be a debate about whether current limiting should be used but a great many people have done that without suffering any adverse consequences.

The only thing to watch for are the Input Only pins on the PICAXE. These are usually the pins used by the PICmicro as VPP/MCLR and do not usually have an internal clamping diode to V+. For those an external clamping diode must be used.
 
Top