Author Topic: device failure on PICKIT2 (Read 21923 times)

JVR · « **Reply #50 on:** October 22, 2012, 10:23:48 am »

No, what I meant with ''Dont Ever use it though'' is that I dont use it. You can use mplab with external hex files, but it is going to take a lot longer.

Look at the PK2 manual, it has a USB_UART mode, IIRC those use the PGD/PGC pins, so checking if it will work in UART mode with a loopback cable will help assess if the PK is operational.

Still, shut down, reboot, plug directly into PC <- Do those first

Simon · « **Reply #51 on:** October 22, 2012, 10:24:42 am »

Quote from: JVR on October 22, 2012, 10:23:48 am

No, what I meant with ''Dont Ever use it though'' is that I dont use it. You can use mplab with external hex files, but it is going to take a lot longer.

Look at the PK2 manual, it has a USB_UART mode, IIRC those use the PGD/PGC pins, so checking if it will work in UART mode with a loopback cable will help assess if the PK is operational.

Still, shut down, reboot, plug directly into PC <- Do those first

ok

JVR · « **Reply #52 on:** October 22, 2012, 10:25:41 am »

Quote from: Simon on October 22, 2012, 10:23:38 am

maybe I should put a bypass cap in too! where does it end ? but this all worked fine the other day unless the power section has blown, but then it wouldn't work when on the breadboard and powered either.

Remember, the PK is an ICSP programmer, not a Stand Alone programmer. It expects to device to be in a properly configured circuit, bypassed, clamped etc etc

Simon · « **Reply #53 on:** October 22, 2012, 10:52:59 am »

well it is a pity they don't specify the expected circuit environment in the manual.

JVR · « **Reply #54 on:** October 22, 2012, 10:58:34 am »

Quote from: Simon on October 22, 2012, 10:52:59 am

well it is a pity they don't specify the expected circuit environment in the manual.

True, but most of the datasheets have a minimum connection pic in them, you'd need at least that. MCHP is not known for epic documentation, try doing a USB PIC32 design, loads of connections and cap placements are very opaque.

Is it working yet?

Simon · « **Reply #55 on:** October 22, 2012, 10:59:47 am »

I can't check till I get home, in-fact probably not until tomorrow night, so storing up all of the tips for a blast tomorrow night

.

JVR · « **Reply #56 on:** October 22, 2012, 11:03:45 am »

Your going to have a long night

Let us know

Simon · « **Reply #57 on:** October 22, 2012, 11:21:07 am »

will do

deephaven · « **Reply #58 on:** October 22, 2012, 11:38:25 am »

I think I might have a possible answer for you.

There is an issue on the PIC16F883 where programming will often fail if RB3 is not pulled down during programming.

This is described in the errata document. It is highly recommended to check for any errata data on Microchip (and probably other manufacturers!).

Simon · « **Reply #59 on:** October 22, 2012, 11:40:25 am »

Thanks, I'll give that a go too.

JVR · « **Reply #60 on:** October 22, 2012, 02:35:08 pm »

Quote from: deephaven on October 22, 2012, 11:38:25 am

I think I might have a possible answer for you.

There is an issue on the PIC16F883 where programming will often fail if RB3 is not pulled down during programming.

This is described in the errata document. It is highly recommended to check for any errata data on Microchip (and probably other manufacturers!).

Are you kidding me?

Simon, try this first. RB3 was the LVP input on the older F877 silicon, they probably did not remove all the links. FAIL

Simon · « **Reply #61 on:** October 22, 2012, 02:39:09 pm »

so who do I sue for charges at £15/h of my time wasted ?

I am amazed at this, does this really mean that RB3 can't be used for much if the pic is to be programmed in situ ? soon I'll be going atmel !

deephaven · « **Reply #62 on:** October 22, 2012, 03:15:43 pm »

Quote from: Simon on October 22, 2012, 02:39:09 pm

so who do I sue for charges at £15/h of my time wasted ?

I am amazed at this, does this really mean that RB3 can't be used for much if the pic is to be programmed in situ ? soon I'll be going atmel !

Well, I was fortunate in my design that I happen to be using RB3 as a switch input, so I just had to remember to make sure the switch was on when programming the thing.

I haven't used any Atmel parts for a long time, maybe someone that has can comment on whether or not they have erratas to the same extent that Microchip does.

Looking up erratas is just part of my procedure now when I'm thinking of incorporating a different chip.

Simon · « **Reply #63 on:** October 22, 2012, 03:39:45 pm »

To be honest if all current chips out there have this defect it should be noted on the datasheet, not a seperate document.

Simon · « **Reply #64 on:** October 22, 2012, 08:22:37 pm »

well programming completed and verification checked out. Thank you for all your help guys, I'll be trying it out tomorrow now so fingers crossed and hopefully the pickit3 is a nice addition

JVR · « **Reply #65 on:** October 23, 2012, 06:21:56 am »

Great news

Really cant believe they stuffed the silicon that badly. Just shows that the 88X series was not a new design, merely a slight facelift from the 8XX series

Simon · « **Reply #66 on:** October 23, 2012, 11:47:18 am »

I fail to see the need for so many pic parts to be honest. after most pin numbers, clock speeds and number of periferals (linked to pin number) are taken care of how many variants does that leave ?

chach123 · « **Reply #67 on:** October 23, 2012, 05:02:52 pm »

hello there,
what where u mentioning of pic progremming doesn't work well ?
well i'm not that educated , but u know what ,
once, when i programmed a pic , i have kept programming it while LVP (low Voltage programing ) option ticked, ( it was default

) , and i kept getting similar response from pic as u getting now , after deselect LVP option, then programing happened correctly... .
that option is there, where u select Osc mode, RC,XC,HS such ...
i don't know if u experience this case,
just mentioned,

bye bye

Simon · « **Reply #68 on:** October 23, 2012, 05:04:37 pm »

Yes i had this problem on another project so learn there. It seems there is a similar problem here but it relates to a "bug" in the chip and i need to ground a pin when I flash it.

poorchava · « **Reply #69 on:** October 25, 2012, 11:57:36 am »

I think the reason for the multitude of Microchip controllers comes from customer needs. It's not always that company orders an ASIC and this ASIC is customer specific. I mean the development was driven by customer needs, but is not customer exclusive. This means that company develops a chip based on needs of particular customer, but the chip gets included in company portfolio and is available to public. This means that customer does not need to cover full costs of development, because the semiconductor company can make profit on that chip from other clients too.

This can be easily seen on the example of Toshiba, AllegroMicro, ICHaus.

This is a common situation, but I don't know for sure whether this applies to Microchip - those are only my suspicions.

btw. Microchip reuses silicon in other cases too. At one point they apparently made some very severe fuckup in either design or fabrication of pic18k[something] which caused mcu to be disfunctional to a degree even Microchip cannot accept. But some part of the chip together with USB module were ok, so they made some quick hack and marketed those as usb-uart bridges. I think someone at some forum pointed out the fact, that usb bridge when connected to a programmer through some supposedly unused pins identifies itself as pic18k series

Simon · « **Reply #70 on:** October 25, 2012, 12:00:27 pm »

They do that on processors too, that why you have so many speeds.

They still have a stupidly large range of pics all so similar that it don't always make sense.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: device failure on PICKIT2 (Read 21923 times)

Share me