Repeat/End Repeat Bug

Anonymous
2013-12-16
2016-09-02
  • Anonymous - 2013-12-16

    Hi gang,

    I just noticed a bug in the REPEAT command with word sized numbers. For example...

    REPEAT 512
      stuff
    END REPEAT
    

    ...will repeat 768 times, not 512 times.

    Pretty clearly, the compiled outer loop counter is one unit too big.

    Thomas Henry

     
  • Anobium

    Anobium - 2013-12-17

    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 on
    
     
  • 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

     
  • Anobium

    Anobium - 2013-12-18

    I was thinking using a WORD variable in the REPEAT command may work around the problem.

    Its a bug anyway.

     
  • Scott Sutton

    Scott Sutton - 2016-09-02

    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
    • Anobium

      Anobium - 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?

       
  • Hugh Considine

    Hugh Considine - 2016-09-02

    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.

     
    • Anobium

      Anobium - 2016-09-02

      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.

       
  • Scott Sutton

    Scott Sutton - 2016-09-02

    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.

    I have zipped up the files on the attachment.

    Scott

     
    • Anobium

      Anobium - 2016-09-02

      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.

       
      • Anobium

        Anobium - 2016-09-02

        @Scott. This is caused by the MLCR line being set off.

        Use the following will resolve.

        #chip 16F88, 8
        #config MCLRE_ON
        #define LED PORTB.0
        dir LED out
        
         Repeat 1000
           Set led on
           Wait 5 ms
           Set LED off
           Wait 5 ms
         End Repeat
        

        If you power cycle the chip then program then the dead ones will recover.

         
  • Scott Sutton

    Scott Sutton - 2016-09-02

    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

     
  • Scott Sutton

    Scott Sutton - 2016-09-02

    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
    • Anobium

      Anobium - 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.

       
  • Scott Sutton

    Scott Sutton - 2016-09-02

    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

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks