Pickit 2 with pk2cmd Can Only Program One Type of PIC
Tom Hunt
I've been using my Pickit 2 with pk2cmd for about a year with no problems. I recently purchased a new laptop on the death of my old one. The old laptop ran a 32 bit OS. The new one runs a 64 bit OS. I downloaded the pk2cmd source and compiled it successfully. At first, everything seemed fine. I tested it with a PIC 16F88. All commands worked fine. I tried to program other chips, 16F84A, 16F876A, and 18F2455. They *almost* never responded successfully. I was able to program the 18F2455 on two occasions. Even a simple: pk2cmd -ppic18f2455 -i could not identify the chip. The 16F88 never seems to have a problem. The only exception is that if I leave the programmer plugged in for any length of time, the next command after an idle period will fail to find the programmer. I hope that someone can point me in the right direction. Here is a summary of some of my notes/attempts:
Hardware:
Toshiba Qosmio X775
Intel Core i7 8GB Ram
USB: 3 USB 2.0 ports, 1 USB 3.0 port
lsusb:
Without PicKit2:
tom@asimo:~> lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Bus 001 Device 005: ID 058f:b003 Alcor Micro Corp.
Bus 002 Device 012: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
With PickKit2:
tom@asimo:~> lsusb
Bus 003 Device 002: ID 04d8:0033 Microchip Technology, Inc. PICkit2
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Bus 001 Device 005: ID 058f:b003 Alcor Micro Corp.
Bus 002 Device 012: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
So, the PicKit2 looks to be connected to Bus 3, which is an USB 2.0 hub
OS: OpenSuse Linux x86_64
Kernel:
tom@asimo:~> uname -r
3.1.9-1.4-desktop
Libraries:
libusb-0.1.so.4, libusb-0.1.so.4.4.4
libusb-1.0.so.0, libusb-1.0.so.0.0.0
libusb-1.0.so
libusb.so
libusbmuxd.so.1, libusbmuxd.so.1.0.7
udev rule: 51-pickit.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="0033", MODE="0666", OWNER="tom" GROUP="users"
PicKit2 information:
serial Number: BUR101232868
tom@asimo:~> pk2cmd -?V
Executable Version: 1.20.00
Device File Version: 1.62.09
OS Firmware Version: 2.32.00
Device File:
The one that came with the source for pk2cmd 1.20. I believe it is version 1.52.0.
I swapped in whatever device file I was using with my old laptop, and got the same results.
Regardless of whether the programming works or fails, I see the same message in dmesg and /var/log/messages:
eg.:
tom@asimo:~> pk2cmd -ppic18f2455 -i
Device ID = 0000
Revision = 0000
Device Name = <no device>
Operation Succeeded
dmesg:
[127855.705355] usb 3-1: New USB device found, idVendor=04d8, idProduct=0033
[127855.705367] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[127855.705376] usb 3-1: Product: PICkit 2 Microcontroller Programmer
[127855.705383] usb 3-1: Manufacturer: Microchip Technology Inc.
[127855.705390] usb 3-1: SerialNumber: Љ
[127855.718373] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[127855.721375] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[127863.617178] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[127863.620179] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[127863.657175] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[127863.690180] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[127863.723179] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[127880.730431] usb 3-1: USB disconnect, device number 3
[128409.495107] usb 3-1: new full speed USB device number 4 using xhci_hcd
[128409.515465] xhci_hcd 0000:06:00.0: WARN: Stalled endpoint
[128409.517425] xhci_hcd 0000:06:00.0: WARN: Stalled endpoint
[128409.519421] xhci_hcd 0000:06:00.0: WARN: Stalled endpoint
[128409.543470] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128409.555468] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128409.564469] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128409.567469] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128409.568502] usb 3-1: New USB device found, idVendor=04d8, idProduct=0033
[128409.568512] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[128409.568518] usb 3-1: Product: PICkit 2 Microcontroller Programmer
[128409.568523] usb 3-1: Manufacturer: Microchip Technology Inc.
[128409.568527] usb 3-1: SerialNumber: Љ
[128409.581466] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128409.584468] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128420.449197] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128420.452193] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128420.489196] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128420.522200] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128420.555198] xhci_hcd 0000:06:00.0: WARN: short transfer on control ep
[128441.318220] usb 3-1: USB disconnect, device number 4
Even though lsmod seemed to indicate I was on a USB 2.0 bus, dmesg is still showing the xhci_hcd messages. I tried modprobe -r xhci_hcd and verified that it was removed. I still see the same message and have the same problems.
I have tried downloading the firmware again to the PicKit2. It re-installed successfully, but I see no change in behavior.
I should note also that I installed MPLAB.X v1.10. The behavior is the same. I tried with MPLAB uninstalled and still no difference.
Let me know if there is any other pertinent information I can provide.
Thanks in advance,
Tom
Xiaofan Chen
> Hardware:
> Toshiba Qosmio X775
> Intel Core i7 8GB Ram
>
> USB: 3 USB 2.0 ports, 1 USB 3.0 port
>
I thought this mailing list is dead, seems not yet...
I think this might not be really a pk2cmd problem, it might well be
a Linux USB problem.
You might want to try to switch to a different port (e.g.: switch
port with your mouse) to see if that helps.
--
Xiaofan
Jeff Post
You might also try using the shortest USB cable you can find.
Jeff
Tom Hunt
died in my hour of need. :-}
I tried the programmer on the dual boot of Windows 7 on the same
laptop. It works fine. I think you are correct that this is a
problem with my compilation and/or the Linux USB libraries.
I was only able to get it to compile under 64 bit, using libusb-1.0-
devel and libusb-compat-devel ( Suse packages ). The compatibility
library included usb.h and libusb.so. My guess
is that the compatibility is less than perfect.
I tried various configurations/changes to the make file and the source
itself, but I couldn't quite get it to compile. I'm not a C++
developer, so it was a bit beyond my capabilities. Any
thoughts on where I should go from here? I really don't want to have
to boot in to Windows for embedded development.
Thanks!
Tom
Xiaofan Chen
> Thanks to you both for getting back to me. I was afraid the list had
> died in my hour of need. :-}
> I tried the programmer on the dual boot of Windows 7 on the same
> laptop. It works fine.
So the hardware is good.
> I think you are correct that this is a
> problem with my compilation and/or the Linux USB libraries.
No I am not saying that. Rather you can try to switch to
a different USB port and change to a shorter cable to
see if that helps first.
> I was only able to get it to compile under 64 bit, using libusb-1.0-
> devel and libusb-compat-devel ( Suse packages ). The compatibility
> library included usb.h and libusb.so. My guess
> is that the compatibility is less than perfect.
The compatibility layer should be good enough and it is
now shipped as standard for major distro except Debian/Ubuntu
where the legacy libusb-0.1 packages are still the default.
> I tried various configurations/changes to the make file and the source
> itself, but I couldn't quite get it to compile. I'm not a C++
> developer, so it was a bit beyond my capabilities. Any
> thoughts on where I should go from here? I really don't want to have
> to boot in to Windows for embedded development.
>
You need to install the development package of the
libusb-compat package to build from source. I am not
using Suse but the name should be "libusb-devel"
or similar.
https://build.opensuse.org/package/show?package=libusb-devel&project=hardware
--
Xiaofan
Tom Hunt
I have ( about half a meter ). I also saw a link that suggested
trying with a 100 ohm resistor and two 33pf caps on the data line.
Neither did much for me. I also tried all four USB ports with the
same result. Only once did I see the actual bus assignment change.
It seems to want to give me bus 3 all the time. This bus seems to be
associated with one of the USB 2.0 hubs, but I can't say that for
sure. I just know they are assigned the same bus...
I did install the libusb-devel package as well as the compatibility
package. Only when I had installed both was I able to compile
successfully.
I must admit, I'm a bit frustrated with this tonight. Please don't
take anything I write as frustration with anyone here. I appreciate
everyone taking the time to help out.
The laptop hardware seems Ok. The Pickit2 hardware and firmware work
fine under Windows for all my chips. The Pickit source code worked
under the same distro, same version for 32 bit. I have tried to
isolate any new features that may have crept in ( such as the
xhci_hcd ). I am left with the "black box" of the USB libraries or
something else in the disto that is interfering. Maybe I'm barking up
the wrong tree, but I can't see what I've missed.
Thanks again,
Tom
On Mar 23, 11:06 pm, Xiaofan Chen <xiaof...@gmail.com> wrote:
>
> --
> Xiaofan
Jeff Post
> Sorry for the confusion. I tried with the shortest type A to B cable
> I have ( about half a meter ). I also saw a link that suggested
> trying with a 100 ohm resistor and two 33pf caps on the data line.
> Neither did much for me. I also tried all four USB ports with the
> same result. Only once did I see the actual bus assignment change.
> It seems to want to give me bus 3 all the time. This bus seems to be
> associated with one of the USB 2.0 hubs, but I can't say that for
> sure. I just know they are assigned the same bus...
>
> I did install the libusb-devel package as well as the compatibility
> package. Only when I had installed both was I able to compile
> successfully.
>
> I must admit, I'm a bit frustrated with this tonight. Please don't
> take anything I write as frustration with anyone here. I appreciate
> everyone taking the time to help out.
>
> The laptop hardware seems Ok. The Pickit2 hardware and firmware work
> fine under Windows for all my chips. The Pickit source code worked
> under the same distro, same version for 32 bit. I have tried to
> isolate any new features that may have crept in ( such as the
> xhci_hcd ). I am left with the "black box" of the USB libraries or
> something else in the disto that is interfering. Maybe I'm barking up
> the wrong tree, but I can't see what I've missed.
>
> Thanks again,
> Tom
>
I don't think you've missed anything. While my crystal ball never did work,
I'm inclined to think it's a software problem, in particular something didn't
translate well going from 32 bit to 64 bit. Could be something as simple as
an alignment problem. Could be either in the pk2cmd code or the libusb code.
Has anyone else who might be listening tried pk2cmd on a 64 bit Linux system?
If so, how did it go?
Tom, I likely won't have time for the next few months to delve into the code,
so you might have to dual boot for a while. When I do find time, I trust
you'll be willing to be a guinea pig for testing?
Dan, if you're here, have you tested pk2cmd on 64 bit Linux systems?
Jeff
Xiaofan Chen
> I don't think you've missed anything. While my crystal ball never did work,
> I'm inclined to think it's a software problem, in particular something didn't
> translate well going from 32 bit to 64 bit. Could be something as simple as
> an alignment problem. Could be either in the pk2cmd code or the libusb code.
>
> Has anyone else who might be listening tried pk2cmd on a 64 bit Linux system?
> If so, how did it go?
Last time I tried it under 64bit Ubuntu Linux there is no issue to get
pk2cmd to work.
> Tom, I likely won't have time for the next few months to delve into the code,
> so you might have to dual boot for a while. When I do find time, I trust
> you'll be willing to be a guinea pig for testing?
>
> Dan, if you're here, have you tested pk2cmd on 64 bit Linux systems?
--
Xiaofan
Xiaofan Chen
> I should note also that I installed MPLAB.X v1.10. The behavior is the
> same. I tried with MPLAB uninstalled and still no difference.
>
For MPLAB X, you need to take note the version of Java.
On the other hand, I tend to think this is not a pk2cmd problem.
You can try this more-up-to-date pk2cmd version to see if
it helps anything or not.
http://www.microchip.com/forums/tm.aspx?m=540021
--
Xiaofan
Xiaofan Chen
> The laptop hardware seems Ok. The Pickit2 hardware and firmware work
> fine under Windows for all my chips. The Pickit source code worked
> under the same distro, same version for 32 bit. I have tried to
> isolate any new features that may have crept in ( such as the
> xhci_hcd ). I am left with the "black box" of the USB libraries or
> something else in the disto that is interfering. Maybe I'm barking up
> the wrong tree, but I can't see what I've missed.
The other option to debug whether this is related to OpenSuse
Linux x86_64 version you use, is to try a different Linux distro,
e.g. 32bit version of the same distro, Ubuntu 11.10 32bit and
64bit, you can use Live CD or Flash drive.
If none of the 64bit Linux OS works whereas the 32bit version
works, then the problem clearly point to pk2cmd.
If none of the 32bit and 64bit Linux works, then the problem
seems to be your machine.
If only the OpenSuse Linux x86_64 version you use does
not work, then it is the problem related to the particular
distro.
I know this may take some time though...
--
Xiaofan
Tom Hunt
I know for a fact that it works fairly well under OpenSuse 12.1 32
bit. That is what I used under my old laptop. It was a 64 bit core
duo, but I ran a 32 bit OS. Curiously, I had intermittent problems on
that system with the 16F88 but not the other chips. The answer in
this case was VPP. I used the -X switch to power VPP ahead of VDD and
it worked. Now I have the opposite situation where only the 16F88
will program reliably. I tried various "tricks" with the switches to
no avail. Strange. I have a live CD of the latest 64 bit Mint lying
around somewhere. I will try that as you suggest. If it is a distro
problem, I will try and figure out how to explain the issue to the
OpenSuse community.
Jeff,
When you get time to delve into this, I would be happy to be a
guinea pig. I tried to set the source code up in Eclipse's CDT, but I
am too much of a novice C programmer to know what I'm doing. I had
hoped to set it up for debugging. I like Eclipse's debugger for
Java. I may keep trying that route.
In parallel, I will try to compile and use the source from the link
you provided, Xiaofan.
I'll report back any successes or challenges.
Thanks again!
Tom
On Mar 24, 4:45 am, Xiaofan Chen <xiaof...@gmail.com> wrote:
Tom Hunt
I just downloaded and compiled the v1.21-RC1 from the link Xiaofan
provided. I get the same results with my 18F2455.
Xiaofan Chen
> Update:
> I just downloaded and compiled the v1.21-RC1 from the link Xiaofan
> provided. I get the same results with my 18F2455.
I just tried an OpenSuse 12.1 x86_64 installation (VirtualBox
VM under Mac Mini 2011 running OS X Lion) and it works
fine with the 1.21-RC1. I do not have the 18F2455 now so
I use the PIC18F2620 which should be similar in terms of
programming specification.
mcuee@linux-hbxz:~/Desktop/build/pk2cmd> lsb_release -a
LSB Version: n/a
Distributor ID: SUSE LINUX
Description: openSUSE 12.1 (x86_64)
Release: 12.1
Codename: Asparagus
mcuee@linux-hbxz:~/Desktop/build/pk2cmd> ./pk2cmd -PPIC18F2620 -GFtest.hex
Read successfully.
Operation Succeeded
mcuee@linux-hbxz:~/Desktop/build/pk2cmd> ./pk2cmd -PPIC18F2620 -Y -Ftest.hex
PICkit 2 Verify Report
25-3-2012, 9:35:26
Device Type: PIC18F2620
Verify Succeeded.
Operation Succeeded
--
Xiaofan
Jeff Post
> On Sat, Mar 24, 2012 at 11:54 PM, Tom Hunt <idon...@gmail.com> wrote:
> > Update:
> > I just downloaded and compiled the v1.21-RC1 from the link Xiaofan
> > provided. I get the same results with my 18F2455.
>
> I just tried an OpenSuse 12.1 x86_64 installation (VirtualBox
> VM under Mac Mini 2011 running OS X Lion) and it works
> fine with the 1.21-RC1.
>
OpenSuse, but emulating Suse on Mac hardware?
If so, that is not a valid test of the low-level hardware interface.
Jeff
Xiaofan Chen
> On Saturday 24 March 2012 18:43, Xiaofan Chen wrote:
>> On Sat, Mar 24, 2012 at 11:54 PM, Tom Hunt <idon...@gmail.com> wrote:
>> > Update:
>> > I just downloaded and compiled the v1.21-RC1 from the link Xiaofan
>> > provided. I get the same results with my 18F2455.
>>
>> I just tried an OpenSuse 12.1 x86_64 installation (VirtualBox
>> VM under Mac Mini 2011 running OS X Lion) and it works
>> fine with the 1.21-RC1.
>>
> Umm, have I understood correctly? You're not actually running 64 bit Intel
> OpenSuse, but emulating Suse on Mac hardware?
I am running 64bit Intel OpenSuse under a Virtual Machine. The Mac
Hardware is Mac Mini 2011 which runs on Intel Core i5. Therefore
the VM should also run on Intel Core i5. But I am not a VirtualBox
expert.
http://www.apple.com/macmini/specs.html
mcuee@linux-hbxz:~> cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz
stepping : 7
cpu MHz : 2309.714
cache size : 6144 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc up
rep_good nopl pni monitor ssse3 lahf_lm
bogomips : 4619.42
clflush size : 64
cache_alignment : 64
> If so, that is not a valid test of the low-level hardware interface.
>
That is right. It is not a valid test for the low-level hardware.
The test is to say that OpenSuse x64 and pk2cmd may
well be not the problem. But rather the low level hardware
interface is the problem.
The low level hardware interface problem can be:
1) PICkit 2 connection to the PIC chips
In the case of PIC18F2455, this tip might help.
http://www.microchip.com/forums/fb.ashx?m=335515
2) OpenSuse Linux kernel driver for the Host USB chipsets
of Tom's PC.
That is the one my test can not cover.
--
Xiaofan
Jeff Post
>
> > If so, that is not a valid test of the low-level hardware interface.
>
> That is right. It is not a valid test for the low-level hardware.
> The test is to say that OpenSuse x64 and pk2cmd may
> well be not the problem. But rather the low level hardware
> interface is the problem.
>
not the same thing.
When you call an os api that in effect says, here's a string of bytes to send
to device x on usb bus y, the VM is then out of the picture. There is no
guarantee that the kernel code on the Mac handles it the same way the kernel
code in Suse processes the data.
Having the same (or similar) cpu does tend to give one confidence that pk2cmd
is not the issue, however, I think the most important clue here is that it
works for Tom *on the exact same hardware* running Windows (or did I misread
something?). That's a clear indication that it's not a hardware problem per
se (caps, cable length, voltages, etc.)
Seems to me the most likely explanation is the libusb code, and if that's the
case there may be a way to work around the problem in the pk2cmd code. Too
little is known at this time, but that's the direction I'm leaning.
Jeff
Xiaofan Chen
> Seems to me the most likely explanation is the libusb code, and if that's the
> case there may be a way to work around the problem in the pk2cmd code. Too
> little is known at this time, but that's the direction I'm leaning.
>
libusb-compat and libusb-1.0 codes may indeed not that
stable since there are a lot of fix not integrated and 1.0.9
release takes forever to release under the leadership
of Peter Stuge. But I doubt they are the problems.
http://libusb.6.n5.nabble.com/libusb-1-0-9-release-td5581933.html
pk2cmd libusb codes may have some minor issues indeed.
#if HAVE_LIBUSB_INTERRUPT_MODE
// latest libusb: interrupt mode, works with all kernels
# define PICKIT_USB(direction) usb_interrupt_##direction
#else
// older libusb: bulk mode, will only work with older kernels
# define PICKIT_USB(direction) usb_bulk_##direction
#endif
The detection of HAVE_LIBUSB_INTERRUPT_MODE
may not be correct and it is not necessary for most
of the distro out there (unless the distro runs Linux 2.2.x).
So probably we can change the above just to one line.
define PICKIT_USB(direction) usb_interrupt_##direction
The other bug is mentioned here.
http://groups.google.com/group/pickit-devel/browse_thread/thread/de9693363e43c9a0
However, my thinking leans on issues with Tom's
particular PC and the particular kernel used.
--
Xiaofan
Tom Hunt
Optimus graphics set up ( Intel integrated with the Nvidia driver
hooked through the Intel to the display ). It wants a way to start
the CD with nomodeset, but I couldn't see a way to do it in time.
I'll try my Mint live CD today. I think that one lets you set boot
parameters. I had really wanted to try the Ubuntu CD since Xiaofan
confirmed that works with x86_64.
Just out of curiosity ( and to get a programmer working ), I dusted
off my old PicStart+. I had a copy of Jeff's picp 0.6.8 lying
around. It compiled under x86_64. I can program all my 16F chips
with it fine. As my laptop doesn't have a serial port, I used a basic
USB to Serial cable. The picdevrc file didn't have a definition for
the 18F2455. I tried to make one. It reads, blanks, and programs Ok
except for the configuration word. All the config bits look Ok except
the second word ( Config1H and Config1L ). So, the picp program works
with the serial library through USB. I don't know if this contributes
much to the investigation, but it was interesting. I also note that
the USB never lets go of the connection to the programmer ( as it does
with the Pickit2 ).
If anyone has a moment to tweak my 18F2455 definition for picp, that
would help keep me going. I tried to base it off of the 18F4550,
adjusting for the differences between the two. They are in the same
datasheet.
Here's what I used:
[18F2455]
0 ; config word: code protect mask bit
0 ; config word: watchdog mask bit
4 ; word alignment for writing to this device
300000 ; Configuration memory start address
200000 0 ; ID locations addr and size
f00000 ; Data eeprom address ( zero instead? )
0
0
0 0 0 0 0 0 0
PICSTART JUPIC OLIMEX
[18F2455:def]
30 00 ; size of program space
ff ff ; width of address word
ff ff ; width of data word
0f 0f ; width of ID
0f 0f ; ID mask
3f ff ; width of configuration word
27 ff ; configuration word mask
00 ff ; eeprom data width
00 ff ; eeprom data mask
00 00 ; calibration width
00 00 ; calibration mask
00 00
30 00
00 00
04
00 00
07
00 00
01 00
00 00
00 00
03
19
1e 0f
[18F2455:defx]
cf 3f 1f 3f
83 00 00 85
c0 0f e0 0f
40 0f 00 00
00 00 00 0f
00 00 cf 3f
1f 3f 87 00
00 e5 c0 0f
Thanks,
Tom
On Mar 25, 1:24 am, Xiaofan Chen <xiaof...@gmail.com> wrote:
> On Sun, Mar 25, 2012 at 11:52 AM, Jeff Post <j_p...@pacbell.net> wrote:
> > Seems to me the most likely explanation is the libusb code, and if that's the
> > case there may be a way to work around the problem in the pk2cmd code. Too
> > little is known at this time, but that's the direction I'm leaning.
>
> libusb-compat and libusb-1.0 codes may indeed not that
> stable since there are a lot of fix not integrated and 1.0.9
> release takes forever to release under the leadership
> pk2cmd libusb codes may have some minor issues indeed.
>
> #if HAVE_LIBUSB_INTERRUPT_MODE
> // latest libusb: interrupt mode, works with all kernels
> # define PICKIT_USB(direction) usb_interrupt_##direction
> #else
> // older libusb: bulk mode, will only work with older kernels
> # define PICKIT_USB(direction) usb_bulk_##direction
> #endif
>
> The detection of HAVE_LIBUSB_INTERRUPT_MODE
> may not be correct and it is not necessary for most
> of the distro out there (unless the distro runs Linux 2.2.x).
>
> So probably we can change the above just to one line.
> define PICKIT_USB(direction) usb_interrupt_##direction
>
Tom Hunt
nouveau.modeset=0 to get it to boot. I pulled in the 1.20 source
code, downloaded g++ and libusb-dev using apt-get. I compiled and
installed the software. I get the same issues. *However*, I noticed
that Ubuntu uses the older libusb-0.1 library and not libusb-1.0.
OpenSuse 12.1 has the libusb-1.0 installed by default. The only way
the package manager allows you to get the older library is via the
compatibility lib in OpenSuse.
Summary of OS operations on the exact same hardware with no
virtualization:
OpenSuse 12.1 x86_64 with libusb-1.0 and libus compat lib -
No chip but 16f88 works
Windows 7 Home Premium 64 bit -
All chips program successfully.
Ubuntu 11.10 64 bit Live CD with libusb-0.1 -
18F2455 fails to identify, read program space, erase, or program
16F88 - able to read and identify ( didn't try programming )
Looks like the same results as OpenSuse.
Results seem mixed. It looks like it may be a combination of the
program working with the Linux usb libraries on my hardware ( which
mixes usb 2 and 3 ).
I'll try the 1.21 pk2cmd version next on Ubuntu.
Tom
On Mar 25, 5:24 am, Xiaofan Chen <xiaof...@gmail.com> wrote:
> On Sun, Mar 25, 2012 at 11:52 AM, Jeff Post <j_p...@pacbell.net> wrote:
> > Seems to me the most likely explanation is the libusb code, and if that's the
> > case there may be a way to work around the problem in the pk2cmd code. Too
> > little is known at this time, but that's the direction I'm leaning.
>
> libusb-compat and libusb-1.0 codes may indeed not that
> stable since there are a lot of fix not integrated and 1.0.9
> release takes forever to release under the leadership
> pk2cmd libusb codes may have some minor issues indeed.
>
> #if HAVE_LIBUSB_INTERRUPT_MODE
> // latest libusb: interrupt mode, works with all kernels
> # define PICKIT_USB(direction) usb_interrupt_##direction
> #else
> // older libusb: bulk mode, will only work with older kernels
> # define PICKIT_USB(direction) usb_bulk_##direction
> #endif
>
> The detection of HAVE_LIBUSB_INTERRUPT_MODE
> may not be correct and it is not necessary for most
> of the distro out there (unless the distro runs Linux 2.2.x).
>
> So probably we can change the above just to one line.
> define PICKIT_USB(direction) usb_interrupt_##direction
>
Tom Hunt
Windows test. I don't have a compiler on it ( I don't really use
Windows for anything ). I pulled in the pk2cmd 1.62 version to test.
I'll have to go back and get a compiler and try the v1.20 code there.
Sorry for the confusion.
What compiler should I get ( MingW perhaps ) ?
> > Seems to me the most likely explanation is the libusb code, and if that's the
> > case there may be a way to work around the problem in the pk2cmd code. Too
> > little is known at this time, but that's the direction I'm leaning.
>
> libusb-compat and libusb-1.0 codes may indeed not that
> stable since there are a lot of fix not integrated and 1.0.9
> release takes forever to release under the leadership
> pk2cmd libusb codes may have some minor issues indeed.
>
> #if HAVE_LIBUSB_INTERRUPT_MODE
> // latest libusb: interrupt mode, works with all kernels
> # define PICKIT_USB(direction) usb_interrupt_##direction
> #else
> // older libusb: bulk mode, will only work with older kernels
> # define PICKIT_USB(direction) usb_bulk_##direction
> #endif
>
> The detection of HAVE_LIBUSB_INTERRUPT_MODE
> may not be correct and it is not necessary for most
> of the distro out there (unless the distro runs Linux 2.2.x).
>
> So probably we can change the above just to one line.
> define PICKIT_USB(direction) usb_interrupt_##direction
>
Tom Hunt
not working, 16F88 works.
I'm back in Windows 7. I'm downloading Cygwin with the MingW g++
compiler.
Tom
Tom Hunt
Windows executable. The 18F2455 still works fine with that, so
hardware with Windows usb drivers looks good with v1.20 command line.
Tom Hunt
now at least for code and config bits. I may have messed up the data
and ID portions though.
Tom
Xiaofan Chen
> Summary of OS operations on the exact same hardware with no
> virtualization:
>
> OpenSuse 12.1 x86_64 with libusb-1.0 and libus compat lib -
> No chip but 16f88 works
>
> Windows 7 Home Premium 64 bit -
> All chips program successfully.
>
> Ubuntu 11.10 64 bit Live CD with libusb-0.1 -
> 18F2455 fails to identify, read program space, erase, or program
> 16F88 - able to read and identify ( didn't try programming )
> Looks like the same results as OpenSuse.
If you can try the Ubuntu 11.10 32bit build to rule out
problems in pk2cmd with regard to 32bit/64bit.
> Results seem mixed. It looks like it may be a combination of the
> program working with the Linux usb libraries on my hardware ( which
> mixes usb 2 and 3 ).
If you want to pursue that route, you can try to ask in the linux-usb
mailing list. They are quite helpful. But they may ask you to try the
latest Linux kernel.
http://www.linux-usb.org/mailing.html
--
Xiaofan
Tom Hunt
32-bit live CD. The kernel is the same version as the x86_64 version
( 3.0.0.12-generic ). I used apt-get for g++ and libusb-dev ( 0.1
version ). All chips identify and read successfully every time.
I think the next test would be to compile for 32-bit on the 64-bit
system. I tried this, but was unable to get it to compile. If anyone
has any suggestions, I'd love to give it a try.
Thanks,
Tom
On Mar 25, 11:45 pm, Xiaofan Chen <xiaof...@gmail.com> wrote:
Jeff Post
> Excellent suggestion, Xiaofan! I am posting this from Ubuntu 11.10,
> 32-bit live CD. The kernel is the same version as the x86_64 version
> ( 3.0.0.12-generic ). I used apt-get for g++ and libusb-dev ( 0.1
> version ). All chips identify and read successfully every time.
>
> I think the next test would be to compile for 32-bit on the 64-bit
> system. I tried this, but was unable to get it to compile. If anyone
> has any suggestions, I'd love to give it a try.
>
compiler? That should give clues as to the cause of the problem.
Jeff
Tom Hunt
compiling pk2cmd for 32-bit on my 64 bit OpenSuse OS.
I added the -m32 switch to the OPTS definition in the Makefile.
The code compiled but failed to find the libusb. It saw my 64-bit
version of libusb-1.0 as incompatible.
I pulled in libusb-0.1.so.4.4.4 with zypper. It put it in the /lib
directory. I made a symbolic link to my /usr/lib directory:
ln -s /lib/libusb-0.1.so.4.4.4 libusb.so
The code linked successfully. I used make install. Voila! The 32-
bit version works for my 18F2455 and 16F88.
While this solves my immediate needs, it does leave the original
problem in place. I don't know if it's worth pursuing further. I
think time would be better spent developing software for the next
generation of programmers. I'll be happy to be a guinea pig for
those. I doubt you'd want my help developing it unless you want to do
it in Java! :-) (Java and USB? Eeeech! )
Thanks again to you both for all your help.
Tom
Xiaofan Chen
> Excellent suggestion, Xiaofan! I am posting this from Ubuntu 11.10,
> 32-bit live CD. The kernel is the same version as the x86_64 version
> ( 3.0.0.12-generic ). I used apt-get for g++ and libusb-dev ( 0.1
> version ). All chips identify and read successfully every time.
Great. So now at least you have a working setup now.
And since you mentioned that Ubuntu 11.10 64bit does not
work, that does potentially point the problem to pk2cmd.
--
Xiaofan
Xiaofan Chen
> Well, this has been quite an adventure. I went back and looked into
> compiling pk2cmd for 32-bit on my 64 bit OpenSuse OS.
>
> I added the -m32 switch to the OPTS definition in the Makefile.
> The code compiled but failed to find the libusb. It saw my 64-bit
> version of libusb-1.0 as incompatible.
Could you install libusb 32bit libraries as well using Zypper
or the GUI Add/Remove Software?
> I pulled in libusb-0.1.so.4.4.4 with zypper. It put it in the /lib
> directory. I made a symbolic link to my /usr/lib directory:
> ln -s /lib/libusb-0.1.so.4.4.4 libusb.so
>
> The code linked successfully. I used make install. Voila! The 32-
> bit version works for my 18F2455 and 16F88.
So again the 32bit version works. That again points some
potential problem with pk2cmd codes even though pk2cmd
seems to work for me under 64bit Linux OS but maybe
my tests did not trigger the problems like your tests.
> While this solves my immediate needs, it does leave the original
> problem in place. I don't know if it's worth pursuing further. I
> think time would be better spent developing software for the next
> generation of programmers. I'll be happy to be a guinea pig for
> those. I doubt you'd want my help developing it unless you want
> to do it in Java! :-) (Java and USB? Eeeech! )
>
> Thanks again to you both for all your help.
>
Thanks for your reports as well. Yes indeed the original
problem is still there why 64bit pk2cmd does not work
for you for some chips. Probably pk2cmd codes are the
problem here. If I happen to find something suspicions
(I am not a programmer myself but rather a hardware
designer engineer) I will inform the list.
--
Xiaofan
Xiaofan Chen
> So again the 32bit version works. That again points some
> potential problem with pk2cmd codes even though pk2cmd
> seems to work for me under 64bit Linux OS but maybe
> my tests did not trigger the problems like your tests.
>
>> While this solves my immediate needs, it does leave the original
>> problem in place. I don't know if it's worth pursuing further. I
>> think time would be better spent developing software for the next
>> generation of programmers. I'll be happy to be a guinea pig for
>> those. I doubt you'd want my help developing it unless you want
>> to do it in Java! :-) (Java and USB? Eeeech! )
>>
>> Thanks again to you both for all your help.
>>
>
> Thanks for your reports as well. Yes indeed the original
> problem is still there why 64bit pk2cmd does not work
> for you for some chips. Probably pk2cmd codes are the
> problem here. If I happen to find something suspicions
> (I am not a programmer myself but rather a hardware
> designer engineer) I will inform the list.
>
One easy thing to do is to enable usb debug by modifying
one line in pk2usb.h.
#define USB_DEBUG_FLAGS 0
Change 0 to 1 and you will have debug logs.
Compare the debug logs of the 32bit version of
pk2cmd and 64bit of pk2cmd to see where the
64bit pk2cmd fails on your system. Post the
details and maybe we can identify the problems.
--
Xiaofan
Jeff Post
>
> So again the 32bit version works. That again points some
> potential problem with pk2cmd codes even though pk2cmd
> seems to work for me under 64bit Linux OS but maybe
> my tests did not trigger the problems like your tests.
Which version of libusb are you using under 64 bit Linux? On my 32 bit Linux I
have libusb 0.1, not 1.0.
Jeff
Jeff Post
>
> One easy thing to do is to enable usb debug by modifying
> one line in pk2usb.h.
>
> #define USB_DEBUG_FLAGS 0
>
> Change 0 to 1 and you will have debug logs.
>
I'd really like to know what's going on here.
Jeff
Xiaofan Chen
libusb-0.1 and libusb-1.0 are different and you can have
both of them on either 32bit or 64bit Linux.
libusb-0.1 can be the legacy libusb-0.1 or the libusb-compat
compatibility layer on top of libusb-1.0, depending on the
distros.
More information about libusb.
http://www.libusb.org/ (the website can be dead from time to time)
--
Xiaofan
Tom Hunt
day or so. On 64-bit, I have both libusb-0.1 and libusb-1.0. The 0.1
is a compatibility layer ( from what the package manager tells me ).
I assume it wraps the old methods and redirects them through the 1.0
lib. I am pretty sure mine linked to the 1.0 version, but I'm not
entirely sure. I'll try and check.
I'll turn on the debug and try tonight. Where does the logging go
( stderr )? I'll send you the files when I have them, or is there a
way to post them here? I don't immediately see any controls...
Thanks,
Tom
Tom Hunt
debug flag set to 1. The 18f2455 was not getting recongnized. After
several tries of plugging and unplugging the USB cable, I got it to
read reliable. After that, I could plug and unplug it as many times
as I wanted, and it still worked. I compiled the 64 bit version for
debug. It read the chip, blank checked etc. with no problems. I
plugged and unplugged it several times with no problems.
After all that, I wonder if this is a hardware or cabling issue after
all. I have had no other issues with my USB ports with other
peripherals. The behavior seems pernicious. Once it fails to read
the 18f2455, it consistently fails. I can swap in the 16f88 at any
point while it is failing to read the 18f. It reads the 18f88
successfully. Once it reads the 18f2455, it seems to read it
successfully over and over.
I have the logs of successful reads with both the 32 bit and 64 bit
code. I don't think that really helps.
I'm not really sure where to go from here.
Tom