Menu
▾
▴
usbpicprog-technical
|
From: Francesco M. <f18...@ya...> - 2008-10-27 16:37:46
|
Hi, I'm having troubles programming the PIC18F2550 with the bootloader: I've built (actually, on a breadboard) the JDM programmer as suggested in the website of UPP. However, using Piklab 0.15.3, when I try to clear the configuration bits of the PIC (after a warning saying me that the programmer does not support selective erasing and that all PIC memory will be cleared), piklab hangs forever. If instead I try to program the code memory it says: ------------- Programming device memory... protected: code=false data=false Writing memory: Code memory start before align: 0 start after align: 0 (align=16) end before align: 949 end after align: 959 (align=16) start=0x000000 nbWords=0x0003C0 total=0x004000 force=false varOffset=true varSize=true Verifying memory: Code memory start=0x000000 nbWords=0x004000 total=0x004000 force=true varOffset=true varSize=true Device memory does not match hex file (in Code memory at address 0x000000: reading 0xFFFF and expecting 0xEFA0). ------------- My setup is: - breadboard with JDM programmer connected to the serial port, to an external 12V stabilized power supply and to the P2 connector of my UPP - UPP connected to the JDM programmer and to the USB port of the PC (for power supply) If I sense (without running piklab or any other app using the serial port) with a voltage meter the base of the BC547 transistor on the JDM programmer (that is approximatively the voltage level on the pin 3 of the RS232) I read -10.8V. On the UPP's PIC I read 5.17V on Vdd (pin 20) and 11.8V on MCLR (pin 1); on PGD and PGC lines (pin 28 and 27) I read respectively -0.5V and -0.8V... I think all these readings are ok... I think however the programmer isn't working correctly because if I compile latest SVN version of UPP_WX and run it (as root) and then do 'Actions->Connect bootloader' I get: ------ USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it usb_set_debug: Setting debugging level to 2 (on) usb_os_init: Found USB VFS at /dev/bus/usb usb_os_find_busses: Found 005 usb_os_find_busses: Found 004 usb_os_find_busses: Found 003 usb_os_find_busses: Found 002 usb_os_find_busses: Found 001 usb_os_find_devices: Found 001 on 005 usb_os_find_devices: Found 001 on 004 usb_os_find_devices: Found 001 on 003 usb_os_find_devices: Found 001 on 002 usb_os_find_devices: Found 005 on 001 skipped 1 class/vendor specific interface descriptors usb_os_find_devices: Found 004 on 001 skipped 1 class/vendor specific interface descriptors skipped 1 class/vendor specific interface descriptors usb_os_find_devices: Found 001 on 001 error obtaining child information: Inappropriate ioctl for device error obtaining child information: Inappropriate ioctl for device USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it usb_set_debug: Setting debugging level to 2 (on) ------ I think this is normal because 'lsusb' says: ----- Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 005: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical Bus 001 Device 004: ID 046d:c309 Logitech, Inc. Internet Keyboard Bus 001 Device 001: ID 0000:0000 ----- that is, the PIC seems unprogrammed :/ thanks for any hints, Francesco -- |
|
From: Frans S. <fra...@gm...> - 2008-10-28 07:14:51
|
Well, I tried it with piklab 0.15.2 and 0.15.1 before, never with 0.15.3. Maybe you should try the older versions of piklab Have you mentioned that you have to invert the MCLR line? Have you measured the voltages on the PGD, PGC and MCLR with the PIC connected? it shoud be 0v/5v, 0v/5v and 0v/12v Did you connect a proper 12v power supply? If you still fail, I can send you a programmed PIC18F2550. Cheers, Frans > Hi, > I'm having troubles programming the PIC18F2550 with the bootloader: I've > built (actually, on a breadboard) the JDM programmer as suggested in the > website of UPP. > > However, using Piklab 0.15.3, when I try to clear the configuration bits of the > PIC (after a warning saying me that the programmer does not support selective > erasing and that all PIC memory will be cleared), piklab hangs forever. > > If instead I try to program the code memory it says: > > ------------- > Programming device memory... > protected: code=false data=false > Writing memory: Code memory > start before align: 0 > start after align: 0 (align=16) > end before align: 949 > end after align: 959 (align=16) > start=0x000000 nbWords=0x0003C0 total=0x004000 force=false varOffset=true > varSize=true > Verifying memory: Code memory > start=0x000000 nbWords=0x004000 total=0x004000 force=true varOffset=true > varSize=true > Device memory does not match hex file (in Code memory at address 0x000000: > reading 0xFFFF and expecting 0xEFA0). > ------------- > > My setup is: > - breadboard with JDM programmer connected to the serial port, to an external > 12V stabilized power supply and to the P2 connector of my UPP > - UPP connected to the JDM programmer and to the USB port of the PC (for power > supply) > > If I sense (without running piklab or any other app using the serial port) with > a voltage meter the base of the BC547 transistor on the JDM programmer (that is > approximatively the voltage level on the pin 3 of the RS232) I read -10.8V. > > On the UPP's PIC I read 5.17V on Vdd (pin 20) and 11.8V on MCLR (pin 1); on PGD > and PGC lines (pin 28 and 27) I read respectively -0.5V and -0.8V... I think all > these readings are ok... > > I think however the programmer isn't working correctly because if I compile > latest SVN version of UPP_WX and run it (as root) and then do 'Actions->Connect > bootloader' I get: > > ------ > USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it > usb_set_debug: Setting debugging level to 2 (on) > usb_os_init: Found USB VFS at /dev/bus/usb > usb_os_find_busses: Found 005 > usb_os_find_busses: Found 004 > usb_os_find_busses: Found 003 > usb_os_find_busses: Found 002 > usb_os_find_busses: Found 001 > usb_os_find_devices: Found 001 on 005 > usb_os_find_devices: Found 001 on 004 > usb_os_find_devices: Found 001 on 003 > usb_os_find_devices: Found 001 on 002 > usb_os_find_devices: Found 005 on 001 > skipped 1 class/vendor specific interface descriptors > usb_os_find_devices: Found 004 on 001 > skipped 1 class/vendor specific interface descriptors > skipped 1 class/vendor specific interface descriptors > usb_os_find_devices: Found 001 on 001 > error obtaining child information: Inappropriate ioctl for device > error obtaining child information: Inappropriate ioctl for device > USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it > usb_set_debug: Setting debugging level to 2 (on) > ------ > > I think this is normal because 'lsusb' says: > > ----- > Bus 005 Device 001: ID 0000:0000 > Bus 004 Device 001: ID 0000:0000 > Bus 003 Device 001: ID 0000:0000 > Bus 002 Device 001: ID 0000:0000 > Bus 001 Device 005: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical > Bus 001 Device 004: ID 046d:c309 Logitech, Inc. Internet Keyboard > Bus 001 Device 001: ID 0000:0000 > ----- > > that is, the PIC seems unprogrammed :/ > > > thanks for any hints, > Francesco > > |
|
From: Francesco M. <f18...@ya...> - 2008-10-29 17:34:45
|
Hi, Frans Schreuder ha scritto: > Well, I tried it with piklab 0.15.2 and 0.15.1 before, never with > 0.15.3. Maybe you should try the older versions of piklab I tried but the older versions do not work either :/ > Have you mentioned that you have to invert the MCLR line? I did it > Have you measured the voltages on the PGD, PGC and MCLR with the PIC > connected? it shoud be 0v/5v, 0v/5v and 0v/12v on MCLR the voltage is correctly 0/12; but on PGD and PGC lines the voltage levels are not exactly 0/5 but rather -0.6/5.5; I think this (or maybe one of the several other attempts I did :)) may have damaged the PIC I'm using... (abs max ratings say that voltages lower than -0.3V or higher than 5.3V on any pin except MCLR and few others may damage the PIC) :/ > Did you connect a proper 12v power supply? I did; in fact when MCLR is driven to 12V I read before the limiting resistor D6 exactly 12V (thanks to the zener); after the resistor about 11.65V... > > If you still fail, I can send you a programmed PIC18F2550. I'd appreciate this very much, if it's not a problem! I built the through-hole version so that if you have a DIP 18F2550 that would be perfect. I'll obviously pay (using paypal is ok?) for the PIC and shipping charge fees... If it's ok, I'll send you my mail address privately... Thanks, Francesco |
|
From: Francesco M. <f18...@ya...> - 2008-11-11 19:33:19
|
Hi Frans,
today I've received your pre-programmed PIC; thanks indeed!
One question: if I type in linux 'lsusb' with the UPP attached (with the PIC
with only the bootloader flashed), should I see a line indicating the UPP?
Or I need to flash the microcontroller code on the PIC to see something listed?
Thanks,
Francesco
|
|
From: Frans S. <fra...@gm...> - 2008-11-12 07:23:38
|
Hi Francesco, On the firmware page: http://usbpicprog.org/?page_id=6 you can see that you have to attach jumpers on the programming header. One jumper is on the MCLR pin of the 18F2550. If you attach only this one, you will see the bootloader in lsusb (it's called Microchip Picdem something) When you attach the other jumper after programming the usbpicprog firmware, you will see usbpicprog in lsusb. Cheers, Frans Francesco Montorsi wrote: > Hi Frans, > today I've received your pre-programmed PIC; thanks indeed! > > One question: if I type in linux 'lsusb' with the UPP attached (with the PIC > with only the bootloader flashed), should I see a line indicating the UPP? > Or I need to flash the microcontroller code on the PIC to see something listed? > > Thanks, > Francesco > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
|
From: Francesco M. <f18...@ya...> - 2008-11-12 22:57:55
|
Hi, Frans Schreuder ha scritto: > On the firmware page: http://usbpicprog.org/?page_id=6 you can see that > you have to attach jumpers on the programming header. > One jumper is on the MCLR pin of the 18F2550. If you attach only this > one, you will see the bootloader in lsusb (it's called Microchip Picdem > something) To me it showed up as: "ID 04d8:000e Microchip Technology, Inc." > When you attach the other jumper after programming the usbpicprog > firmware, you will see usbpicprog in lsusb. After flashing (successfully ;)) the uc_code-1.1 (and installing the second jumper) I still see the UPP listed as "ID 04d8:000e Microchip Technology, Inc."... but usbpicprog recognizes it (says "usbpicprog 0.1.1 connected") so it looks like everything works ;) As soon as I can I'll post the results about how my UPP through-hole works ;) Thanks, Francesco -- |
|
From: Frans S. <fra...@gm...> - 2008-11-13 07:30:09
|
Hi, >> On the firmware page: http://usbpicprog.org/?page_id=6 you can see >> that you have to attach jumpers on the programming header. >> One jumper is on the MCLR pin of the 18F2550. If you attach only this >> one, you will see the bootloader in lsusb (it's called Microchip >> Picdem something) > To me it showed up as: > "ID 04d8:000e Microchip Technology, Inc." The bootloader should have said: "ID 04d8:000b Microchip Technology, Inc." and it probably did, or else you couldn't have flashed the firmware successfully! The "Microchip Technology, Inc." string is just related to the 04d8, it has nothing to do with any string in the firmware but generated by the operating system. > >> When you attach the other jumper after programming the usbpicprog >> firmware, you will see usbpicprog in lsusb. > After flashing (successfully ;)) the uc_code-1.1 (and installing the > second jumper) I still see the UPP listed as "ID 04d8:000e Microchip > Technology, Inc."... but usbpicprog recognizes it (says "usbpicprog > 0.1.1 connected") so it looks like everything works ;) > > As soon as I can I'll post the results about how my UPP through-hole > works ;) Great! Don't forget to tell me which devices you have programmed successfully! cheers, Frans |
|
From: Frans S. <fra...@gm...> - 2008-11-13 08:48:28
|
Hi, > After flashing (successfully ;)) the uc_code-1.1 (and installing the > second jumper) I still see the UPP listed as "ID 04d8:000e Microchip > Technology, Inc."... but usbpicprog recognizes it (says "usbpicprog > 0.1.1 connected") so it looks like everything works ;) > > As soon as I can I'll post the results about how my UPP through-hole > works ;) There's also something else you can check before actually trying to program a pic: first measure the voltage on the last of the diodes. There should be something like 12 or 13 volts on it when both of the jumpers are attached. Cheers, Frans |
|
From: Frans S. <fra...@gm...> - 2008-11-15 16:10:07
|
Hi, > > I have programmed my other two PIC18F2550 with the UPP bootloader. UPP > (v.1.1) autodetected them correctly and when I clicked > Actions->Program the programming seems successful. > However if I click Actions->Verify for both those PICs I get "Verify > config failed at 0x300004. Read 0x00. Expected 0xFF". > If I understand it correctly, the bits are relative to the watchdog > timer (WDTPS2-WDTPS0 e WDTEN). > There's nothing wrong with your usbpicprog, it's just normal that it can't verify this locations since it is not implemented in the pic and always reads as 0x00. I should still add some kind of mask in the software for which configuration bits to verify and which not. But since it differs for every PIC it is a lot of work to do that, so it will probably take a while. You can disable the verify function for config memory in the preferences panel! > I wonder if this is because the PICs were damaged by my previous > experiments :) or rather because of something related to > code-protection flags... Nothing is broken really! > Thanks!! > Francesco > > Thank you for reporting! Frans |
|
From: Frans S. <fra...@gm...> - 2008-11-15 16:16:11
|
Hi Francesco, Could you also take some pictures of your through hole version of usbpicprog? (maybe in action programming something) It would be nice to put it on the site! Cheers, Frans |
|
From: Francesco M. <f18...@ya...> - 2008-11-17 13:08:51
|
Hi, Frans Schreuder ha scritto: > Could you also take some pictures of your through hole version of usbpicprog? > (maybe in action programming something) > It would be nice to put it on the site! sure! I've made some shots of my circuit and tarred them at: http://frm.users.sourceforge.net/upp_th_photos.tar.bz2 Disclaimer: - the PCB is not professional, no silk, etc - unfortunately I couldn't manage to make some of the close-up photos sharp... my digital camera seems unable to focus near objects :/ - the only PMOS I could find was SMD so that I soldered it with the help of small wire on the top side :/ I hope there is at least an usable photo... Bye, Francesco PS: I suggest setting the default "reply-to" of this mailing list to the mailing list itself, instead of the sender -- -- |
|
From: Francesco M. <f18...@ya...> - 2008-11-17 13:11:32
|
Hi, Frans Schreuder ha scritto: > Hi, >> I have programmed my other two PIC18F2550 with the UPP bootloader. UPP (v.1.1) autodetected them correctly and when I clicked Actions->Program the programming seems successful. >> However if I click Actions->Verify for both those PICs I get "Verify config failed at 0x300004. Read 0x00. Expected 0xFF". >> If I understand it correctly, the bits are relative to the watchdog timer (WDTPS2-WDTPS0 e WDTEN). >> > There's nothing wrong with your usbpicprog, it's just normal that it can't verify this locations since it is not implemented in the pic and always reads as 0x00. ah, good! > I should still add some kind of mask in the software for which configuration bits to verify and which not. But since it differs for every PIC it is a lot of work to do that, so it will probably take a while. I've seen that Piklab has in "piklab/src/devices/pic/xml_data" all datas available for lots of PICs; the XML files there should contain all required info for implementing those masks... since they release Piklab under GPL I think it would be ok to reuse those files. Btw, I read on the website about the old piklab plugin; is the new one being developed? I'm ready to give an hand with patches/implementation work :) > You can disable the verify function for config memory in the preferences panel! I'll do so in the meanwhile, then. Bye, Francesco -- |
|
From: Frans S. <fra...@gm...> - 2008-11-17 15:27:51
|
Hi, > > > I've made some shots of my circuit and tarred them at: > http://frm.users.sourceforge.net/upp_th_photos.tar.bz2 I've put it on the site under hardware! Thanks > > Disclaimer: > - the PCB is not professional, no silk, etc > - unfortunately I couldn't manage to make some of the close-up photos > sharp... my digital camera seems unable to focus near objects :/ > - the only PMOS I could find was SMD so that I soldered it with the > help of small wire on the top side :/ > > I hope there is at least an usable photo... > > Bye, > Francesco > > > PS: I suggest setting the default "reply-to" of this mailing list to > the mailing list itself, instead of the sender > So I did... |
|
From: Frans S. <fra...@gm...> - 2008-11-18 08:52:29
|
Hi
> I've seen that Piklab has in "piklab/src/devices/pic/xml_data" all
> datas available for lots of PICs; the XML files there should contain
> all required info for implementing those masks... since they release
> Piklab under GPL I think it would be ok to reuse those files.
I have looked at these files before, but I think it's more work to
actually make the scripts and everything to convert them to usbpicprog
source than to do it myself.
I have already implemented the masks in the latest SVN revision now!
>
> Btw, I read on the website about the old piklab plugin; is the new one
> being developed?
The old plugin was the first attempt for usbpicprog, but I moved to a
stand alone program for some reasons:
* it's cross platform
* the plugin was too slow (it was some kind of bitbanging algorithm
on the PC side)
* I was unable to track the fast changes of piklab in order to stay
compatible with the latest version
the usbpicprog software does now also have a command line interface
which makes it possible to use it from within any IDE.
I think it would be a good idea (and the easiest) to write a general
piklab plugin that can run a command line programmer, maybe with default
options for usbpicprog.
>
> I'm ready to give an hand with patches/implementation work :)
>
Thanks! maybe you can can give a hand with the piklab command-line plugin?
>> You can disable the verify function for config memory in the
>> preferences panel!
> I'll do so in the meanwhile, then.
If you checkout the latest SVN revision, you can enable it again :P
Cheers,
Frans
|
|
From: Francesco M. <f18...@ya...> - 2008-11-20 17:35:54
|
Hi, Frans Schreuder ha scritto: > Hi >> I've seen that Piklab has in "piklab/src/devices/pic/xml_data" all >> datas available for lots of PICs; the XML files there should contain >> all required info for implementing those masks... since they release >> Piklab under GPL I think it would be ok to reuse those files. > I have looked at these files before, but I think it's more work to > actually make the scripts and everything to convert them to usbpicprog > source than to do it myself. > I have already implemented the masks in the latest SVN revision now! Great! However the Piklab .xml files contains lot of useful informations and setting up routines which read those .xml files is a matter of few minutes using the built-in wxWidgets XML classes (which by chance were partly written by me :))... Also, I like more the Piklab approach because separing data from sources allows you to quickly add new devices info. Possibly a database could have been an even better choice, but XML is good, too. Re-using Piklab XML would allow UPP to display lots of more info about the selected devices and give readable names for e.g. config registers, etc, so I think it would be a Good Thing to reuse them. >> Btw, I read on the website about the old piklab plugin; is the new one >> being developed? > The old plugin was the first attempt for usbpicprog, but I moved to a > stand alone program for some reasons: > > * it's cross platform > * the plugin was too slow (it was some kind of bitbanging algorithm > on the PC side) > * I was unable to track the fast changes of piklab in order to stay > compatible with the latest version > > the usbpicprog software does now also have a command line interface > which makes it possible to use it from within any IDE. > I think it would be a good idea (and the easiest) to write a general > piklab plugin that can run a command line programmer, maybe with default > options for usbpicprog. that's probably the best thing, sure. >> I'm ready to give an hand with patches/implementation work :) >> > Thanks! maybe you can can give a hand with the piklab command-line plugin? Sure; however before working on such plugin I'd prefer to give some help with the main app (see my other mail). >>> You can disable the verify function for config memory in the >>> preferences panel! >> I'll do so in the meanwhile, then. > If you checkout the latest SVN revision, you can enable it again :P I've tested the new version and indeed it says "verify successful"! Thanks. Bye, Francesco -- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X