 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Bad silicon?
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
I have a batch of boards I have been trying to program tonight - 20x E64 module. I bought the chips from Microchip direct, date code 2104. Of the ten that I have tried so far, eight of them simply won't talk to either PIC32PROG+GUI or even Microchip's IPE, or they give invalid processor type errors(see other thread), or code protected errors. The latter of which is utter bollocks, as they are all brand-new chips and have never been programmed before, so how can you code-protect a virgin chip? I am now wondering if I have a crook batch of chips. I would be extremely interested to hear from anyone who has tried to use the 64-pin chip, if their chip came from the 2104 batch - did it program for you? Did you have any problems? I have tried different PSU's, bypassing suspect parts or connections, checking all connections from the chip(they are all present). I might have stuffed up the soldering on one module, but not eight out of ten! I've been soldering 0.5mm pitch TQFP's for several years now, and never had this issue on this scale before. Occasionally, I might bridge a pin and not spot it, but I find that during visual examination and fix it. All these boards that won't program are fine - no solder bridges, and all the legs are reflowed correctly. Anyone got any ideas or suggestions? I'm thinking about sending a message to Microchip to see if they have received other reports of chips that won't program. I am wondering cos of the virus and the crazy demand for silicon, that perhaps a batch was rushed through super-speed, and something went wrong in the process and you end up with crook chips. Possible? Not possible? Smoke makes things work. When the smoke gets out, it stops! |
||||
CaptainBoing Guru  Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
do you have a picKit you can try with? Download a fresh copy of MC's IDE - it pulls the "personality" for a family of chips when you select it in the programmer If you use microchip line right through and still have problems then I'd put in a call with them Edited 2021-04-10 18:00 by CaptainBoing |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
Paragraph two.  Yes, tried with IPE and PK3 - they refuse to talk to them either. This is so strange. I've never seen this before. Swapping 20 64-pin TFQP chips - if that is what has to be done - is not really my idea of fun.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 375 |
Sounds like a silicon version change ? |
||||
mikeb Senior Member  Joined: 10/04/2016 Location: AustraliaPosts: 173 |
Windows 10 ? I have Win 10 refusing to install updates because it doesn't like my VM or Disk Backup tool. It was OK for 3 years now their 'Security' patches decide it's not on. Have you tried a different PC with a known working OS ? Regards, Mike B. There are 10 kinds of people in the world. Those that understand binary and those that don't. |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 375 |
>>Of the ten that I have tried so far, eight of them simply won't talk to either PIC32PROG+GUI or even Microchip's IPE, or they give invalid processor type errors(see other thread), or code protected errors. So are the other two connecting ? The problem seems the same in both threads so it is not much point looking at specific dates etc. There is an errata 2020 to check [ assuming the boards are ok of course !! ] Edited 2021-04-10 20:31 by zeitfest |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
the 'bitbang' extension of pic32prog support a couple of switches for performing an "emergency" erase. these are: // // The below few lines enable a forced "emergency" erase, // use -b8 for MX processors, -b9 for MZ processors // // once the erase is completed, exits from pic32prog // so run pic32prog without any .hex file specified on the command line, and with the switch "-b8" added. i put this in when i was managing to occasionally 'brick' some MX150's during development, as a means of recovering them - it worked. as i recall, mplab was also able to recover these chips, but was a major pain to get running for such a small task! cheers, rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
@ Mike: Yes, W10. I do have a Win8 machine I know is good. I might see if I have any luck there. Good idea. Worth a try. I don't expect it to work though, cos I am starting to think this is a crook batch of silicon. @ zeitfest: YES. The other two programmed and worked just fine. @ Rob: Thanks. Result: pic32prog -d ascii:com3 -b8, "Attempting blind erase of MX processor". Dropped back to C prompt. Run GUI attempt to program, no target found. I will now reflow this one once more just to be 100% sure there are no dicky joins between the pins and the pads, although I am pretty sure there is no issue there. I have a few chips from a different batch, so if reflowing does not help, I will remove ONE chip, and replace it with one from an earlier batch and see if I still have the problem. This would help me prove one way or another if we perhaps have a bad batch of chips. Smoke makes things work. When the smoke gets out, it stops! |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 639 |
Good morning All Grogster, you have a batch of PICs and a batch of 10UF caps. Why are you blaming the PICs? Also, how about USB cables etc? Yes, I know, you are correct the chips are faulty but? Peter |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
Same USB cable I use for all my PIC32 work. I can connect an E28 module to the exact same USB cable, and it talks just fine, so it's not the cable. I have now reflowed one board, and triple checked all the pins to make sure they all have a nice shiny fillet of solder connecting them to the pads. pic32prog - no target found. This is very strange. The chips are normally bulletproof. I suspect them, but still want to find something else causing this, cos like I say - the chips normally never are a problem in the hundreds I have used to date. @ Peter: You have a point about the cap. It is much easier to replace that as a test, then to remove the chip, so I will now change the Vcap, just to be sure I have covered that base also, but then the only thing left to try, is removing this chip, and putting one on from an earlier batch to see if it will talk to me. Can anyone think of anything else I should be trying before I remove the chip? Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
Changed Vcap for a brand new 10uF X5R one - no target found. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
Swapped the PIC32 for one I had here from a 2018 batch, double checked everything, tried to program - no target found. CAN'T be the chips then, or this one would have worked. I wonder if I have crook PCB's? Perhaps I have an o/c via or two between the 1455 and the PIC32 - that would certainly cause all these problems. It is very rare for a PCB to be crook, but I HAVE had PCB's with o/c vias before, so it CAN happen..... I will now check all the lines between the 1455 and the PIC32 are intact. That should not stop the PK3 and IPE from being able to talk to the chip though, and it can't either.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
FIXED THE PROBLEM!!!!  It was not the chips, it was Grogsters stupidity.....   The E64 boards I was assembling, were an older model. In that design, I used a supervisory chip(MCP130-315), but this model has a BUILT-IN 10K PULLUP TO 3v3. I did not bother to install it, cos I did not have any left, and have found that they did not really make any difference based on all the other boards I have built without one, but without it on THIS design, MCLR is left floating, as it relies on that 130 supervisory chip to also pull-up MCLR. I fitted a 10k resistor as a test, and bingo - all systems go. Now ALL the boards program fine. I post this, so you all can have a great big laugh at my expense, and I deserve it, as I am actually the root cause of my problems here.  "I think the phrase rhymes with 'Clucking Bell'" - Blackadder. Smoke makes things work. When the smoke gets out, it stops! |
||||
| PeterB Guru Joined: 05/02/2015 Location: AustraliaPosts: 639 |
You alone will understand how tickled pink I am. Peter |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
Yes, I think I can! I'm just glad I finally found the problem, and feel a little guilty now blaming the chips. It was only after I replaced one of the 2021 batch with one from 2018 - and the problem was still exactly the same, that I knew it MUST be something else, so went back through all my records and schematics till I found that model of E64, and....eureka! Beaten by my own design.....   Smoke makes things work. When the smoke gets out, it stops! |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
It's so easy to miss foul-ups in your own work. I know this from my days as a draughtsman, where swapping two digits of a 4-digit wire number can take ages to find on the shop floor when a test fails. :( Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
oh if I had a pound... glad it's working |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9044 |
I DO want to send a very heartfelt thanks to everyone who replied on both threads, as I really was totally confused as to why it would not work - when I have built heaps of those modules now.  So - thanks, everyone.   Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
