lawnmowerman
New Member
Looked at the previous complaint about this error. i am having the same issue, yet none of my problems could be solved by the last post. Any more suggestions guys?
Serial port error 0x9 'Subscript out of range'
- Thread starter lawnmowerman
- Start date
lawnmowerman
New Member
i used the serial port to program the last microcontroller PICAXE 08, so i know it works. The PICAXE 18X is recognized by the editor, yet doesn't program it. I tried reinstalling COM1 and nothing changes.
This subscript out of range error is really damned annoying, especially as it may be an internal Programming Editor error or the actual cause is not reported correctly or meningfully - just whose subscript is it that is out of range, and why is it allowed to go out of range ?
Part of the Gremlin's job today has obviously been to inflict every possible problem on me, and I'm now getting the same error with a PICAXE-08. Checking "Firmware?" works fine and identifies the PICAXE, but as soon as I attempt a download it goes to the "Connecting to Hardware..." splash screen, switches the title to "Downloading Program..." and then >BANG<, "Subscript out of range". With "Clear Memory" the progress bar zooms halfway across the screen at the speed of light, then slowly chugs along until it finally announces "Verification failed", or just chugs from the start.
Been using the hardware for programming reliably during the last 24 hours, yet now it's playing up, and not a clue as to why ( not entirely true, and we'll come back to my theory later ). This is not the hardware I've been tinkering about with either, so nothing's changed there. No other apps open which are using the serial port, it's set for the correct serial port, loop-back test on the cable works okay, etc, etc.
Plug in a different PICAXE-08, same Firmware version - identifies firmware fine, downloads fine, clears hardware fine. Back to the 'dodgy chip'. Identifies firmware, download and clear hardware fail as before. Try the new chip, still works perfectly. Try the old chip, still fails. Neither are labelled but it's now easy to tell which is which.
Scrape the legs clean with a scalpal, no joy.
Make sure that soldering iron is powered off, no joy.
Drop the bench PSU down from 5V to 4.5V, and it works !
Back to 5.0V and back to 'Problem City'.
Short the blocking diode on the Serial In line, no joy.
Check the serial port voltages in case I've damaged them in other experiments. Look the same as always. Unplug the modem and try a different port, no change.
Back to 4.5V and the fanfare rings out again.
What a nightmare, but the problem seems to be not enough juice from the PC serial getting through, and lowering the PICAXE volatge effectively bumps up the serial voltage ( relativity ). The explanation for why identifying firmware works but downloading doesn't, is I suspect because that's triggered by a 'break' which is simply a sustained high on the serial line, so maybe just a small glitch is enough to kick the firmware version number back, but not good enough to make download happen.
If the identify firmware works, then the Programming Editor starts its download, but the PICAXE doesn't see anything, thinks you've given up, and starts running its program. If that happens to be a serial echo program ( notch one up for Sod's Law ) or sending data out via Serial Out ( or toggling pin 0 ( another win for Sod's Law ) and it confuses the Programming Editor into thinking that teh download is happening, then gets its knickers in a complete twist and cacks it with a 'Subscript error'.
Well that's my theory anyway, and I needed to get that sob-story off my chest, it's been a frustrating 24 hours !
Part of the Gremlin's job today has obviously been to inflict every possible problem on me, and I'm now getting the same error with a PICAXE-08. Checking "Firmware?" works fine and identifies the PICAXE, but as soon as I attempt a download it goes to the "Connecting to Hardware..." splash screen, switches the title to "Downloading Program..." and then >BANG<, "Subscript out of range". With "Clear Memory" the progress bar zooms halfway across the screen at the speed of light, then slowly chugs along until it finally announces "Verification failed", or just chugs from the start.
Been using the hardware for programming reliably during the last 24 hours, yet now it's playing up, and not a clue as to why ( not entirely true, and we'll come back to my theory later ). This is not the hardware I've been tinkering about with either, so nothing's changed there. No other apps open which are using the serial port, it's set for the correct serial port, loop-back test on the cable works okay, etc, etc.
Plug in a different PICAXE-08, same Firmware version - identifies firmware fine, downloads fine, clears hardware fine. Back to the 'dodgy chip'. Identifies firmware, download and clear hardware fail as before. Try the new chip, still works perfectly. Try the old chip, still fails. Neither are labelled but it's now easy to tell which is which.
Scrape the legs clean with a scalpal, no joy.
Make sure that soldering iron is powered off, no joy.
Drop the bench PSU down from 5V to 4.5V, and it works !
Back to 5.0V and back to 'Problem City'.
Short the blocking diode on the Serial In line, no joy.
Check the serial port voltages in case I've damaged them in other experiments. Look the same as always. Unplug the modem and try a different port, no change.
Back to 4.5V and the fanfare rings out again.
What a nightmare, but the problem seems to be not enough juice from the PC serial getting through, and lowering the PICAXE volatge effectively bumps up the serial voltage ( relativity ). The explanation for why identifying firmware works but downloading doesn't, is I suspect because that's triggered by a 'break' which is simply a sustained high on the serial line, so maybe just a small glitch is enough to kick the firmware version number back, but not good enough to make download happen.
If the identify firmware works, then the Programming Editor starts its download, but the PICAXE doesn't see anything, thinks you've given up, and starts running its program. If that happens to be a serial echo program ( notch one up for Sod's Law ) or sending data out via Serial Out ( or toggling pin 0 ( another win for Sod's Law ) and it confuses the Programming Editor into thinking that teh download is happening, then gets its knickers in a complete twist and cacks it with a 'Subscript error'.
Well that's my theory anyway, and I needed to get that sob-story off my chest, it's been a frustrating 24 hours !
lawnmowerman
New Member
so is this problem never to be solved?
From other threads on this topic it seems that there are many factors which can bring about Program Editor’s ‘subscript-out-of-range’ error message. This may be another possibility..
When RS232 sending & receiving devices have a slight mismatch with their set baud rates, operation can become marginal where comms will work on some occasions & at other times not. And if it’s a real borderline situation, then the failing comms can sometimes be ‘pattern-sensitive’ also. (And intermittent pattern-sensitive problems can really cause engineers to tear their hair out!) Also bear in mind that because 8 data bits are being transmitted, there is no ‘parity check’ being done to detect possible errors, thereby preventing related error messages that are reported by Program Editor from being more specific.
If Picaxe’s internal oscillator is slightly off-frequency causing a baud rate mismatch to begin with, -then it’s feasible that changing the supply voltage to the device could slightly influence the oscillator & hence the baud rate to the point where comms could be affected one way or the other. (Both model Picaxes being discussed here utilise fully internal oscillators)
Perhaps this is what is happening in Hippy’s particular case -and maybe in some others also. In any event, it wouldn’t be the fault of Rev-Ed, but rather an out-of-tolerance situation occurring in the MicroChip production line.
So, to lawnmowerman –if you have fully checked out <i>& proven </i> all aspects of your PC’s Com Port, then perhaps trying another Picaxe could be a useful next step..
Edited by - whizzer on 04/05/2006 03:37:53
When RS232 sending & receiving devices have a slight mismatch with their set baud rates, operation can become marginal where comms will work on some occasions & at other times not. And if it’s a real borderline situation, then the failing comms can sometimes be ‘pattern-sensitive’ also. (And intermittent pattern-sensitive problems can really cause engineers to tear their hair out!) Also bear in mind that because 8 data bits are being transmitted, there is no ‘parity check’ being done to detect possible errors, thereby preventing related error messages that are reported by Program Editor from being more specific.
If Picaxe’s internal oscillator is slightly off-frequency causing a baud rate mismatch to begin with, -then it’s feasible that changing the supply voltage to the device could slightly influence the oscillator & hence the baud rate to the point where comms could be affected one way or the other. (Both model Picaxes being discussed here utilise fully internal oscillators)
Perhaps this is what is happening in Hippy’s particular case -and maybe in some others also. In any event, it wouldn’t be the fault of Rev-Ed, but rather an out-of-tolerance situation occurring in the MicroChip production line.
So, to lawnmowerman –if you have fully checked out <i>& proven </i> all aspects of your PC’s Com Port, then perhaps trying another Picaxe could be a useful next step..
Edited by - whizzer on 04/05/2006 03:37:53
lawnmowerman
New Member
well, i tried everything now. still no change with the subscript error. im just going to give up on picaxe's in general. i have had nothing but trouble with them since the start.
It is a pity that you give up so soon. You mention that <i>"i used the serial port to program the last microcontroller PICAXE 08, so i know it works" </i> . So it seems like that somthing is working but there are a few problems that keep alluding our attention.
Have you tried another PC? What were the results. You havn't really given us insight into <i>your </i> particular problem - only referred to the fact that you are experiencing the same symptoms as someone else. The fact that they got their's working but you did not suggests that your problem is not the same as their's, so your setup and methods in troubleshooting are very important in order for us to suggest what course of action you should take.
Give us more information as to what you have and havn't tried. Different computers, different chips, different software (computer) setups, different hardware setups (chip and associated circuitry).
All the best and sincerely hoping that you don't give up yet...
<b><i>ylp88 </b> </i>
Have you tried another PC? What were the results. You havn't really given us insight into <i>your </i> particular problem - only referred to the fact that you are experiencing the same symptoms as someone else. The fact that they got their's working but you did not suggests that your problem is not the same as their's, so your setup and methods in troubleshooting are very important in order for us to suggest what course of action you should take.
Give us more information as to what you have and havn't tried. Different computers, different chips, different software (computer) setups, different hardware setups (chip and associated circuitry).
All the best and sincerely hoping that you don't give up yet...
<b><i>ylp88 </b> </i>
I've also had the same problem. I'll try to download a program and it will come up with the subscript out of range error.
I've tried on two computers (my Laptop running XP Pro SP2 and my desktop also running XP Pro Sp2.) They will work occasionally but not work other times.
The problem is intimitant. Yesterday working off my laptop in a free period at school it worked perfectly with probably 6+ downloads all without a hitch. However i set it up today and can't even download once. I can however press the firmware button (in options) and get a positive ID on the 18X chip i'm using
I tried to fix the problem by putting a MAX232 chip inline with the download circuit however the software failed to recognise the chip when the firmware button was pressed after this alteration.
I'm currently working off a home made circuit, on a protoboard using an 18X chip. It is being powered by the +5V out of an old computer switchmode power supply.
The program itself is designed to decode a keypad then send the numbers to the computer via a serial cable
I've tried on two computers (my Laptop running XP Pro SP2 and my desktop also running XP Pro Sp2.) They will work occasionally but not work other times.
The problem is intimitant. Yesterday working off my laptop in a free period at school it worked perfectly with probably 6+ downloads all without a hitch. However i set it up today and can't even download once. I can however press the firmware button (in options) and get a positive ID on the 18X chip i'm using
I tried to fix the problem by putting a MAX232 chip inline with the download circuit however the software failed to recognise the chip when the firmware button was pressed after this alteration.
I'm currently working off a home made circuit, on a protoboard using an 18X chip. It is being powered by the +5V out of an old computer switchmode power supply.
The program itself is designed to decode a keypad then send the numbers to the computer via a serial cable
Hey lawnmowerman, cheerup! 
Don’t give up yet!
Picaxes are being downloaded-to successfully everywhere all the time, and there has to be an explanation for your particular difficulties.
When you said;
> “Looked at the previous complaint about this error. i am having the same issue, yet none of my problems could be solved by the last post. Any more suggestions guys? ”
Perhaps you didn’t see <i>all </i> previous correspondence on this subject. For example, the Tech staff of Rev-Ed released a note on 19 December 2005, concerning problems downloading from Program Editor to a Picaxe 18X. Quote:
“This issue could arise on out of date software - it must be 4.1.0 or later”
You can verify which version of Program Editor you are using by clicking on the menu items: ‘Help’, ‘About’. If the version of software is an old one, then you can download the latest version from Rev-Ed’s Picaxe website.
Hang in there dude –you’ll get there!
Don’t give up yet!
Picaxes are being downloaded-to successfully everywhere all the time, and there has to be an explanation for your particular difficulties.
When you said;
> “Looked at the previous complaint about this error. i am having the same issue, yet none of my problems could be solved by the last post. Any more suggestions guys? ”
Perhaps you didn’t see <i>all </i> previous correspondence on this subject. For example, the Tech staff of Rev-Ed released a note on 19 December 2005, concerning problems downloading from Program Editor to a Picaxe 18X. Quote:
“This issue could arise on out of date software - it must be 4.1.0 or later”
You can verify which version of Program Editor you are using by clicking on the menu items: ‘Help’, ‘About’. If the version of software is an old one, then you can download the latest version from Rev-Ed’s Picaxe website.
Hang in there dude –you’ll get there!
First, try batteries isntead of the PC power supply. We were jsut talking about it in another thread, and it seems to come up on here ALOT. PC power suplies really arent that great. They're not generally stable.
Try batteries. I think it was hippy who said he got it to go away using 4.5 volts instead of 5? The PC PS can put out alot more than 5 volts unless it's drawing a decent current.
--Andy P
Edited by - andypro on 06/05/2006 06:48:03
Try batteries. I think it was hippy who said he got it to go away using 4.5 volts instead of 5? The PC PS can put out alot more than 5 volts unless it's drawing a decent current.
--Andy P
Edited by - andypro on 06/05/2006 06:48:03
3 x AA is <b>definietly </b> the way to go to ensure that you don't have any nasty gremlins in your system. PC power supplies are usually unstable unless you add enough load on each of the lines - perhaps an old hard drive. Generic supplies also tend to have more line noise, especially at light and heavy loads. More expensive, brand name supplies usually have lower line noise but often have a high output power which may result in it either being inefficient to power a PICAXE, or require a higer load before it maintains sufficient regulation.
Is it just me or is this subscript error only becoming a recent ocurrence?
<b><i>ylp88 </b> </i>
Is it just me or is this subscript error only becoming a recent ocurrence?
<b><i>ylp88 </b> </i>
Some of this is repeating what andypro & ylp88 have already said, but I’d already typed this, so here goes..
PC power supply units (PSU’s) are designed to provide power to motherboards, disc drives etc -which they do very well. The problem is that because Picaxe draws so little current in comparison, the operation of a PSU can be very unpredictable with such light load conditions. –And different brands of PSU’s even react in different ways under these circumstances. Yes, you can use a PSU for the purpose –but it has to be loaded with another device (such as an old drive or something) in order for it to operate in a predictable manner.
> <i>”I tried to fix the problem by putting a MAX232 chip inline with the download circuit however the software failed to recognise the chip when the firmware button was pressed after this alteration” </i>
Hope this is telling you something! i.e. it didn’t resolve the issue, & has made the situation somewhat worse –probably because of a slight wiring error in the process of adding the MAX232. This brings up one of the golden rules of troubleshooting; if you are altering your circuitry to assist in locating a problem –if possible, make your circuit <i>simpler </i> , not more complex (because greater complexities can add their own difficulties, thereby clouding the issue of the original problem).
All of this can be said another way: “when problems arise, then go back to basics”.
As Hippy points out, this even applies to programming also. When encountering coding difficulties with a program, –concentrate on getting a little bit working at a time. And then build on that.
BTW: Another factor in favour of using a battery to assist with troubleshooting –it can act like a large capacitor, and filter out noise should it be affecting your circuit.
We hope that you will accept this advice in the spirit it was intended, as the above was not meant to be demeaning in any way, but rather to give a little advice from those of us who are a little bit further down the track than yourself.
Edited by - whizzer on 06/05/2006 08:18:15
PC power supply units (PSU’s) are designed to provide power to motherboards, disc drives etc -which they do very well. The problem is that because Picaxe draws so little current in comparison, the operation of a PSU can be very unpredictable with such light load conditions. –And different brands of PSU’s even react in different ways under these circumstances. Yes, you can use a PSU for the purpose –but it has to be loaded with another device (such as an old drive or something) in order for it to operate in a predictable manner.
> <i>”I tried to fix the problem by putting a MAX232 chip inline with the download circuit however the software failed to recognise the chip when the firmware button was pressed after this alteration” </i>
Hope this is telling you something!
i.e. it didn’t resolve the issue, & has made the situation somewhat worse –probably because of a slight wiring error in the process of adding the MAX232. This brings up one of the golden rules of troubleshooting; if you are altering your circuitry to assist in locating a problem –if possible, make your circuit <i>simpler </i> , not more complex (because greater complexities can add their own difficulties, thereby clouding the issue of the original problem).All of this can be said another way: “when problems arise, then go back to basics”.
As Hippy points out, this even applies to programming also. When encountering coding difficulties with a program, –concentrate on getting a little bit working at a time. And then build on that.
BTW: Another factor in favour of using a battery to assist with troubleshooting –it can act like a large capacitor, and filter out noise should it be affecting your circuit.
We hope that you will accept this advice in the spirit it was intended, as the above was not meant to be demeaning in any way, but rather to give a little advice from those of us who are a little bit further down the track than yourself.
Edited by - whizzer on 06/05/2006 08:18:15
>"PC power supply units (PSU’s) are designed to provide power to motherboards, disc drives etc -which they do very well. The problem is that because Picaxe draws so little current in comparison, the operation of a PSU can be very unpredictable with such light load conditions. –And different brands of PSU’s even react in different ways under these circumstances. Yes, you can use a PSU for the purpose –but it has to be loaded with another device (such as an old drive or something) in order for it to operate in a predictable manner."
I understand that, at the time i didn't have any battery packs lying around and that was the only regulated power supply i could lay my hands on.
I have since tried battries, but with no success. my battries measured at 4.6 volts, firmware read fine, identified as PICaxe 18X 8.6 version.
>"Hope this is telling you something! i.e. it didn’t resolve the issue, & has made the situation somewhat worse –probably because of a slight wiring error in the process of adding the MAX232."
The MAX232 chip was placed as my father and i thought the problem might be a comms error from the comms port recieveing TTL levels and the chip recieving RS232 levels. However it didn't work and after a couple of attempts i reverted back to the standard download circuit.
Someone noted the only chips that seemed to be having these problems are the chips with internal resinators. I've got to replace my chip as two outputs are not working and i'm planning to replace it with a 28X in an attempt to see if this will fix it.
Thankyou for the ideas so far, i would welcome any more ideas anyone has
I understand that, at the time i didn't have any battery packs lying around and that was the only regulated power supply i could lay my hands on.
I have since tried battries, but with no success. my battries measured at 4.6 volts, firmware read fine, identified as PICaxe 18X 8.6 version.
>"Hope this is telling you something!
i.e. it didn’t resolve the issue, & has made the situation somewhat worse –probably because of a slight wiring error in the process of adding the MAX232."The MAX232 chip was placed as my father and i thought the problem might be a comms error from the comms port recieveing TTL levels and the chip recieving RS232 levels. However it didn't work and after a couple of attempts i reverted back to the standard download circuit.
Someone noted the only chips that seemed to be having these problems are the chips with internal resinators. I've got to replace my chip as two outputs are not working and i'm planning to replace it with a 28X in an attempt to see if this will fix it.
Thankyou for the ideas so far, i would welcome any more ideas anyone has
Problems with internal resonators (for chips that use them) are extremely rare indeed.
So rare in fact, that even if it was a factor on your first 18X chip (and it may not have been), -its not likely for you to see the same issue in the next 18X you use.
18x’s are in very widespread use, and (after the baby 08 model), very much a favourite.
So rare in fact, that even if it was a factor on your first 18X chip (and it may not have been), -its not likely for you to see the same issue in the next 18X you use.
18x’s are in very widespread use, and (after the baby 08 model), very much a favourite.
Bravo posters- I'm highly tempted to award this thread a Gold Super Cap & splayed leg DIP IC cluster! Top marks on diligently listing your hardware setup AND consequentual results. Like many Forum regulars I get driven crazy by minimal " It's not working" cries for help, only to find (often many requests later... ) that a key procedure has been confused. <i>" Whada ya mean by PIN/LEG " </i> being typical ...
<b>My 2c worth </b> : Perhaps woes relate to MicroChip PIC manufacture date (shown as YYWW - 0620 would be 2006 20th week) or even the Rev.Ed "burn"? It's arisen before of course in the electronics industry. Recall that DS18B20 retooling nightmare? Can you supply date/code markings on the suspects please ? I last ordered 08Ms & 18Xs late 2005, so have no recent versions.
I've few other insights beyond your own, but FWIW my down under Picaxe experiences have been so favourable that 08 woes last arose in 2002-3,with 18A some months later. ALL hookups since (~1000s ?) have been a breeze- providing the code agrees with the hardware then they just work!- BUT we normally use 3 x AA C-Zn (4.5V)or 4 x AA NiMH (4.8V)during the taming stage. Editing PCs typically are XP laptop/desktops (or a few direct serial W98 Toshiba laptops) with the esteemed Rev.Ed USB-D9 adapter. The only serial woe I recall arose with an old IBM Thinkpad when on its batteries- switching on its mains adapter presumably boosted the serial levels & the problem went away. Although very familiar with the MAX232 & 7805, we've never had to use either with any battery powered Picaxe.
As mentioned recently in another thread <A href='http://www.rev-ed.co.uk/picaxe/forum/topic.asp?topic_id=4490&forum_id=24&Topic_Title=USB+Power&forum_title=PICAXE+Forum&M=True&S=True ' Target=_Blank>External Web Link</a> re USB ,mains PSUs-especially old PC ones,are a Picaxe overkill. They should be BANNED -it's like using a 10 tonne truck just to get your groceries. Appropriate technology guys! No one runs around with a cell phone tethered to a mains charger.
Keeping in mind the educational nature of the whole Picaxe microcontroller approach , it's fair to say that perhaps only 1 in 10 setups ever deserves to end up (here in NZ at least) as a final soldered mains powered project anyway. Most layouts are of course intended to be <b>educational </b> , with circuits typically ripped down (Lego style) for another design/insight/task.
Whoa - almost forgot our Kiwi standby =>www.picaxe.orcon.net.nz/bread08.jpg <A href='http://www.picaxe.orcon.net.nz/bread08.jpg ' Target=_Blank>External Web Link</a>. You were all waiting for that... Stan
EXTRA: Hippy -can you spill the beans on your hi-tech soldering iron please?!
Edited by - stan. swan on 06/05/2006 11:06:03
<b>My 2c worth </b> : Perhaps woes relate to MicroChip PIC manufacture date (shown as YYWW - 0620 would be 2006 20th week) or even the Rev.Ed "burn"? It's arisen before of course in the electronics industry. Recall that DS18B20 retooling nightmare? Can you supply date/code markings on the suspects please ? I last ordered 08Ms & 18Xs late 2005, so have no recent versions.
I've few other insights beyond your own, but FWIW my down under Picaxe experiences have been so favourable that 08 woes last arose in 2002-3,with 18A some months later. ALL hookups since (~1000s ?) have been a breeze- providing the code agrees with the hardware then they just work!- BUT we normally use 3 x AA C-Zn (4.5V)or 4 x AA NiMH (4.8V)during the taming stage. Editing PCs typically are XP laptop/desktops (or a few direct serial W98 Toshiba laptops) with the esteemed Rev.Ed USB-D9 adapter. The only serial woe I recall arose with an old IBM Thinkpad when on its batteries- switching on its mains adapter presumably boosted the serial levels & the problem went away. Although very familiar with the MAX232 & 7805, we've never had to use either with any battery powered Picaxe.
As mentioned recently in another thread <A href='http://www.rev-ed.co.uk/picaxe/forum/topic.asp?topic_id=4490&forum_id=24&Topic_Title=USB+Power&forum_title=PICAXE+Forum&M=True&S=True ' Target=_Blank>External Web Link</a> re USB ,mains PSUs-especially old PC ones,are a Picaxe overkill. They should be BANNED -it's like using a 10 tonne truck just to get your groceries. Appropriate technology guys! No one runs around with a cell phone tethered to a mains charger.
Keeping in mind the educational nature of the whole Picaxe microcontroller approach , it's fair to say that perhaps only 1 in 10 setups ever deserves to end up (here in NZ at least) as a final soldered mains powered project anyway. Most layouts are of course intended to be <b>educational </b> , with circuits typically ripped down (Lego style) for another design/insight/task.
Whoa - almost forgot our Kiwi standby =>www.picaxe.orcon.net.nz/bread08.jpg <A href='http://www.picaxe.orcon.net.nz/bread08.jpg ' Target=_Blank>External Web Link</a>. You were all waiting for that... Stan
EXTRA: Hippy -can you spill the beans on your hi-tech soldering iron please?!
Edited by - stan. swan on 06/05/2006 11:06:03
I just did a non-scientific measurement with a single 18X. Not a statistically good sample I admit.
I measured the Serin/Serout voltages and shapes at ~4.5V (3AA) and 5V. All looked OK nothing odd.
I then measured 18X pulsout at 5.0V and 4.0V (yes, 4V). Simple 100 microsecond pulse. The difference in pulse length was b-all. Not even 0.5%. Measured using a Tektronix TDS1012 scope (cal 2004).
Has anyone been able to scope the 'offending' PC/PICAXE combinations? For comparison with a good combo.
Other than Hippy I haven't seen any vaguely 'scientific' testings/results.
And as there are many different branded serial interfaces has anyone noticed any correlations?
Is it better/worse with USB-Serial adaptors?
Needs some work. A good project for a student.
P.S. Don't forget, MAX232 inverts.
PPS. Extra needs to be taken when powering using SM - especially home-made ones.
Edited by - dippy on 06/05/2006 10:22:03
I measured the Serin/Serout voltages and shapes at ~4.5V (3AA) and 5V. All looked OK nothing odd.
I then measured 18X pulsout at 5.0V and 4.0V (yes, 4V). Simple 100 microsecond pulse. The difference in pulse length was b-all. Not even 0.5%. Measured using a Tektronix TDS1012 scope (cal 2004).
Has anyone been able to scope the 'offending' PC/PICAXE combinations? For comparison with a good combo.
Other than Hippy I haven't seen any vaguely 'scientific' testings/results.
And as there are many different branded serial interfaces has anyone noticed any correlations?
Is it better/worse with USB-Serial adaptors?
Needs some work. A good project for a student.
P.S. Don't forget, MAX232 inverts.
PPS. Extra needs to be taken when powering using SM - especially home-made ones.
Edited by - dippy on 06/05/2006 10:22:03
ylp88 : <i>Is it just me or is this subscript error only becoming a recent ocurrence? </i>
A forum search reveals the Subscript Error has only been reported explicitly since December 2005, but people have been complaining of download problems previously.
The PICAXE-08 I had problems with is from a batch I purchased years ago, so it doesn't point to recent changes in Manufacturing or Firmware revisions.
The more frequent Subscript Errors may be a result of Programming Editor changes, but even if it were, I don't think it's a cause of problems, just not a clear way of indicating what failure happened.
PICAXE-18A's seem to have had the most complaints over downloading, and that probably does equate to INTRC accuracy with that particular PICmicro.
The number of complaints may just be more people coming out of the woodwork to acknowledge they've had problems, whereas they may have ignored them, swapped to a chip which worked and put the earlier problems down to something they did wrong, a temporary board short now fixed or similar, and simply continued. That's my story.
The most likely causes of download failure seems to me to be not getting a reliable signal through ( voltage/current not high enough ), or baud rate errors.
The first could be cured by bumping the input voltage up ( hard ), lowering the PICAXE voltage or reducing the 22K value. Given that there are not numerous complaints from laptop (0V/5V) owners, it's surprising to see problems with a desktop PC (-/+12V).
Baud rate errors could be caused by voltage or temperature change, but it should take +/-6% before the PICAXE has problems ( the PC receiver may be even more tolerant ).
It could be that the PC UART is drifting out of spec rather than the PICAXE, but that feels less likely.
Turning it round from what could cause a problem to what cures it, dropping the PICAXE voltage does seem to be a reliable solution. Analysing that also points to an increase in input signal or a possible change in baud rate which fixes it.
I went back to my problematical 08, and it worked fine first time at 5V so couldn't test the reducing 22K theory.
Something I have noticed in the past with 08's when I have had download problems and swapped to other PICAXE's to keep development going - Leave them sitting around for a few days and they appear to work again ! It's as if there's some 'memory effect' happening, weird and inexplicable as that may be. Could it be the chip cooling ?
That even a 'faulty' PICAXE does respond to a "Firmware?" check and it gets beyond "Connecting to Hardware..." to "Downloading Program..." means it is going through its download acknowledgement even when it won't download.
It's perhaps this usually works, sometimes doesn't, issue which is most frustrating. Something must be changing between one time and another but it's hard to tell what.
I've unfortuantely now jumbled up my 08's so don't know which was the failing one, but if it fails again I'll mark it and look at doing some tests to see if I can isolate what the problem may be. I don't have a scope so analysis won't be complete but I'll see what I can discover.
A forum search reveals the Subscript Error has only been reported explicitly since December 2005, but people have been complaining of download problems previously.
The PICAXE-08 I had problems with is from a batch I purchased years ago, so it doesn't point to recent changes in Manufacturing or Firmware revisions.
The more frequent Subscript Errors may be a result of Programming Editor changes, but even if it were, I don't think it's a cause of problems, just not a clear way of indicating what failure happened.
PICAXE-18A's seem to have had the most complaints over downloading, and that probably does equate to INTRC accuracy with that particular PICmicro.
The number of complaints may just be more people coming out of the woodwork to acknowledge they've had problems, whereas they may have ignored them, swapped to a chip which worked and put the earlier problems down to something they did wrong, a temporary board short now fixed or similar, and simply continued. That's my story.
The most likely causes of download failure seems to me to be not getting a reliable signal through ( voltage/current not high enough ), or baud rate errors.
The first could be cured by bumping the input voltage up ( hard ), lowering the PICAXE voltage or reducing the 22K value. Given that there are not numerous complaints from laptop (0V/5V) owners, it's surprising to see problems with a desktop PC (-/+12V).
Baud rate errors could be caused by voltage or temperature change, but it should take +/-6% before the PICAXE has problems ( the PC receiver may be even more tolerant ).
It could be that the PC UART is drifting out of spec rather than the PICAXE, but that feels less likely.
Turning it round from what could cause a problem to what cures it, dropping the PICAXE voltage does seem to be a reliable solution. Analysing that also points to an increase in input signal or a possible change in baud rate which fixes it.
I went back to my problematical 08, and it worked fine first time at 5V so couldn't test the reducing 22K theory.
Something I have noticed in the past with 08's when I have had download problems and swapped to other PICAXE's to keep development going - Leave them sitting around for a few days and they appear to work again ! It's as if there's some 'memory effect' happening, weird and inexplicable as that may be. Could it be the chip cooling ?
That even a 'faulty' PICAXE does respond to a "Firmware?" check and it gets beyond "Connecting to Hardware..." to "Downloading Program..." means it is going through its download acknowledgement even when it won't download.
It's perhaps this usually works, sometimes doesn't, issue which is most frustrating. Something must be changing between one time and another but it's hard to tell what.
I've unfortuantely now jumbled up my 08's so don't know which was the failing one, but if it fails again I'll mark it and look at doing some tests to see if I can isolate what the problem may be. I don't have a scope so analysis won't be complete but I'll see what I can discover.
Stan : <i>EXTRA: Hippy -can you spill the beans on your hi-tech soldering iron please?! </i>
It is reasonably hi-tech despite the problems it seemed to be causing recently. I think the noise being picked up by the PICAXE/PC/cable was the temperature control kicking in and out.
From http://www.maplins.co.uk - LS20 Soldering Station, part number N78AR - Was on a 9.99 special offer when I bought it a year or two ago.
It is reasonably hi-tech despite the problems it seemed to be causing recently. I think the noise being picked up by the PICAXE/PC/cable was the temperature control kicking in and out.
From http://www.maplins.co.uk - LS20 Soldering Station, part number N78AR - Was on a 9.99 special offer when I bought it a year or two ago.
Unfortunately, like many "standard" computer error messages, the method to solve the problem is not very clear, if possible at all! It would consequently be nice if Technical could expedite a version of Prog. Ed. which has more error trapping, especially in the serial communications routines.
Even if the problem is not explicitly stated in the error message, at least it could identify the part of code that is causing the problems and we could report this to Technical who can then look at the particular part of the code which appears to be playing up.
<b><i>ylp88 </b> </i>
Even if the problem is not explicitly stated in the error message, at least it could identify the part of code that is causing the problems and we could report this to Technical who can then look at the particular part of the code which appears to be playing up.
<b><i>ylp88 </b> </i>
I agree. This is all very odd.
I genuinely find it hard to believe (though I'm obviously not saying impossible) that a slight voltage change will put the oscillator out of kilter enough - assuming there's nothing mega-critical in the bootstrap.
Ditto typical room temperature changes.
Surely, if you programmed a 'temperamental' PICAXE you would be able to measure any V/T timing changes - IF that was the problem. Perhaps that needs doing?
And lets face it PICs can operate at lower voltages. If their osc. spec went that far out between just 4.5 to 5.0V then Microchip would have a lot of returns, as an osc. change would affect many functions. So, other than a faulty PIC I'd be surprised if it were the chip.
My tests (albeit on only one IC) showed the programming pin levels to be well in excess of 0.8Vdd when downloading using the recommended component values. As you say, that sort of thing ought to be more apparent on 0/5V serial. But perhaps it is an electronic issue of the particular PC serial interface UART or connection?
This is where it would be SO handy to scope the pins to get some actual voltage/timing/noise numbers.
I may have missed it, but I have yet to see a full explanation of the actual error message from Technical or exsctly what precisely causes it. I hope its not a one-size-fits-all error message.
I genuinely find it hard to believe (though I'm obviously not saying impossible) that a slight voltage change will put the oscillator out of kilter enough - assuming there's nothing mega-critical in the bootstrap.
Ditto typical room temperature changes.
Surely, if you programmed a 'temperamental' PICAXE you would be able to measure any V/T timing changes - IF that was the problem. Perhaps that needs doing?
And lets face it PICs can operate at lower voltages. If their osc. spec went that far out between just 4.5 to 5.0V then Microchip would have a lot of returns, as an osc. change would affect many functions. So, other than a faulty PIC I'd be surprised if it were the chip.
My tests (albeit on only one IC) showed the programming pin levels to be well in excess of 0.8Vdd when downloading using the recommended component values. As you say, that sort of thing ought to be more apparent on 0/5V serial. But perhaps it is an electronic issue of the particular PC serial interface UART or connection?
This is where it would be SO handy to scope the pins to get some actual voltage/timing/noise numbers.
I may have missed it, but I have yet to see a full explanation of the actual error message from Technical or exsctly what precisely causes it. I hope its not a one-size-fits-all error message.
I'll agree ambient and environmental changes shouldn't be affecting a chip that much but there are some reports to this forum that they do, and the AXE033 Serial LCD module did need to be modified to work with all 18X's. Some chips seem more prone than others.
When download fails, the resulting outcome does seem to depend upon what program has been previously downloaded and may be executing while the Programming Editor thinks it is downloading. I've found there's a far greater chance of strange behaviour if the PICAXE was loaded with a program which sends data back to the PC via Serial Out.
Subscript Error isn't overly informative, but does at least indicate that downloading failed. I have had a situation with an 18X where a download was reported as successful but wasn't. There appears to be a lack of accurate error checking and confirmation of success in the download protocol, and that particular problem was revealed ( after a lot of effort, hair pulling and frustration ), by an "EEPROM 0,($AA)" put in the program; with it a verify error occured, without it, success was being reported when it wasn't successful.
I had put the error down to an intermittant 3-pin molex connection, but I'm no longer convinced it was necessarily that problem.
Someone else recently reported that their PICAXE was claiming successful download but the PICAXE still kept running a previous program; that could have been a similar situation.
It's hard to say all this without giving the impression that there is some serious flaw with the PICAXE, and it's true to say that the overwhelming majority of people don't seem to have any problems at all ( or haven't noticed them ), but there certainly are one or more issues which need some further investigation.
I'm starting to wonder how many "PICAXE Firmware Erased", "Clear memory corrupted my Firmware", and "It was working but just stopped downloading" can be put down to the same problem ?
Edited by - hippy on 06/05/2006 17:02:00
When download fails, the resulting outcome does seem to depend upon what program has been previously downloaded and may be executing while the Programming Editor thinks it is downloading. I've found there's a far greater chance of strange behaviour if the PICAXE was loaded with a program which sends data back to the PC via Serial Out.
Subscript Error isn't overly informative, but does at least indicate that downloading failed. I have had a situation with an 18X where a download was reported as successful but wasn't. There appears to be a lack of accurate error checking and confirmation of success in the download protocol, and that particular problem was revealed ( after a lot of effort, hair pulling and frustration ), by an "EEPROM 0,($AA)" put in the program; with it a verify error occured, without it, success was being reported when it wasn't successful.
I had put the error down to an intermittant 3-pin molex connection, but I'm no longer convinced it was necessarily that problem.
Someone else recently reported that their PICAXE was claiming successful download but the PICAXE still kept running a previous program; that could have been a similar situation.
It's hard to say all this without giving the impression that there is some serious flaw with the PICAXE, and it's true to say that the overwhelming majority of people don't seem to have any problems at all ( or haven't noticed them ), but there certainly are one or more issues which need some further investigation.
I'm starting to wonder how many "PICAXE Firmware Erased", "Clear memory corrupted my Firmware", and "It was working but just stopped downloading" can be put down to the same problem ?
Edited by - hippy on 06/05/2006 17:02:00
@Stan: My offending PICaxe is stated as: 0506 (2005 week 6) (bought however only a week ago, must do a roaring trade in them down under ) so again, not suggesting a recent firmware problem.
It could be software related, i'm using the most recent version, but i doubt it.
I'm going to try changing the 22k in line with the download circuit to a smaller value see if that improves communications between everything.
) so again, not suggesting a recent firmware problem.It could be software related, i'm using the most recent version, but i doubt it.
I'm going to try changing the 22k in line with the download circuit to a smaller value see if that improves communications between everything.
Hello to Knight again
You mentioned in your post of 6-May-2006 8:23 (UK time) that <i>“I've got to replace my chip as two outputs are not working…” </i>
One could assume from this comment that to some degree your 18X has been ‘cooked’ (i.e. damaged). If this is the case, then it can’t be assumed that other aspects of the chips operation haven’t been affected to some extent also.
So for a variety of reasons now, it’s probably a good idea to get a replacement for your chip as soon as you can. And be daring & get another 18X! (after all, there are huge numbers of them in successful use), –unless of course you need a 28X for other reasons.
We at this Forum will be very interested on how you progress with this. We will be delighted to hear your next report!
Regards
Edited by - whizzer on 07/05/2006 03:01:21
You mentioned in your post of 6-May-2006 8:23 (UK time) that <i>“I've got to replace my chip as two outputs are not working…” </i>
One could assume from this comment that to some degree your 18X has been ‘cooked’ (i.e. damaged). If this is the case, then it can’t be assumed that other aspects of the chips operation haven’t been affected to some extent also.
So for a variety of reasons now, it’s probably a good idea to get a replacement for your chip as soon as you can. And be daring & get another 18X! (after all, there are huge numbers of them in successful use), –unless of course you need a 28X for other reasons.
We at this Forum will be very interested on how you progress with this. We will be delighted to hear your next report!
Regards
Edited by - whizzer on 07/05/2006 03:01:21
Yeah that would be correct, in some way shape or form my chip has 2 dead outputs. One my be my fault (connecting a LED to ground without a current limiting resistor) however i don't know what happened to the other one.
I'm going to go and buy a new chip tomorrow, and i might buy both a 18X and 28X, see if one works and one doesn't. And if the 18 works, then i have the 28 to use in one of my other projects.
I'm going to go and buy a new chip tomorrow, and i might buy both a 18X and 28X, see if one works and one doesn't. And if the 18 works, then i have the 28 to use in one of my other projects.
Having worked through this (long!) thread we would like to make a few points:
a) We appreciate that a handful of users are having an issue. This must be very frustrating for them, but this small number also has to be considered a tiny percentage compared to the hundreds of thousands of PICAXE chips sold. However we need to resolve the issue and so will help as we can.
2) The 'subscript out of range' error message and asssociated incorrect progressbar movement were not helpful, we apologise for this and belive we have fully corrected in 4.1.17, a patch is now available for download on the software page of this website.
The subscript error message main cause would be the PICAXE chip not correctly echoing the downloaded byte back to the computer (ie an issue has occurred during programming). Its been said a thousand times before, but the normal cause is an incorrect power supply. 4.5V from 3x AA cells is your friend for testing here.
In theory it could also be caused by incorrect serial port voltages. A common mistake that could cause this would be connectig the 10k on the wrong side of the 22k.
2) Its not really fair to do testing with chips that have been electrically stressed beyond datasheet limits. Any chip that has been connected to an unloaded computer suppply, as already discussed in this thread, is almost certain to have been exposed to a voltage higher than 6.5V - we have just tried in our workshop and measured 7.8V on such a device. In this case the chip should therefore be considered permanently damaged. It may well still work (and probably would) but there is no knowing what internal damage could have occured to the silicon. Any chip with 'blown output pins' will almost certainly have other internal damage aswell. No fair test can be made with a chip in this state.
3) Resonator tolerance / serial transmissions. Most people incorrectly assume that resonator tolerance could cause a 'long serial transmission', such as the download, to fail - as they assume that the timing intolerance increases error over the time of the download and so near the end of the download the chip could be 'out of sync'.
This is not actually true. The PICAXE actually only ever has to stay in 'sync' for the length of a single byte! This is never a problem to do! This is because , in simple terms, the download processes works like this:
1) computer sends byte, PICAXE receives
2) PICAXE programs memory byte internally
3) PICAXE checks internal programming and transits echo
4) small delay then repeat
During the delay between bytes any cumulative resonator tolerance timing errors is reset to nil - so the serial stream is only ever a byte long! We have extensively tested this process by using PICAXE-08 chips deliberately incorrectly programmed with timing errors, and were very surprised at how wide a tolerance was possible - certainly much more than temperature would ever affect a chips internal resonator!
The only problem could occur if the computer sends single bytes quicker than it should, so there is no delay between bytes. This should not be an issue in the software as is, but for some time we have already had a 'extra delay' feature in the software for testing, so we have now made this visible for end users. In 4.1.17 you can select an additional delay between bytes from the View>Options>Port menu. This means you can now 'slow down' your download to see if this helps those having an issue.
4) It is not possible to overwrite/damage the PICAXE bootstrap during a normal download. In fact on chips like the 08 / 08M they have no internal PIC mechanism to even allow the bootstrap memory area to be programmed! However incorrect power supply etc could damage the chip internally.
a) We appreciate that a handful of users are having an issue. This must be very frustrating for them, but this small number also has to be considered a tiny percentage compared to the hundreds of thousands of PICAXE chips sold. However we need to resolve the issue and so will help as we can.
2) The 'subscript out of range' error message and asssociated incorrect progressbar movement were not helpful, we apologise for this and belive we have fully corrected in 4.1.17, a patch is now available for download on the software page of this website.
The subscript error message main cause would be the PICAXE chip not correctly echoing the downloaded byte back to the computer (ie an issue has occurred during programming). Its been said a thousand times before, but the normal cause is an incorrect power supply. 4.5V from 3x AA cells is your friend for testing here.
In theory it could also be caused by incorrect serial port voltages. A common mistake that could cause this would be connectig the 10k on the wrong side of the 22k.
2) Its not really fair to do testing with chips that have been electrically stressed beyond datasheet limits. Any chip that has been connected to an unloaded computer suppply, as already discussed in this thread, is almost certain to have been exposed to a voltage higher than 6.5V - we have just tried in our workshop and measured 7.8V on such a device. In this case the chip should therefore be considered permanently damaged. It may well still work (and probably would) but there is no knowing what internal damage could have occured to the silicon. Any chip with 'blown output pins' will almost certainly have other internal damage aswell. No fair test can be made with a chip in this state.
3) Resonator tolerance / serial transmissions. Most people incorrectly assume that resonator tolerance could cause a 'long serial transmission', such as the download, to fail - as they assume that the timing intolerance increases error over the time of the download and so near the end of the download the chip could be 'out of sync'.
This is not actually true. The PICAXE actually only ever has to stay in 'sync' for the length of a single byte! This is never a problem to do! This is because , in simple terms, the download processes works like this:
1) computer sends byte, PICAXE receives
2) PICAXE programs memory byte internally
3) PICAXE checks internal programming and transits echo
4) small delay then repeat
During the delay between bytes any cumulative resonator tolerance timing errors is reset to nil - so the serial stream is only ever a byte long! We have extensively tested this process by using PICAXE-08 chips deliberately incorrectly programmed with timing errors, and were very surprised at how wide a tolerance was possible - certainly much more than temperature would ever affect a chips internal resonator!
The only problem could occur if the computer sends single bytes quicker than it should, so there is no delay between bytes. This should not be an issue in the software as is, but for some time we have already had a 'extra delay' feature in the software for testing, so we have now made this visible for end users. In 4.1.17 you can select an additional delay between bytes from the View>Options>Port menu. This means you can now 'slow down' your download to see if this helps those having an issue.
4) It is not possible to overwrite/damage the PICAXE bootstrap during a normal download. In fact on chips like the 08 / 08M they have no internal PIC mechanism to even allow the bootstrap memory area to be programmed! However incorrect power supply etc could damage the chip internally.
Rickharris
Senior Member
Thanks for a prompt response Tec - On a Sunday as well!!
I am sure that others will appreciate the level of support Rev Ed give their hobby users.
Edited by - rickharris on 07/05/2006 17:34:51
I am sure that others will appreciate the level of support Rev Ed give their hobby users.
Edited by - rickharris on 07/05/2006 17:34:51
In defence and praise of the PICAXE, despite what problems there have been, the 10K/22K serial interface has proven reliable in the overwhelming majority of cases, and has been used in many PICmicro and with other micro projects elsewhere. The same goes for bit-banged serial as the PICAXE uses. I've had 115200 baud working completely reliably with a PICmicro and PC combination using internal oscillator, a 10K/22K interface, doing bit-banging.
There are forums where it has been suggested that using the 22K-style interface is unacceptable, and coupled with a micro with internal oscillator makes for a disaster waiting to happen. Some have suggested that bit-banged serial in such circumstances will only work reliably or at all for just a few percentage of chips from the factory. Under normal operating conditions I don't agree with that, and think that the evidence shows it is not so. Where a device has a wide tolerance on oscillator frequencies at manufacture there is more chance of a problem, but it has to be quite a way out from what it should be to interfere with serial operations.
The effect of oscillator accuracy is often frequently misundersttod, as Technical points out, and it took me a while to understand it. In the simplest of bit-banged receivers, the code waits for the start bit then delays to the middle of where the data bits would be and samples at those points. Only if the oscillator is running too fast that it reads bit 6 when it believes it is reading bit 7 or so slow that the start bit has arrived when bit 7 is being read will there begin to be a problem. This is where the frequently stated +/-6% tolerance to bit-banged serial baud rate error derives from. That error tolerance is applicable regardless of what baud rate is being used.
At very high baud rates, where bit times are just a few uS, there can be additional problems because sampling for the start bit can cause a few uS delay ( 'jitter' ), but this will have much less effect on lower baud rates.
I see the 10K/22K interface as a great boon for the PICAXE and most users, cheap and easy to use, but it's not compulsory. If people are uncomfortable with it, they can always use a proper MAX232-style solution instead.
I've been using PICAXE's for a long time now, and despite some problems, I've had very, very few and I believe most users would say the same. I don't want to give the impression that the PICAXE and/or the 10K/22K serial interface is fundamentally and implictly flawed, as I don't think it's correct to say that.
And I agree; many thanks for Technical's concern and swift response as always.
There are forums where it has been suggested that using the 22K-style interface is unacceptable, and coupled with a micro with internal oscillator makes for a disaster waiting to happen. Some have suggested that bit-banged serial in such circumstances will only work reliably or at all for just a few percentage of chips from the factory. Under normal operating conditions I don't agree with that, and think that the evidence shows it is not so. Where a device has a wide tolerance on oscillator frequencies at manufacture there is more chance of a problem, but it has to be quite a way out from what it should be to interfere with serial operations.
The effect of oscillator accuracy is often frequently misundersttod, as Technical points out, and it took me a while to understand it. In the simplest of bit-banged receivers, the code waits for the start bit then delays to the middle of where the data bits would be and samples at those points. Only if the oscillator is running too fast that it reads bit 6 when it believes it is reading bit 7 or so slow that the start bit has arrived when bit 7 is being read will there begin to be a problem. This is where the frequently stated +/-6% tolerance to bit-banged serial baud rate error derives from. That error tolerance is applicable regardless of what baud rate is being used.
At very high baud rates, where bit times are just a few uS, there can be additional problems because sampling for the start bit can cause a few uS delay ( 'jitter' ), but this will have much less effect on lower baud rates.
I see the 10K/22K interface as a great boon for the PICAXE and most users, cheap and easy to use, but it's not compulsory. If people are uncomfortable with it, they can always use a proper MAX232-style solution instead.
I've been using PICAXE's for a long time now, and despite some problems, I've had very, very few and I believe most users would say the same. I don't want to give the impression that the PICAXE and/or the 10K/22K serial interface is fundamentally and implictly flawed, as I don't think it's correct to say that.
And I agree; many thanks for Technical's concern and swift response as always.
Have now replaced the chip and the new one has downloaded perfectly.
That said i'm now off to the website to download the new patch.
Thanks so much to everyone that has helped me with my problem, and thankyou to Tech, for a prompt and informative responce and a fix for the editor so quickly.
Now to get the test program off the chip and get my full program running....
That said i'm now off to the website to download the new patch.
Thanks so much to everyone that has helped me with my problem, and thankyou to Tech, for a prompt and informative responce and a fix for the editor so quickly.
Now to get the test program off the chip and get my full program running....