The cable between the ICD2 and the PIC was having the problem.
As you say, it should be handled by the PIC, true. Technically, it
should not affect.
Yes. But this was an observation at my end. Well, I have no true
explanation there.
Might need to look deeper into the firmware running on the PIC (ICD2) to get an
understanding of what's happening, when there is a change in the USB comms.
On the crosstalk, I had used 39pF ceramic discs.
This is Olin's explanation from his website on the cable crosstalk.
http://www.embedinc.com/picprg/icsp.htm
PGD to PGC Crosstalk
While this is really another circuit constraint, this issue is so
unintuitive, little known, poorly documented, but serious that it
deserves its own section.
The standard Microchip cable unfortunately puts PGD and PGC on
adjacent lines. Since this is a flat cable, this can and does lead to
crosstalk between the two in some cases. For writing to the target,
the programmer drives both lines. In that case a little low pass
filtering can be applied by the programmer to soften the edges and
reduce the coupled amplitude on one line from an edge on the other.
However, there is a case that must be addressed by the target circuit.
The PGD line is bidirectional, meaning it is sometimes driven by the
target PIC. In that case PGD is just a normal digital output on the
PIC. These are designed to drive from one state to the other as
quickly as possible. Such an edge produced on PGD by the target PIC
can couple onto the PGC line when using the standard cable supplied
with an ICD2, or any other cable where PGC and PGD are adjacent. The
target PIC then sees a PGC (clock) pulse that the programmer didn't
produce and the serial communication gets out of sync. The net result
is that programming appears to be flaky or not work at all.
This entire effect can happen within the time for the PGD edge to
propagate from the target PIC, thru the cable to the programmer, and
back thru the cable to the target circuit. This means that this
problem can not be solved at the programmer end of the cable. No
amount of clever circuitry at the programmer can make this issue go
away. It must be dealt with at the target circuit.
This issue is particularly important for dsPICs since they are faster
and therefore have stronger digital output drivers and faster edges
that couple better between signals. Although somewhat less severe, we
have observed this issue on programming 18F PICs. We don't recommend
assuming this won't happen on 16F or other PICs. We're not sure that
it doesn't, and ignoring it would essentially be relying on a maximum
digital output edge slope. This could easily change between
production lots, over temperature, or as new fab processes are brought
on line.
We recommend filtering the PGD output from the target PIC by adding
100 Ω in series followed by 47-100pF to ground. This limits the slope
of edges and attenuates the high frequecy components that can couple
from PGD to PGC. We also recommend adding the same capacitance to
ground to the PGC line close to where it enters the target board by
the programming connector. This reduces the impedence of the PGC line
at high frequencies, which reduces its susceptibility to crosstalk.
We had previously recommended 22pF for both capacitors instead of
47-100pF, but have meanwhile found cases where even 22pF was
insufficient. We feel that 47-100pF provides sufficient margin but is
still below the level where it could interfere with the normal
operation of the lines.
For example, the USBProg has 150 Ω output impedence on both lines.
150 Ω times 100pF is a time constant of 15nS, making the 90% settling
time about 45nS. This is small compared to the minimum 500nS time
from data to clock edges used by that programmer. Other Embed Inc
programmers have higher impedences and therefore longer time
constants, but also longer data setup times to compensate. All the
Embed Inc programmers will work with a additional 100pF load on the
PGC and PGD lines.
Cheers,
Manu
Post by Sean BrehenyThanks for the reply, Manu. The thing I don't understand about your
explanation, though, is which cable are you saying has the crosstalk
issues? The USB cable or the cable between the ICD2 and the PIC? I would
have thought that all the timing in the ICD2<->PIC cable would be handled
by the ICD2, not the PC, so I don't understand why changing software on the
PC would affect it. If the issue were with the USB cable, then adding RC
filters to the ICS2<->PIC connection should have nothing to do with it.
Sean
Post by Manu AbrahamHi Sean,
Two statements made me feel it's the timing. With the 3rd it was even
more evident.
"Apart from the usual idiosyncrasies
associated with Microchip products it serves me well even if it is a bit
slow compiling."
"Earlier this year I bought a used Thinkpad laptop running Windows 8 (32
bit) and decided to use that as my lab machine since it was newer and
faster and took up less desk space. So I installed MPl8.92, shifted the
ICD2 and set about programming. Unfortunately programming under the
debugger fails with the ICD0083 message."
"But today my son, visiting for Christmas, installed
something called Virtual Box which allow me to run XP in a window on the
laptop And to my amazement I can use MPL8.92 successfully in this
scenario."
#1. The old machine was slow and the I/O on the cable was okay.
#2. The faster userspace I/O on the newer system, caused a higher data rate
on the cable, which directly affected crosstalk. This broke communication.
#3. Now, the faster machine has a virtual machine, which slows down all I/O.
App->VM->OS->USB->serial in comparison to App->OS->USB->serial
(The additional introduction of the VM makes things working for him: all his
I/O is now delayed. Indirectly, it implies the same issue that the edges are
too fast for his cable. He needs to slow down the edges. :-)
R-C filter to damp it ? :-) Does that work ? points to FEXT, I must say)
In my situation, I had an even more funnier situation. The machine was the
same, but if i used a newer cable it would work for a few days. That cable
would behave exactly the same as the old one. Cable had no issues.
Eventually, I figured out that humidity and physical handling the cable a
few times had some effect to the cheap chinese cable. Likely the cable
behaved like a Transmission Line (?) with an increasing capacitance over
time due to a myriad factors.
Userspace drivers are okay if done correctly. But when userspace drivers
are available, it gives the user a chance to make clumsy stuff. But whereas
an in kernel driver, if you do that, everything blows apart. So, the user is
forced to write good applications in case of a kernelspace driver. The
downside is that a kernelspace driver is more difficult to handle in
comparison. This is the prime reason why the Linux kernel drags people
to go with kernelspace drivers instead of userspace drivers.
Cheers,
Manu
Post by Sean BrehenyHi Manu,
I never heard the term NEXT/FEXT before and when I Google it, it seems to
be talking about physical crosstalk. What does that have to do with the
timing issues you mention?
Just trying to understand! Thanks.
Sean
Post by Manu Abrahamhttps://msdn.microsoft.com/en-us/library/windows/hardware/
ff540207(v=vs.85).aspx
WinUSB is a User Mode Driver framework, Kernelspace drivers comply more
to
Post by Sean BrehenyPost by Manu Abrahamtiming restrictions etc etc.. So, the userspace timing dictates your bus timing.
This is dictates your Near END/ Far END (NEXT/FEXT) crosstalk. IIRC correctly,
I've gone through this specific problem. Olin Lathrop has had a
suggestion for this
issue on this ML, a long time back. This did fix the issue for me.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo