 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : 4.6b21 and b25 verify error
Page 1 of 2   |
|||||
| Author | Message | ||||
bigmik Guru  Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Hi All, I only just last night tried upgrading to Ver 4.6b25 for the uMite and I get a verify failed error when I do a physical VERIFY command.. (see attached) The program flash/burn itself passes (I thought this would have a verify as part of its function) and MMBasic appears to work OK. Grogster said he gets the same error but Geoff thinks that this might be a problem.. 
Can anyone else confirm or deny that this occurs.. As the error does not happen with earlier versions. Regards, Mick PS. I have IPE set for a PIC32MX170F256B and I am using a PicKit3 to flash the firmware. Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Hi Mick, I've used your configuration (IPE, 170F256B, PicKit3) a couple of times to flash b25 and it seems to be happy with it. Must say I've never actually hit the "Verify" button to explicitly check it, but just going through automatically finishes normally and the chips have worked fine so far. BTW I'm on an old XP system. Greg |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Hi Greg, Well that's the thing it is ONLY when I actually do a verify that I get this error, the burn phase itself ALWAYS succeeds. I am wondering if anyone else gets the same. I can accept that there is something wrong my end but earlier versions dont show this error.. I always do a verify and I admit up till now I have never had a verify failure. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
I will go public here, and say that I to have the exact same error, in exactly the same way as Mick, but not just with the latest Beta. I have had that happen semi-regularly with the PICkit3 and IPE when I click the verify button. It does not need to be the Micromite either, as I get this "Verify fail" error with the VT100 firmwares too, but I have just started to ignore these fails, or more to the point, just not bother to do a separate verify step. The initial programming is a program/verify anyway, by IPE's own admission, so.... As with the uM, the VT100 once programmed works flawlessly, but when I click the verify button it is 50/50 if it passes or fails. I am using Windows 8 x64 with auto-updates set to on, so this system should be as up to date as it can be in that respect. EDIT: Perhaps this is something specific to the PICkit3 - Dave(of EEVBlog fame) has some nice words to say about the PK3!!!  By all accounts, the PICkit2 was a far better product, but I don't THINK you can use the PK2 to program the newer PIC32 chips - not sure about that though.Smoke makes things work. When the smoke gets out, it stops! |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Are you on IPE V2.26 - it might be just that. I updated to V2.26 from V1.8 a couple of weeks ago and after going through the full shebang of the install and saying it was finished, it then came back and said there was some problem. I ignored that and just went ahead and used it and so far so good. |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Hi Greg, Good idea ... Mine is Ver 2.20 I will update after I come back from following the wife around the shopping centre. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
i believe that you can use the standard release of pic32prog to program the PIC32 chips using a pickit2. i have a pickit2 on its way, and will be able to verify this when it arrives. to date i have only tried a pickit3 with alternate firmware loaded. btw, the version of pic32prog that i posted a few days ago should work just fine with a pickit2. the alterations i made are confined to a specific block of code and only enabled when the "-d COMn" option is selected. in all other respects it behaves exactly like a normal release version and will automatically detect an attached pickit2. rob :-) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5913 |
IPE V2.20 on Win7 64 bit. Same verify fail error here. I had assumed that " Programming... Programming/Verify complete" Means that a verify was done automatically after programming but now I think that is not so. I have never had any chips fail to program and never bothered with "verify" on it's own. It reminds me of a friend who kept chooks. They were happy and healthy. He bought a book about keeping chooks and discovered all the problems the chooks had. He got rid of the books and the chooks were happy again. Jim VK7JH MMedit MMBasic Help |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Jim LOL How apt. Peter The only Konstant is Change |
||||
| micronut Newbie  Joined: 03/09/2014 Location: United StatesPosts: 37 |
I've loaded all the MK2 versions on the 170 using pic32prog with a Pickit2 and have had no verify problems. It does take a couple of minutes to load though. One nice thing about the Pickit2 is that it will power the chip while programming. |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Hi MicroNut I can power the MuP and MuP-Mini as I program with the PicKit3 as well (in advanced options) using MPLAB IPE @Jim Yes I expected that the Program/Verify meant just that.. Apparently NOT But I have always done a manual verify of every chip I burned for a customer.. It was only when I went to upgrade to b25 that the issue occurred, then I tried b21, which I got at the same time. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
It might be worthwhile asking on the Microchip forums - someone there might have more details on the issue - perhaps. Smoke makes things work. When the smoke gets out, it stops! |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Lads, I downloaded the v2.26 IPE and it is exactly the same. I will assume that as there are others with the same issue that it is not a `Mick has fat fingers' problem. I will leave this up to the `C' experts with this one.. Oh.. I just remembered I read in the `170 I burned and I meant to do a comparison with the `source.hex' Will do that now. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Hmmm, I just compared the two files and received MASSIVE amounts of discrepancies, then I checked the file sizes and the original one is 702k in size whereas the saved version is 746k in size.. Hmm, Out of my knowledge range.. Geoff, does MMBasic do a power-up checksum to check that it is good or similar? Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| aargee Senior Member  Joined: 21/08/2008 Location: AustraliaPosts: 255 |
Mick, I have the same problem, loads OK but if you do a standalone verify it fails. Using the Pickit 3, not sure which version of MPLab. I've been ignoring the verify fails and my chooks are healthy.  For crying out loud, all I wanted to do was flash this blasted LED. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
Same problem picKit3,IPE 2.26, W7-64bit. Never tried standalone verify before, never had a problem with the chip after programming. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3663 |
I don't have the mentioned firmware but I have had bogus Verify Errors from IPE. I found ignoring them worked best. Generally I don't use IPE (or MPLAB/etc) at all :) John |
||||
| jimbotron Regular Member  Joined: 27/11/2013 Location: AustraliaPosts: 46 |
I did a little mucking around and I think I know what the problem is. The Micromite is storing the BASIC program and various settings in flash, and the first time it starts up these settings change. You can prove it yourself. In IPE go into settings and click on "hold in reset". This will keep the reset pin low so that the Micromite can't start and alter the flash. Program the chip, then re-verify. It should work. Next go into settings and change to "Release from Reset". Do the verify again and it will fail because the Micromite has run. You can set "Hold in Reset" again and it will still fail. If you enter a short program, then read the chip back, you can see the program starting at the beginning of flash at address 1d000000. Interestingly the program appears to be stored in reverse. Try entering abcdefg as a program. You can easily spot the hex values decrementing. In some versions of Micromite, zeros appear to be written at the end of the program, in other versions it is not. It is these zeros that cause the first error. If you short the TX and RX pins to do a reset, it will get rid of the error at 1d000000 but you'll hit errors further into the flash space. Bottom line. IPE is working fine, and if you want to re-verify then turn on "Hold in Reset". Jimmy |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3663 |
They're not in reverse. Look up little endian (and big endian). I think you've found the IPE bug. That it allows a chip it's programming & verifying to run between the two is plain daft. No change of setting should be needed to stop such crazy behaviour! BTW, this doesn't explain ones I've seen that failed IPE verify as they don't change the flash. John |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Ah, yes. That explains it. When the Micromite MkII starts up the flash used to store the options is set to blank (all 0xff's) by the programmer, ie the erased state. The firmware checks for this and then sets the options (stored in flash) to the defaults. This takes half a second and if you watch you will notice that on the very first startup after programming the firmware, MMBasic will take about half a second longer to start up. If you do a verify after the firmware has done its initial startup you will find that the flash has changed (by the firmware itself). Geoff [edit] Camping in Cervantes in Western Australia (signal strength here is good). Geoff Graham - http://geoffg.net |
||||
| Page 1 of 2 |
|||||
 Print this page |
