Have a play with this code, does it fix the issue when you a word as the repeat variable. I am away from my bench, otherwise I would test.
#chip 16F88,4
dir portb.7 out
set portb.7 off
wait 1 s
dim ccount as word
dim repCount as word
repCount = 768
REPEAT repCount
ccount++
END REPEAT
set portb.7 on
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-12-17
Hello,
I'm not sure what you're getting at here, but it makes no difference if the 512 in my example is provided as a constant or as value contained within a variable. In either case, it's clear the compiled nested loops are incorrect. In particular, the outer loop is one unit too big., which causes the example I gave to execute 3X256=768 times, not the 2X256=512 specified in the source code.
Thomas Henry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like I have resurrected a very old thread....
When I use the repeat command in my code my chip (16F88) it can only be programmed one time. After that, the programmer no longer can connect to the chip for programming. I have killed 5 chips in a row. Its like it is dead after that point? I am using an melabs USB programmer. It works fine with all other code that I have tried so far with no issues. Is this a programmer issue or is there still an issue with the repeat command in GCB?
BTW, just tried the same code on an 18F452 and it works fine. I can program it over and over and it has no issues and executes fine?
Thanks,
Scott
Last edit: Scott Sutton 2016-09-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What version of the compiler? What version of the distribution are you using?
Are you using an 'out of the box' installation? Therefore, no mods to any .h files?
Are you using standard unmodified 16f88.dat file?
Have you tried other programmers? What version?
What is the code that is causing the issue? I have not seen this issue - so, we need the code if you think this is root cause.
What assembler are you using? or, are you assembling direct from Great Cow BASIC?
Are you changing the ASM between generation and programming?
When you say 'killed' does the mean the microcontroller is damaged beyond repair? Please clarify.
Please upload, source GCB, ASM and HEX - I can test with PK2 and a Serial Bootloader.
Lots of questions but not seen this before.
@All. Any one got a melavs USB programmmer? Same issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very odd, there shouldn't any commands that prevent programming. Especially not Repeat!
Does your code do anything with any programming related pins? For the 16F88, that would be PORTA.5 (MCLR), PORTB.6 (program clock) or PORTB.7 (program data)? I've had problems with the 12F675 when using programs that switch the programming clock or data lines on as soon as the chip is powered up, but a couple of clicks of the erase button and my PICkit 2 has had the chip responding again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with Hugh. There should not be any commands that prevent programming especially not repeat, but, if you answer questions above I am sure we can help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, Thanks for the replies....
Some of the questions may be over my head so my reply may not make sense.
What version of the compiler?
Just downloaded the latest version of GCB
What version of the distribution are you using?
?
Are you using an 'out of the box' installation?
Yes, no mods at all
Are you using standard unmodified 16f88.dat file?
Yes I assume, I have not altered anything
Have you tried other programmers? What version?
No
What is the code that is causing the issue?
#chip 16F88, 8
#define LED PORTB.0
dir LED out
Repeat 1000
Set led on
Wait 5 ms
Set LED off
Wait 5 ms
End Repeat
What assembler are you using? or, are you assembling direct from Great Cow BASIC?
I may not understand the work flow correctly but this is basically what I am doing. I am using the default IDE that came with GCB, SynWrite. From that software I generate a hex file that I then load into the melabs programmer version 4.51. I have updated the firmware on it. This is working for the most part. I have generated several successful test codes.....serial out to the PC, blinking LEDs, HPWM test verified with my scope, etc. But, when I got to the repeat command the issue happened. Again, the same code now ported to an 18F452 works perfectly and I can re-code the chip over and over again.
Are you changing the ASM between generation and programming?
no
When you say 'killed' does the mean the microcontroller is damaged beyond repair? Please clarify.
I simply can not connect to it anymore. The programmer says "The target device does not match the selected device". It will for the first time I load the code, but afterwards I can no longer program it.
OK. Great answers (I may come back to the missing ones later) and the code really helps.
If you load the hex, then apply power to the chip and try to program within the first 10 secs. Does this work? Try this - report back. You must power cycle the chip and program in less than 10 secs.
Why do I ask? Because the PK2 also fails if I do not power cycle the chip before program. I have to remove power - I do not know why yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had tried that before your post. I can get it to clear (erase) when I do that right after power up. If I then leave power on it and try to erase again OR program I get the "Device does not match...." error. If I power up and try to program it always says "Device does not match...."
So, to answer your question, the programmer will erase it after a power cycle (1 time) but not program it.
I am thinking that it is really not fully erasing it because if it was then it should be able to program it at least one time before going into the fault mode. I can get a new 16F88 out of the box and it will program it one time, after that its over with.
Thanks!
Scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MCLRE_ON and MCLRE_OFF toggles between operating as a port (defined in your code) or as the Master Clear Function. So, keeping it simple - one setting makes port support input/.output and the other setting enables the Master Clear Function.
Now you know this.. experiment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting note closing out this issue. Now that I know what I did wrong I went back to "repair" the chips that had become unresponsive. I discovered that I had to download the program within 1 second of power up or they would give me the device error, not 10 seconds. They have all become responsive again and program normally now without issue.
Thanks again for the help!
Scott Sutton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi gang,
I just noticed a bug in the REPEAT command with word sized numbers. For example...
...will repeat 768 times, not 512 times.
Pretty clearly, the compiled outer loop counter is one unit too big.
Thomas Henry
Agree a bug.
Have a play with this code, does it fix the issue when you a word as the repeat variable. I am away from my bench, otherwise I would test.
#chip 16F88,4 dir portb.7 out set portb.7 off wait 1 s dim ccount as word dim repCount as word repCount = 768 REPEAT repCount ccount++ END REPEAT set portb.7 onHello,
I'm not sure what you're getting at here, but it makes no difference if the 512 in my example is provided as a constant or as value contained within a variable. In either case, it's clear the compiled nested loops are incorrect. In particular, the outer loop is one unit too big., which causes the example I gave to execute 3X256=768 times, not the 2X256=512 specified in the source code.
Thomas Henry
I was thinking using a WORD variable in the REPEAT command may work around the problem.
Its a bug anyway.
Looks like I have resurrected a very old thread....
When I use the repeat command in my code my chip (16F88) it can only be programmed one time. After that, the programmer no longer can connect to the chip for programming. I have killed 5 chips in a row. Its like it is dead after that point? I am using an melabs USB programmer. It works fine with all other code that I have tried so far with no issues. Is this a programmer issue or is there still an issue with the repeat command in GCB?
BTW, just tried the same code on an 18F452 and it works fine. I can program it over and over and it has no issues and executes fine?
Thanks,
Scott
Last edit: Scott Sutton 2016-09-02
Not a good idea to re-open.
More information needed.
What version of the compiler? What version of the distribution are you using?
Are you using an 'out of the box' installation? Therefore, no mods to any .h files?
Are you using standard unmodified 16f88.dat file?
Have you tried other programmers? What version?
What is the code that is causing the issue? I have not seen this issue - so, we need the code if you think this is root cause.
What assembler are you using? or, are you assembling direct from Great Cow BASIC?
Are you changing the ASM between generation and programming?
When you say 'killed' does the mean the microcontroller is damaged beyond repair? Please clarify.
Please upload, source GCB, ASM and HEX - I can test with PK2 and a Serial Bootloader.
Lots of questions but not seen this before.
@All. Any one got a melavs USB programmmer? Same issue?
Very odd, there shouldn't any commands that prevent programming. Especially not Repeat!
Does your code do anything with any programming related pins? For the 16F88, that would be PORTA.5 (MCLR), PORTB.6 (program clock) or PORTB.7 (program data)? I've had problems with the 12F675 when using programs that switch the programming clock or data lines on as soon as the chip is powered up, but a couple of clicks of the erase button and my PICkit 2 has had the chip responding again.
I agree with Hugh. There should not be any commands that prevent programming especially not repeat, but, if you answer questions above I am sure we can help.
First, Thanks for the replies....
Some of the questions may be over my head so my reply may not make sense.
What version of the compiler?
Just downloaded the latest version of GCB
What version of the distribution are you using?
?
Are you using an 'out of the box' installation?
Yes, no mods at all
Are you using standard unmodified 16f88.dat file?
Yes I assume, I have not altered anything
Have you tried other programmers? What version?
No
What is the code that is causing the issue?
What assembler are you using? or, are you assembling direct from Great Cow BASIC?
I may not understand the work flow correctly but this is basically what I am doing. I am using the default IDE that came with GCB, SynWrite. From that software I generate a hex file that I then load into the melabs programmer version 4.51. I have updated the firmware on it. This is working for the most part. I have generated several successful test codes.....serial out to the PC, blinking LEDs, HPWM test verified with my scope, etc. But, when I got to the repeat command the issue happened. Again, the same code now ported to an 18F452 works perfectly and I can re-code the chip over and over again.
Are you changing the ASM between generation and programming?
no
When you say 'killed' does the mean the microcontroller is damaged beyond repair? Please clarify.
I simply can not connect to it anymore. The programmer says "The target device does not match the selected device". It will for the first time I load the code, but afterwards I can no longer program it.
I have zipped up the files on the attachment.
Scott
OK. Great answers (I may come back to the missing ones later) and the code really helps.
If you load the hex, then apply power to the chip and try to program within the first 10 secs. Does this work? Try this - report back. You must power cycle the chip and program in less than 10 secs.
Why do I ask? Because the PK2 also fails if I do not power cycle the chip before program. I have to remove power - I do not know why yet.
@Scott. This is caused by the MLCR line being set off.
Use the following will resolve.
If you power cycle the chip then program then the dead ones will recover.
I had tried that before your post. I can get it to clear (erase) when I do that right after power up. If I then leave power on it and try to erase again OR program I get the "Device does not match...." error. If I power up and try to program it always says "Device does not match...."
So, to answer your question, the programmer will erase it after a power cycle (1 time) but not program it.
I am thinking that it is really not fully erasing it because if it was then it should be able to program it at least one time before going into the fault mode. I can get a new 16F88 out of the box and it will program it one time, after that its over with.
Thanks!
Scott
OK,
Dead chips are back to life and can be programmed again. You were right, I must not have attempted to program right after power cycle only erase.
So, because I am a newbe please explain what I did wrong "MLCR line being set off", I do not understand?
Why does other codes work set up this way? Why did "repeat" invoke this issue?
Thank you for your help!! I am very excited to be able to use GCB and see what I can create with it.
Scott Sutton
Last edit: Scott Sutton 2016-09-02
Do you know... I knew you were going to ask that!
MCLRE_ON and MCLRE_OFF toggles between operating as a port (defined in your code) or as the Master Clear Function. So, keeping it simple - one setting makes port support input/.output and the other setting enables the Master Clear Function.
Now you know this.. experiment.
Interesting note closing out this issue. Now that I know what I did wrong I went back to "repair" the chips that had become unresponsive. I discovered that I had to download the program within 1 second of power up or they would give me the device error, not 10 seconds. They have all become responsive again and program normally now without issue.
Thanks again for the help!
Scott Sutton