Menu
▾
▴
Re: [Usbpicprog-technical] Programming the PIC16F88
|
From: Frans S. <fra...@gm...> - 2009-05-27 14:39:14
|
Hi Anton, I will try to put some things in a log file. The xml files are just "stolen" from Piklab, maybe there is some information on their website, but I think the information is pretty obvious if you open it with a text editor. BTW, I have never focused so much on blank check since it is not very essential for programming the device. there is also another way to do it, by reading some other registers from the PIC (verification words) but it is not working yet. I think verify is much more important to get right! Cheers, Frans ps. why don't you subscribe to the mailing lists (usb...@li...), that way other people can also read about your questions. I also cc'd this message to the mailing list... Anton Post wrote: > Hi Frans > > I just build and installed snapshot 668. The dialogue now stays up during > programming thanks (and because of that you can't click a second time on the > programming, so it doesn't crash). > > 09:52:25: Erasing before programming... > 09:52:25: Erase OK > 09:52:25: Programming the code area of the PIC... > 09:52:42: Write Code memory OK > 09:52:42: Programming the data area of the PIC... > 09:52:42: Write Data memory OK > 09:52:42: Programming configuration area of the PIC... > 09:52:43: Write Config memory OK > 09:52:43: Verifying all areas of the PIC... > 09:53:00: Verify code failed at 0x0. Read: 0xFF, Expected: 0x8A > 09:53:00: Operations completed with errors/warnings > > But really I am of course interested more in the actual programming side - can > we include some more logging or diagnostics so we can find out what is not > happening, or at what stage the wrong memory addresses (i.e. 0x2035) are being read? > > I just got: > 09:59:25: Checking if the device is blank... > 09:59:42: Blankcheck failed at 0x3C03. Read: 0xA5, Expected: 0xFF > 09:59:42: Device is not blank. > 09:59:42: All operations completed > > Is there documentation on the xml file format for the PIC definition? (Although > I cannot see anything with that memory address range...) > > Thanks, > Anton > > ------------------------ > > Hi Frans > > Thank you for that. How are things on the actual PIC programming side, though? > Is it possible to put some more diagnostic code in or give me a release that > writes critical steps to a log file, so I can help you localise why the code is > not writing down? > > Thanks, > Anton > > ----------------------------------------------------- > > Hi Anton, > > The bug with the window has been fixed in the svn repository. I will make a > snapshot soon. > > I am working hard to fix all the bugs (that's why I didn't release it yet, don't > expect a stable release yet from the snapshots). > > It's good to keep telling me if you experience any new problems with usbpicprog, > it only helps to improve the software! > > Regards, > > Frans > > Anton Post wrote: > >>> Hi Frans >>> >>> Thanks for all your help. I will try to clarify what happens for me: >>> >>> - I opened up usbpicprog >>> 11:12:42: Detected PIC model 16F88 with device ID 0x765 >>> 11:12:42: usbpicprog 552 Connected >>> >>> - I open the hex file >>> - I hit the "Program" button (in the preferences everything is selected - Erase, >>> program code, data and config, verify) >>> - The programming dialog comes up and straight away disappears. It doesn't seem >>> to just lose focus, because it's not behind the window or anywhere to be seen if >>> I minimise the other window or whatever. >>> - At this stage I usually just clicked it again, at which point the program >>> > crashes. > >>> - But what I did just now (after reading your email) is leave it for a couple of >>> minutes, and you are correct - a message comes up saying "All operations >>> > completed". > >>> 11:09:53: Erasing before programming... >>> 11:09:53: Erase OK >>> 11:09:53: Programming the code area of the PIC... >>> 11:10:10: Write Code memory OK >>> 11:10:10: Programming the data area of the PIC... >>> 11:10:10: Write Data memory OK >>> 11:10:10: Programming configuration area of the PIC... >>> 11:10:11: Write Config memory OK >>> 11:10:11: Verifying all areas of the PIC... >>> 11:10:28: Verify successful >>> 11:10:28: All operations completed >>> >>> The thing that I find strange about that bug is that if you don't have "Erase >>> before programming" selected, the dialog does not disappear, but it updates as >>> it goes through all the operations as expected. (Is it possible that the erase >>> code brings up another popup with the same ID/name, and then straight away >>> closes it in this situation?) >>> >>> The main difficulty overall for me, though, is that the PIC is not getting >>> written to properly - when I do a read, or a verify after programming I get all >>> the problems I mentioned in the last email (usually blank). It is my feeling >>> (it's been hard to know for sure) that the "reading" code somehow interacts with >>> the hex file that has just been written - the reason I say that is that usually >>> if I do a read straight after a write, it may come up with some (usually >>> corrupt) data. But if I re-start usbpicprog, and do a read, it always (?) comes >>> up blank. Strangely, if I re-start usbpicprog, and open the hex file, and then >>> do a read, it still comes up blank, so it must be something to do with writing >>> the code, perhaps a bug in the firmware even? >>> >>> In any case, the program is not running in the PIC (it is a tested program that >>> I trust) so I don't think it's all getting down. >>> >>> You ask about the blankcheck - the following is the output I get (sometimes a >>> little different, but 0x2008, 0x30 is common): >>> 11:22:34: Checking if the device is blank... >>> 11:22:51: Blankcheck failed at 0x2008. Read: 0x30, Expected: 0xFF >>> 11:22:51: Device is not blank. >>> 11:22:51: All operations completed >>> >>> I am not sure how to tell if that is during the code, config or data section, as >>> the dialog just says "Checking if device is blank". >>> >>> I mentioned it last time, but I repeat an odd finding - if I do an Erase on the >>> device, then the answer does come back blank: >>> 11:25:26: Checking if the device is blank... >>> 11:25:44: Device is blank >>> 11:25:44: All operations completed >>> >>> I hope these diagnostics are some help to you. >>> >>> Looking forward to a new version. ;-) >>> Thanks again, >>> Anton >>> >>> ---------------------------- >>> >>> Dear Anton, >>> >>> I thought I already replied to your questions before, but I must have >>> > forgotten it. > >>> The problems you are having are not at all related to your hardware, the problem >>> is that the current snapshot is not very stable... :( >>> I am putting much effort in locating the problem, but it is software and the >>> same behavior is true for most 16F devices. >>> >>> I will think about some firmware version checking. >>> >>> What you say about the complete program cycle (erase, write all, verify all), >>> might it be that it is working but that the progress dialog loses focus? >>> What if you wait for a while until it says "all operations completed" or >>> something similar? I think that might be the problem... >>> >>> About the blankcheck, that is also another bug... it just shouldn't read beyond >>> 0x2007. Could you tell me whether it occurs at checking the code or config >>> > memory? > >>> Regards, >>> >>> Frans >>> >>> Anton Post wrote: >>> >>> >>>>> Hi Frans >>>>> >>>>> Sorry to keep disturbing you, as I'm sure you're very busy. I was just >>>>> > wondering > >>>>> whether you'd had a chance to look at my query below? >>>>> >>>>> I really did spend a bit of time trying quite a lot of diagnostics, but >>>>> > was not > >>>>> able to localise the problem beyond that - however, if you have some time I'm >>>>> very keen on being able to progress further with my project. >>>>> >>>>> Thanks again, >>>>> Anton >>>>> >>>>> -------------------------------------------------- >>>>> >>>>> Hi Frans >>>>> >>>>> Thanks for the tip on using the snapshot copy of the firmware - I now have it >>>>> >>>>> >>> saying "usbpicprog 552 connected", which I believe is the latest (and 0.2.1 for >>> the software, although that may be generic (built today off 620 (I believe >>> different from the upp_wx version I had before)). Might I request as a >>> relatively simple future enhancement for the PC software to test the firmware >>> version for compatibility - I think it will save a bit of headache for the >>> > users. > >>> >>> >>>>> Running a complete program cycle (erase, write all, verify all) fails straight >>>>> >>>>> >>> away, and clicking it again crashed the program. (This is probably what you >>> mentioned before?) >>> >>> >>>>> However just doing a program (code+data+config) with no erase or verify seems >>>>> >>>>> >>> to work fine, i.e. the bar goes across for about 20 seconds. >>> >>> >>>>> Unfortunately then I get some odd behaviour: >>>>> Usually I restart usbpicprog before doing a read, and usually the program >>>>> >>>>> >>> appears to be blank. A blankcheck sometimes succeeds, sometimes fails: >>> >>> >>>>> 12:44:50: Checking if the device is blank... >>>>> 12:45:08: Blankcheck failed at 0x2008. Read: 0x30, Expected: 0xFF >>>>> 12:45:08: Device is not blank. >>>>> >>>>> or 13:05:36: Blankcheck failed at 0x2035. Read: 0x1C, Expected: 0xFF >>>>> or 13:06:55: Blankcheck failed at 0x21C7. Read: 0x00, Expected: 0xFF >>>>> >>>>> Note that even though those memory addresses seem to be invalid for a 16F84, a >>>>> >>>>> >>> blank check does succeed following an erase, so something gets changed then - >>> this seems to work reliably whether I restart the program in between or not: >>> >>> >>>>> 12:47:58: Checking if the device is blank... >>>>> 12:48:16: Device is blank >>>>> >>>>> Occasionally, (but usually/always?) when I haven't restarted usbpicprog, >>>>> >>>>> >>> values are read from the area that was programmed, but they are usually corrupt >>> (see examples below). The odd thing is that once I restart usbpicprog and do >>> another read, it tends to come up "blank", as described above. >>> >>> >>>>> As it is not very reliable is there something I should be checking on my >>>>> >>>>> >>> circuit? Should I be adding some capacitors somewhere? My programming cable is >>> perhaps 30cm long. I have visually inspected my circuit for shorts or bad >>> connections, and have done the same with the programmer. MCLR is 11.95v. As some >>> things work (for example autodetecting the PIC16F88) I assume that there can't >>> be too much wrong with the physical communications. >>> >>> >>>>> Desired program: >>>>> 000000: 8A 15 0A 16 00 2F 04 28 83 12 03 13 85 01 83 16 85 01 83 12 86 01 83 >>>>> >>>>> >>> 16 000018: 86 01 98 16 83 12 FF 30 85 00 86 00 A0 01 05 30 20 02 03 18 25 28 A1 >>> 01 000030: 21 0A 03 19 23 28 A2 01 22 0A 03 19 21 28 A2 0A 1C 28 A1 0A 18 28 A0 >>> 0A 000048: 13 28 85 01 86 01 A0 01 05 30 20 02 03 18 3A 28 A1 01 21 0A 03 19 38 >>> 28 000060: A2 01 22 0A 03 19 36 28 A2 0A 31 28 A1 0A 2D 28 A0 0A 28 28 4F 30 8A >>> 15 000078: F1 27 6B 30 F1 27 8A 11 0F 28 41 28 8A 15 00 27 8A 11 63 00 04 28 FF >>> 3F 000090: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F >>> > FF 3F > >>> >>> >>>>> Read back: >>>>> 000000: FF 3F FF 3F FF 3F 04 28 8A 15 0A 16 00 2F 83 16 83 12 03 13 85 01 83 >>>>> >>>>> >>> 16 000018: 85 01 83 12 86 01 FF 30 86 01 98 16 83 12 05 30 85 00 86 00 A0 01 A1 >>> 01 000030: 20 02 03 18 25 28 A2 01 21 0A 03 19 23 28 A2 0A 22 0A 03 19 21 28 A0 >>> 0A 000048: 1C 28 A1 0A 18 28 A0 01 13 28 85 01 86 01 3A 28 05 30 20 02 03 18 38 >>> 28 000060: A1 01 21 0A 03 19 36 28 A2 01 22 0A 03 19 2D 28 A2 0A 31 28 A1 0A 8A >>> 15 000078: A0 0A 28 28 4F 30 8A 11 F1 27 6B 30 F1 27 00 27 0F 28 41 28 8A 15 FF >>> 3F 000090: 8A 11 63 00 04 28 FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F >>> > FF 3F > >>> >>> >>>>> Another try: >>>>> 000000: 8C 1E 26 08 99 00 08 00 00 00 F7 2F 1A 08 08 00 00 00 00 00 00 00 00 >>>>> >>>>> >>> 00 000018: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF >>> 3F 000030: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F A1 01 20 02 03 18 25 >>> 28 000048: A2 01 21 0A 03 19 23 28 A2 0A 22 0A 03 19 21 28 A0 0A 1C 28 A1 0A 18 >>> 28 000060: A0 01 13 28 85 01 86 01 3A 28 05 30 20 02 03 18 38 28 A1 01 21 0A 03 >>> 19 000078: 36 28 A2 01 22 0A 03 19 2D 28 A2 0A 31 28 A1 0A 8A 15 A0 0A 28 28 4F >>> 30 000090: 8A 11 F1 27 6B 30 F1 27 00 27 0F 28 41 28 8A 15 FF 3F 8A 11 63 00 >>> > 04 28 > >>> >>> >>>>> Another try: >>>>> 000000: 88 14 02 00 00 00 00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00 00 >>>>> >>>>> >>> 00 000018: 86 01 98 16 83 12 FF 30 85 00 86 00 A0 01 05 30 20 02 03 18 25 28 A1 >>> 01 000030: 21 0A 03 19 23 28 A2 01 22 0A 03 19 21 28 A2 0A 00 00 20 02 00 08 20 >>> 08 000048: 02 00 01 00 02 01 20 00 00 00 20 02 03 18 20 28 A0 00 00 08 01 08 18 >>> 28 000060: A0 01 02 08 01 01 06 00 22 08 01 20 20 02 01 08 20 08 20 00 01 00 02 >>> 11 000078: 30 20 22 00 20 02 02 11 0D 28 00 08 00 00 00 02 8A 11 20 00 00 28 4F >>> 30 000090: 8A 11 F1 27 6B 30 F1 27 00 27 0F 28 41 28 8A 15 FF 3F 8A 11 63 00 >>> > 04 28 > >>> >>> >>>>> Occasionally read back correctly: >>>>> 000000: 8A 15 0A 16 00 2F 04 28 83 12 03 13 85 01 83 16 85 01 83 12 86 01 83 >>>>> >>>>> >>> 16 000018: 86 01 98 16 83 12 FF 30 85 00 86 00 A0 01 05 30 20 02 03 18 25 28 A1 >>> 01 000030: 21 0A 03 19 23 28 A2 01 22 0A 03 19 21 28 A2 0A 1C 28 A1 0A 18 28 A0 >>> 0A 000048: 13 28 85 01 86 01 A0 01 05 30 20 02 03 18 3A 28 A1 01 21 0A 03 19 38 >>> 28 000060: A2 01 22 0A 03 19 36 28 A2 0A 31 28 A1 0A 2D 28 A0 0A 28 28 4F 30 8A >>> 15 000078: F1 27 6B 30 F1 27 8A 11 0F 28 41 28 8A 15 00 27 8A 11 63 00 04 28 FF >>> 3F 000090: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F >>> > FF 3F > >>> >>> >>>>> One focus of all my diagnostics has been to try to figure out whether it's the >>>>> >>>>> >>> reading or the writing that is unreliable - I haven't been able to figure that >>> out, sorry. The other question I had (which is why I list three failed writes >>> above) is whether there's a pattern, i.e. the programming is too fast for the >>> flash to write completely - Looking bitwise at the above examples it does not >>> appear to me to be the case. And the fact that restarting usbpicprog almost >>> always changes the behaviour means I think that this is not where we should be >>> looking. >>> >>> >>>>> The main issue holding me up (apart from the unreliability) is that even when >>>>> >>>>> >>> the program does get down correctly, I have never seen the configuration take >>> hold - as I'm trying to run off an internal oscillator and it's set for an >>> external one, the PIC just sits there. >>> >>> >>>>> Thanks again, >>>>> Anton >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> >>>>> Dear Anton Post, >>>>> >>>>> Did you load the latest (snapshot) firmware in the usbpicprog programmer? >>>>> >>>>> >>> (Does it say usbpicprog 0.2.0 connected or does it tell you usbpicprog 6xx >>> connected?) >>> >>> >>>>> The stable (0.2.0) firmware does not yet support the 16F88 >>>>> The 0x200A readout should not occur though, I will check that one out! >>>>> >>>>> Cheers, >>>>> >>>>> Frans Schreuder >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > > > > |
