Hi!,

On Sun, Feb 1, 2015 at 11:31 PM, Jason White
<whitewaterssoftwareinfo@gmail.com> wrote:
> Thanks Daniel,
>
> It turns out my issue was caused by capacitance between adjacent leads
> on my programming cable. Physically separating the wires on the ribbon
> cable caused it to suddenly start working as expected for me.

I'm glad it works now.

>
> As it turns out an extra 5 picofarads between clock and data lines
> makes a big difference. looking at the math/theory side of this: the
> impedance/reactance for 5 picofarads with a 1.8Mhz sqaure wave is in
> the order of a few K-ohms. So it was as if my clock and data lines
> were momentarily tied together with a resistor every rising and
> falling edge. No wonder I got bad data!

I think that the capacity on the cables alone was not the culprit,
perhaps you have some resistors in series with the signals?

Here is a photo of my current (working) test setup, as you see, my
cables are similar to yours, and the board is not tidy :-)

  https://drive.google.com/uc?export=3Ddownload&id=3D0B1Uh9dgDfzYpSU5PbEpHe=
lk1OVk

Also, for reference, the response from st-util shows is 0x10006444:

 INFO src/stlink-common.c: Loading device parameters....
 INFO src/stlink-common.c: Device connected is: F0 small device, id 0x10006=
444
 INFO src/stlink-common.c: SRAM size: 0x1000 bytes (4 KiB), Flash:
0x4000 bytes (16 KiB) in pages of 1024 bytes
 INFO gdbserver/gdb-server.c: Chip ID is 00000444, Core ID is  0bb11477.

Also, at least in Linux, openocd (0.8) seems faster for debug than st-util.

    Daniel.

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.