I had a customer that ordered 6 PICs as samples from MicroChip, and not=20
one of them would oscillate at 20MHz.  Really threw me for a loop when=20
the boards were built and none of them ran.

Kerry


Philip Pemberton wrote:
> Here's a strange one...
>
> I've just built five DiscFerret (<http://www.discferret.com/>) boards.=20
> All four were built using Multicore LF318 paste in a reflow oven. Peak=20
> temperature was 240C, checked with a K-type thermocouple. The reflow=20
> profile was Kester's "standard Lead-Free profile", which matches one of=20
> Multicore's standard profiles (although the datasheet implies that it's=20
> hard to screw up the reflow profile for LF318).
>
> All the parts on all the boards are REV 0x03 (as reported by my=20
> PICKit2), which (it seems) would make them Rev A3 or A4. Date codes are=20
> as follows:
>    07374AT -- fitted to two working boards
>    1028YWW -- fitted to one working board and two faulty boards
>
> All boards are running my variant of Microchip's HID bootloader, and the=
=20
> same firmware revision is loaded.
>
>
> My ATE tests run a bunch of tests on the FPGA-to-PIC comms link:
>    1) PIC =3D> FPGA Comms
>       The PIC uses two I/O pins (RE0 and RE1) to communicate with a small
>       shift register / FSM on the FPGA. This FSM latches the state of the
>       other ten FPGA I/Os, then feeds this data back to the PIC over a
>       two-wire "SPI-like" link. The PIC reads 23 bits: 20 zeroes, a one,
>       then the 10 data bits.
>
>    2) FPGA =3D> PIC Comms
>       The PIC uses the same two I/O pins to shift data into a shift
>       register on the FPGA (it's a different config bit-stream). The FPGA
>       dumps this data onto the ten I/O lines, then the PIC reads the
>       state of the pins.
>
>    3) PMP Data Bus Test
>       The PIC is remotely reset, forcing re-enumeration and Parallel
>       Master Port re-initialisation (tests 1 and 2 disable the PMP).
>       The FPGA is reprogrammed, then the PMP is then used to read two
>       FPGA registers: FIXED55, which always returns 0x55, and FIXEDAA,
>       which always returns... (drumroll please)... 0xAA.
>       There's also a Scratchpad register to which the PIC can read and
>       write (this is part of the Data Write test).
>
>
> Here's the issue. Tests 1 and 2 pass on all four boards. If I shove a=20
> piece of wire between a pin and ground, I get a FAIL on whichever test=20
> is running at the time. This is good...
>
>
> Problem is, only two of the four boards can actually communicate with=20
> the FPGA using the PMP. The other two always return a value of 0x00 when=
=20
> reading FIXED55 and FIXEDAA.
>
>
> Can anyone think why the PMP might do this?
>
>
> The code is online at <http://hg.discferret.com/firmware/>. Click=20
> "files" to get the file list, then the "file" link next to a file to=20
> view its contents. Almost all of the interesting code is in=20
> HardwareProfile.h and main.c; the rest of the code is the Microchip USB=20
> Framework.
>
> I'm starting to think "defective chips", but these were new-out-of-tape,=
=20
> ordered via Microchip Samples to replace three others that were DOA...=20
> (doesn't bode well, does it?)
>
> Thanks,
>  =20



--=20
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.289 / Virus Database: 267.11.13 - Release Date: 10/6/05

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