Announcement

Collapse
No announcement yet.

[Solved] Dead U2 Programmer?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • [Solved] Dead U2 Programmer?

    Using PB3 and an old U2 programmer doing ICSP on a PIC18F 87K90 and I started seeing some very weird behavior. For example,

    Code:
    nOnes var byte
    nTens var byte
    
    nOnes = 3
    nTens = nOnes
    and nTens would always be zero. Doing this instead

    Code:
    nOnes var byte
    nTens var byte
    
    nOnes = 3
    nTens = 3
    would work.

    So I allowed MicroCode studio to update everything and went to the latest beta firmware for the U2. Now I can't get the U2 to program *anything*. Sometime it stops with "Erase failed", sometimes gives a configuration error, sometimes says it couldn't write to location 0000, and sometimes it acts normal but, although it does erase (or otherwise prevent code already on the chip from working) the PIC acts like a brick.

    To confirm I tried changing the USB cable, the USB port, the header cable, the PC, and tried programming an 18F452 directly in the ZIF socket. I'm pretty convinced it's a problem with the programmer. (Bootloading a program does work so that appears to eliminate any PB3/MPASM issues).

    So, thanks for following along this far. The questions:
    1) Could a bad programmer be responsible for code problem noted above?
    2) Any possibility it's a problem with the latest beta that I could maybe undo?
    3) Any possibility to diagnose/repair the U2 Programmer? I have a spare at home but I don't want to risk damaging that one too...

    Any advice is appreciated.

    Best Regards,
    Paul

  • #2
    1) Could a bad programmer be responsible for code problem noted above?

    Extremely unlikely.

    2) Any possibility it's a problem with the latest beta that I could maybe undo?

    Yes, there is a possibility. You can use the programmer's update function to revert back to an earlier version of firmware. The firmware files are found in the melabs Programmer install folder. (meupxx.hex)

    3) Any possibility to diagnose/repair the U2 Programmer? I have a spare at home but I don't want to risk damaging that one too...

    The programmer has proven to be very robust. It's unlikely that the hardware is damaged. If you have a programming adapter or another proven ICSP connection, you can test the programmer hardware.

    The programmer runs a self-test when powered. If there is a problem in the voltage generation, it will shut down and blink red immediately.

    Revert to older firmware first. It may reveal a clue.
    Charles Leo
    ME Labs, Inc.
    http://melabs.com

    Comment


    • #3
      Hello Charles,

      Thank you for your reply, and for taking the time to do so.

      I tried it again after reloading the most current firmware and I am able to program an 18F452 using the ZIF programming adapter. Also verified that ICSP does indeed work on an older project using an 18F66J50. Trying ICSP on my current board I get "Erase failed" or, if I uncheck "Erase before programming" I get "Code programming error at 0600".

      So it's not the programmer. Good for MELabs, bummer for me! The dang board has been working properly for weeks and I was just trying out some additional features before committing to the next prototype revision. I'll keep swapping out components for a bit and if it gets too frustrating I'll just order the next revision and start over again. I'll post later the end result just to bring full closure.

      Thank you again for your help; it was truly appreciated.

      Best Regards,
      Paul

      Comment


      • #4
        A week has gone by. I ordered, received, and populated a fresh round of prototypes, and I am still having two difficulties that I imagine are related. Not sure whether to start a new thread but for the moment I'll continue here.

        First is ICSP. I've attached a stripped down schematic of the ICSP circuit. The ┬ÁC programming pins are not used for anything other than programming. Starting with freshly compiled code that is different from what is already on the chip, the "Erase before programming" fails every time. If I tell it not to erase before programming, it returns with Code Verify errors. If I erase manually it replies that the Erase failed, but reading what's on the PIC shows all FFFF's. So it appears that it is erasing but not able to verify it as such. So, after manually erasing, I tell it to program (with Erase before programming unchecked) it goes through programming code, verifying code, other verifications that go by too quickly for me to see, then finally stalls with a "Configuration programming error at 0000." Reading the PIC shows that the configuration is not the same as what was in the original file.

        However, the code is on the chip and seems to run. Which brings me to the second problem that, again, I have no clue if it is related to the ICSP problem or not. The chip is being used to run a custom LCD (the reason for needing a PIC with so many pins and the LCD controller) and due to the setup of those registers it's still kind of long. Therefore a pbp file that demonstrates the problem is attached instead of posted in-line.

        Oh right, the actual problem... In short if I assign variables a specific value the LCD shows the numerals just fine. If I instead assign a value to a single variable and then assign the other variables to be equal to that first variable it fails--they retain their original values. The exact code is short enough to post here:

        Code:
            'This displays "4444" On the LCD.  No problem
            nOnes = 4
            nTens = 4
            nHundreds = 4
            nThousands = 4
            gosub Display_ones
            gosub Display_Tens
            gosub Display_hunds
            gosub Display_Thous
            pause 1000
        
            'This *SHOULD" displays "8888" on the LCD.
            'Instead it shows up as 4448...
            'The other variable's aren't taking the value from nOnes!
            nOnes = 8
            nTens = nOnes
            nHundreds = nOnes
            nThousands = nOnes
            gosub Display_ones
            gosub Display_Tens
            gosub Display_hunds
            gosub Display_Thous
            pause 1000
        So any help, comments, or insight would be really, really appreciated. I'm totally lost as to where to go from here.

        Best Regards,
        Paul
        Attached Files

        Comment


        • #5
          More Information

          Maybe posting on a Monday morning will have more response than on a Friday afternoon...8^)

          So, I was able to program the chip, a PIC18F87K90 btw, using a MikroElectronika "MikroProg" programmer and a kludged adapter. Not really an optimal solution; I like the U2 much better and would far prefer making that work. However it doesn't. I know the circuit is good, I know the program is good, I know the U2 works for everything else except the PIC I'm currently working with.

          The question: Has anyone ever successfully programmed an actual PIC18F87K90 chip or one from the same family (PIC18FxxK90)? Where do I go from here?

          Best Regards,
          Paul

          Comment


          • #6
            A few users have reported using the K90 family with PBP successfully. I believe the U2 Programmer was also being used, but I'm no longer certain of this.

            You will need the latest revision of PBP3 to correct some possible problems related to bank selection on the K90. I think this is limited to specific circumstances of the HPWM command, but it's easier to provide support if we know you have the latest. Download PBP 3.0.6 from:

            http://PBP3.com/download

            You might also try the latest beta software/firmware for the U2 Programmer:

            http://melabs.com/support/progsoft.htm

            Let us know if the software updates change any of your results. If not, we'll investigate further. You're describing two problems, so we may need to focus on one at a time.
            Charles Leo
            ME Labs, Inc.
            http://melabs.com

            Comment


            • #7
              I have tested the 18F87K90 with the current U2 programmer. No errors from my test.

              Is the device powered at 5V when you are programming?
              Charles Leo
              ME Labs, Inc.
              http://melabs.com

              Comment


              • #8
                Hello Charles,

                Thanks for your reply. We can eliminate the compiler issue since it does not exist when I use the non-U2 programmer; PBP3 is still used and it all works fine with the only change being the programmer.

                Upgraded to the latest PBP. Had some trouble with the MCSPX install as it said my license was already being used, so sticking with the previous install. (I'm just about moved to a new PC, MCSPX license says I can install on three computers?)

                U2 programmer is using latest beta, 4.50.

                Anyway, compiling through MCSPX and automatically programming with all the usual erase/program/verify settings (Options| Update Configuration from File, Erase Before Programming, and Verify After Programming checked; Options|More Options--Code, Data, and Configuration checked for all items). Result: message that Erase Failed.

                Trying a manual Erase gives the same message. Doing a manual Blank check gives the message "EEPROM Data not blank at 0000 = 0000."

                Unchecked Options|More Options|Erase|data and Options|More Options|Blank Check|Data, tried another erase. Result is "Erase Failed" message. Tried manual blank check, got message "Configuration not blank at 0000 = FFFF."

                Unchecked Options|More Options|Blank Check|Config, tried another erase. Result is "Erase Failed" message. Tried manual blank check, got message "This device is blank."

                Tried programming again, got message "Erase failed." Unchecked Options|Erase Before Programming and tried programming again. Saw the "Programming Code" window briefly (not much code at this point) then got the message "EEPROM Data Programming Error at 0000." BTW, I'm trying to put 14 bytes of data on while programming the chip. At this point the program appears to be running on the PIC.

                I looked at the Code, Data, and Config information from the compiled hex file and then downloaded and compared what came from the programmed PIC. Code was fine but the Config was not the same:
                0000- 0811 2409 8b01 0091 c0ff e0ff 40ff on the compiled hex file
                0000- df5d 277f 8b01 0091 c0ff e0ff 40ff from the "read" file.

                EEPROM was, of course, blank from the "read" file.

                So there's my results! I'm happy to run any other tests, checks, or whatever. I can share the entire schematic with MELabs directly but I am not allowed to post it on the 'net. I truly hate to imagine it but I think there might actually be a bug...

                Best Regards,
                Paul

                Comment


                • #9
                  Originally posted by Charles Leo View Post
                  Is the device powered at 5V when you are programming?
                  No, powered by 3.3V with the internal regulator disabled.

                  Best Regards,
                  Paul

                  Comment


                  • #10
                    The problem may be that the bulk-erase algorithm requires 5V on Vdd.

                    In the meProg software, set the low-voltage erase option (Options > More Options > Low Voltage Erase). This option uses a slower, row-erase algorithm.

                    You made a lot of changes to the advanced options. To set everything back, you can click Options > More Options > Set Options to Defaults. Keep in mind that this will uncheck the low-voltage option above.

                    You will be able to run on three computers. If there is a problem with MCSPX, we can get a bit of help from David at Mecanique.
                    Charles Leo
                    ME Labs, Inc.
                    http://melabs.com

                    Comment


                    • #11
                      Thanks for the information and I appreciate your hanging in with this. I tried what you suggested and got the same results. To try and put it into a brief statement I'd say it erases and programs the code just fine but not so much for the EEPROM or the Configuration bits.

                      The EEPROM I could live without if necessary but not being able to set the config bits hurts. In your successful test with this PIC were you running at 3.3V or 5V with the internal regulator enabled? I've only got one chip on the board that's can't take 5V. If you think it's worth a shot I could lift the Vdd pin of that chip, enable the on-board regulator, and jumper the 5V from the U2 programmer into the board's Vdd. (The whole thing draws <2mA in normal operation, watching it during programming it goes up to maybe 12 mA).

                      I'll deal with the MCSPX thing later...8^)

                      Best Regards,
                      Paul

                      Comment


                      • #12
                        My test was at 5V, but I tested both the bulk-erase and row-erase.

                        Please verify that your programmer firmware is version 5.9. (Program > Get Target Information)

                        In your circuit design, are all of the Vdd, Vss, AVdd, and AVss pins connected to power or ground?

                        Did you reset the options to defaults? When using the low-voltage erase, do you now see a slower progress bar for each memory area? It should be obvious that the erase algorithm has changed. If it acts exactly the same as before, check the setting again.

                        Changing the voltage would have value as a test, but I don't see it as a valid permanent solution. This should work at 3.3V.
                        Charles Leo
                        ME Labs, Inc.
                        http://melabs.com

                        Comment


                        • #13
                          Please verify that your programmer firmware is version 5.9. (Program > Get Target Information)
                          Box says:
                          melabs U2 Programmer
                          Firmware version is 5.9
                          Target Device ID is 5144.
                          Target device matches selected device.

                          In your circuit design, are all of the Vdd, Vss, AVdd, and AVss pins connected to power or ground?
                          Yes. All Vdd and AVdd connected to regulated 3.3V, all Vss and AVss connected to ground. Envreg to ground and VddCORE/VCAP to +3.3V (as specified for disabling the internal regulator) and a 10 uF cap.

                          Did you reset the options to defaults? When using the low-voltage erase, do you now see a slower progress bar for each memory area? It should be obvious that the erase algorithm has changed. If it acts exactly the same as before, check the setting again.
                          Oh yes, followed your directions exactly. It was indeed slower.

                          Changing the voltage would have value as a test, but I don't see it as a valid permanent solution. This should work at 3.3V.
                          I will try that in the morning and report the results. Won't be a huge ordeal.

                          Best Regards,
                          Paul

                          Comment


                          • #14
                            Info from 5V test

                            Good Morning Charles,

                            I ran the test as described (enabled the PIC's internal 3.3V regulator, lifted pins for any components that might be sensitive to 5V, and attached the U2's 5V to VDD). Set the U2 programmer to the default settings using the menu item, and told it to program. Everything programmed perfectly--code, data, config; the whole gestalt.

                            You said it would be of value to have this test; sure looks like an interesting result to me. You should also now have the ability to duplicate my results by dropping in a 3.3V regulator into your test rig. (When powering with 3.3V the PIC doesn't seem to really care whether the internal regulator is enabled--I can see no differences in performance or current draw). I know that I tell my customers that any problem I can duplicate, I can fix.

                            Best Regards,
                            Paul

                            Comment


                            • #15
                              I will arrange a test at 3.3V to see if I can repeat the result. You are correct; if I can repeat it, then we can fix it.

                              If you can, Paul, email your hex file with embedded configuration data to [email protected]. I'll proceed without it, but sometimes results can differ depending on configuration data.

                              I will post more information as it becomes available.
                              Charles Leo
                              ME Labs, Inc.
                              http://melabs.com

                              Comment

                              Working...
                              X