Download problems with 20M

[bridden]

I've been doing some designing with the Picaxe 20M chip and I've stumbled into the download nightmare. Looking around the forum it seems that a few others have had this issue - albeit with 18X chips mostly. So - here is the run down of my testing on a variety of PCs.

Test configuration (kept the same, PCs swapped out): AXE118 with 20M chip. Powered at 4.5V and 5V. USB010 serial adapter from Rev-Ed. Latest programming editor version 5.2.2. Drivers installed and checked to be prolific 2.0.0.7 - downloaded from Picaxe site.

A total mix of results depending on the PC used:

PC1: ASUS XP Home SP3, Athlon64 X2 Dual core 4200, 2GB RAM. VIA Rev 5 USB host controller.

PC1 Result - fails with verification errors, byte 190, byte 82, byte 228 - nothing consistent. Very occasional pass.

Measured the voltages on this beast. As per specification, -0.5V low and 5V high during the serial port test within prog-ed.

PC2: Advent netbook, XP home SP3, 1.6Ghz Atom processor, 1Gb RAM, Intel 82801G USB host controller.

PC2 result: PASS

PC3: MSI Windows Vista Ultimate SP0 32bit, Athlon 64 Dual core 5200, 2 GB RAM, Standard Open HCD USB host.

PC3 result: fails with verification errors - nothing consistent. Never seems to pass.

PC4: Via Samuel2 800Mhz, 128 Mb RAM, Windows XP Pro SP2. Via Rev 5 USB host controller.

PC4 result: PASS

PC5: Pentium III 650Mhz, 512Mb RAM, Intel 82371 PCI to USB controller. XP Pro SP2

PC5 result: PASS

PC6: Core 2 Duo 2Ghz, XP SP2, 1Gb RAM.

PC6 result: Some failures and some verification errors, probably 80% success, 20% failure. No pattern to which byte fails.

Also tried: BAT85 diode circuit - no impact.

Conclusion: Looks to me like a performance related issue. Fast dual core PCs seem to cause the download a problem. In fact, the faster the PC with less reliable it becomes. The Core 2 Duo seems to be on the "edge" - anything faster and it fails.

Ideas?

 

[moxhamj]

Hmm, maybe it is the speed. I've deliberately gone for slower pcs for my picaxe work (800Mhz) because these are freebie giveaways and they also come with a standard 9 pin serial port at the back. Hopefully the brains trust can shed some light.

 

[Mycroft2152]

Hmm, maybe it is the speed. I've deliberately gone for slower pcs for my picaxe work (800Mhz) because these are freebie giveaways and they also come with a standard 9 pin serial port at the back. Hopefully the brains trust can shed some light.

Where are the Seven Dwarfs when you really need them?

 

[Dippy]

Grumpy here...
I've never had an issue so can't provide an answer.
I've used the AXE027 on several Pentium-based desktops and an AMD based HP notebook and never had a glitch (other than my own doing). But nothing new and superfast.

All I'll say is that I have seen on many occasions, with other devices, that problems crop up with PCs as they get faster or OS changes.

Trouble is that there are so many variables... hardware, OS, Drivers ad nauseum.
Sometimes a solution for one PC won't work for another.
Sorry, it must be very frustrating and hopefully someone will come along with a slick solution.

PS. I'm sure Doc will be along in a minute...

 

[hippy]

It could be speed related and it could also be related to other issues, in particular how the USB drivers are configured with buffering, timeouts and so forth. I'm not an expert on USB but have read of similar issues with USB-to-serial links for non-PICAXE products having similar problems on some PC's but not others and it seems there that system speed is also in the equation.

The Programming Editor doesn't control the serial ports, it simply asks Windows to provide access to a port, tells Windows to send data and asks what Windows received. It should not matter whether the serial port is a physical port, USB, over-LAN or WiFi or whatever, as far as the Programming Editor is concerned it's talking to 'a serial port', the same as any other. So, whatever the problem, it would not seem to be related to the Programming Editor software itself.

One thing you could try is to disconnect the cable from the PICAXE, link the RX and TX together and see how it responds using Terminal within Programming Editor, HyperTerm or some other terminal emulator, see if there is data corruption there. It's not possible to simulate the timings of a real PICAXE download so that may work while download does not.

Beyond that, opening Device Manager and tweaking whatever configuration options there are there may help. That's the suggestion I've seen elsewhere which seems to have solved other people's problems.

The USB010 uses an old ( given the speed industry moves on ) Prolific chipset and it may be that it or their drivers are not well suited to higher-speed systems. You could try with an AXE027 ( FTDI-based ) download cable, and it may also be worthwhile trying a download using a physical serial port cable. If that works, but USB doesn't, it would confirm that the issue is something external to the Programming Editor.

 

[tiscando]

At the moment, I download picaxes with an Emachines desktop PuC with a 2.6GuHuz celeron (which only works like a 1GuHuZ pentium according to floating point maths) CaPU and it's OsS upgraded to vista premium. When I download (via the serial port), the CaPU usage goes up to 100%, and it takes 5 seconds to download the table for the eX1 parts.
When I simulate a program on PE, my fujitsu laptop with a 1.73GuHuZ pentium eM CaPU simulates faster at the maximum speed than the desktop PuC.

At one time, I had a LED-560Ohm connected between the TaXDuh and GuND, and when it's downloading, the LED flashes about 12 times per second.

If my picaxes are downloaded with a much faster computer, does the Programmer wait for the PICk to send an "I'm ready" signal (e.g. a single pulse) before sending the next byte/word/diword/quadword, or would the PICk just get overwhelmed, causing verification errors?

 

[hippy]

The download protocol is not published but data transfer is done using a send then wait for verification mechanism for robustness so the PICAXE cannot be overwhelmed with a flood of data arriving too fast, besides, the US serial output should not be running faster than 4800 baud.

Theoretical maximum transfer rates at 4800 baud should be around 480 bytes per second one-way. The PICAXE however needs to receive data, update its internal memory, verify then send a response, the PC is waiting for that response and then has to re-schedule the Programming Editor to run and use the response so the throughput is less than theoretical. I suspect it is this scheduling time which adds the most delay as I've never been able to improve upon the throughput in my own programs using the same send and wait for acknowledgement mechanism with other hardware.

Download of a 256 byte table in 5 seconds is in the right ball park based upon the time it takes to download a 256 byte program into an 08M on my PC. Why CPU usage would go up to 100% I don't know; the Programming Editor should probably have suspended but there will be plenty more processes Windows has activated to do the transfer. Maybe CPU usage does go up to 100% on all PC's and Windows OS's, again, I don't know.

Getting 12 flashes per second monitoring data transfers doesn't sound right. 256 bytes in 5 seconds is 50 per second, if it were transferring data at 12 per second a download of 256 bytes would take over 20 seconds. On an 08M with LED+R on Output Pin 0 ( Serial Out ) which due to the mechanism described earlier reflects what's also coming in to the PICAXE, the LED lights and flickers continuously during the download. I see the same monitoring the received signal when I've done that.

Simulation execution on a 1.7GHz Pentium most likely will be faster than on a 2.6GHz Celeron. Apart from ( for the same GHz marking ) a Celeron is around half the speed of a Pentium, there will be differences in bus, DRAM, cache and even video memory timings. The same OS on different hardware may run differently to maximise performance as best it can, different OS's will give different performances overall.

 

[bridden]

Further test

I've tested another PC - again totally identical in terms of PICAXE hardware used.

New PC: 3Ghz Intel Core 2 Duo, 3Gb RAM, Intel Southbridge providing USB, XP Pro SP2

Result: PASS (very occasional failure).

Hence it looks like something to do with AMD chipsets as a super-fast Intel still works. I'm going to buy the latest USB cable from Rev-Ed now as the prolific seems to be a problem.

 

[hippy]

It is possible that make of CPU, brand of motherboard or BIOS manufacturer has an effect. I had to upgrade Windows 95 to 98 over a similar issue with AMD+VIA M/B not working with a network card in some particular circustance.

 

[tiscando]

So it's not to do with the CaPU speed.

In my case, PEh uses up 80-90% of the 2.6GuHuZ celeron (I think it as 1GuHuZ pentium) CaPU when simulating and downloading, with the other 10-20% used up by other programs. It simulates faster at maximum speed (20ms) on my 1.73GuHuZ celeron laptop, but still uses 80-90% of the CaPU.

5-6 seconds to download 0s in the table, and 6 sec to download 0s in the eeprom.

I now think the led did flash up to 40HuZ, but it was flickering, so I didn't think it was 50HuZ.

 

[Tricky Dicky]

I have noticed that USB ports are not as rugged as initially made out. Quite a few well used machines at our school now have "dodgy" ports especially the ones the pupils use. These can give variable performance depending on what is plugged in. The PC on my desk has a port which will happily read of a Sandisk memory stick every time, sometimes give problems with a printer plugged in it and point blankly cannot read my Easy Disk memory stick. All the other ports will do all three no problems.

Richard