Purchased Pre-programmed ATMEGA Chips - Cannot Read/Write/Erase Via Atmel Studio

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone,

 

So due to the ongoing chip shortage and supply chain issues I've only been able to source "used" or "refurbished" parts for some of the components that I use. I received some ATMEGA64M1's recently and was planning on using them to replace the same part on boards that I rebuild. I'm able to successfully read the flash and EEPROM data from the original chips via ISP but I can't do anything with these refurbished pieces. I keep getting an error in Atmel/Microchip Studio saying that it's failed to enter the programming mode. It also will not read the device signatures. I've tried 2 of these chips so far and have had the same results.

After doing some reading I realize that the lock bits or fuses may be an issue with them since they've been previously programmed. However, I'm not 100% sure if that's the case or if the chips are just dead/bad to begin with. Is there any way to confirm if they're just locked or completely dead via Atmel Studio?

 

If they were readily available I'd purchase these new if I could. Anyway, I'm a novice when it comes to this stuff and I've read about parallel programming but I don't think I will have the time and patience to even begin such a project.

 

Thanks in advance!

Last Edited: Wed. Jan 5, 2022 - 03:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Presumably that chip has JTAG? Perhaps SPIEN has been disabled via JTAG? If you have access to a JTAG debugging interface I'd try connecting with that to check fuses. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
ATMEGA64M1

Datasheet says it has debugWIRE - so perhaps they're in debugWIRE mode ... ?

 

or locked ?

 

EDIT

 

Recent thread about switching between debugWIRE and ISP: https://www.avrfreaks.net/forum/why-disable-debugwire-and-close-after-debug-session

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 5, 2022 - 03:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Possible causes:
1. The fuse SPIEN is disabled. In this case, the only way to recover is parallel programming.
2, clock is not supplied. If your board expects an internal RC and the chip you purchased expects an external clock, somehow you can force the clock into the XTAL1 pin to enable your ISP.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


clawson wrote:

Presumably that chip has JTAG? Perhaps SPIEN has been disabled via JTAG? If you have access to a JTAG debugging interface I'd try connecting with that to check fuses. 

 

Unfortunately, I don't think this chip has JTAG as an interface option 😟

 

awneil wrote:

SaMirakle wrote:
ATMEGA64M1

Datasheet says it has debugWIRE - so perhaps they're in debugWIRE mode ... ?

 

or locked ?

 

EDIT

 

Recent thread about switching between debugWIRE and ISP: https://www.avrfreaks.net/forum/why-disable-debugwire-and-close-after-debug-session

 

I'm not sure how to go about even looking this up. I'm a bit of a novice when it comes to this stuff. I don't recall seeing this option anywhere in the Device Programming window which is all I hoped I would need to be using in the first place. All I'm trying to accomplish is writing the data that was read from the original chips to the refurbished chips. 

 

kabasan wrote:

Possible causes:

1. The fuse SPIEN is disabled. In this case, the only way to recover is parallel programming.

2, clock is not supplied. If your board expects an internal RC and the chip you purchased expects an external clock, somehow you can force the clock into the XTAL1 pin to enable your ISP.

 

1. Is there even a way to check if SPIEN is disabled? Since I can't read any of the setting data off of the chips all of the values are unknown.

2. The PCB has an external oscillator on the board and works fine with the original chips that came on it. I'm thinking the only way to go about this would be with parallel programming?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If ISP isn't working, you can't see anything with ISP. It's a stalemate.
It is also possible that you are in debugWIRE mode as mentioned in # 3.
You can create an empty project in Microchip Studio, start debugging, and then switch back to ISP mode.
Please read the thread presented and learn to that extent. It shouldn't take a lot of time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:

1. Is there even a way to check if SPIEN is disabled? Since I can't read any of the setting data off of the chips all of the values are unknown.

 

Not without parallel programming

 

SaMirakle wrote:

2. The PCB has an external oscillator on the board and works fine with the original chips that came on it. I'm thinking the only way to go about this would be with parallel programming?

 

You're probably correct. The good news is that since you only need to do a chip erase the hardware to do that with parallel programming isn't too arduous. Most of the pins can be hard-wired. I reckon, out of 17 pins used for parallel programming, you only need to manipulate 4 of them. However, one of them is XTAL1 so your on-board oscillator connections might be an issue.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
After doing some reading I realize that the lock bits or fuses may be an issue with them since they've been previously programmed.
BOD may be enabled; might try other VCC.

SaMirakle wrote:
Is there any way to confirm if they're just locked or completely dead via Atmel Studio?
No though can instrument by a logic analyzer and decode.

VCC has to be stable, off the BOD, in the SOA, and dVCC/dt within limits (glitch)

Clock has to be within limits (glitch or iow ΔtCLCL) and SOA.

VCC and/or clock glitching will cause a CPU or NVM controller anomaly.

SaMirakle wrote:
If they were readily available I'd purchase these new if I could.
Which ATmega64M1 package? (TQFP, QFN)

Reasons :

  • mega64M1 wafer fab count has increased though there's a lead frame shortage
  • microchipDIRECT

 


libsigrokdecode/decoders/avr_isp at master · sigrokproject/libsigrokdecode · GitHub

due to

Protocol decoders - sigrok

 

Tempe Fab 2, Gresham Fab 4 | AVR Freaks

ATMEL parts are running out of stock due to wafer shortage ? | AVR Freaks

Lead Time | World's Largest Inventory of Microchip Products (enter ATmega64M1)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kabasan wrote:
You can create an empty project in Microchip Studio, start debugging, and then switch back to ISP mode.

^^ This ^^

 

But this will require that you have a suitable debug probe.

If you don't have one, and can't find someone to lend you one, getting an XPlained or curiosity board with built-in debugger is going to be the cheapest option: https://www.avrfreaks.net/commen...

 

Please read the thread presented and learn to that extent. It shouldn't take a lot of time.

This one: 

awneil wrote:
Recent thread about switching between debugWIRE and ISP: https://www.avrfreaks.net/forum/why-disable-debugwire-and-close-after-debug-session

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try slowing the ISP clock rate. The chips MAY be set for a low clock rate and ISP must be 1/4 that or slower.  For fuses, you can afford to set the ISP clock quite slow, then update the fuses. Remember that new fuses take effect only on a RESET which usually means "power-up".

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Which ATmega64M1 package? (TQFP, QFN)

 

Well surely it's not the TQFP as Mouser alone has over 7000 in stock(though they ain't cheap),  and Microchip Direct has over 2000

Last Edited: Wed. Jan 5, 2022 - 07:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Which ATmega64M1 package? (TQFP, QFN)

Reasons :

  • mega64M1 wafer fab count has increased though there's a lead frame shortage
  • microchipDIRECT

 

Unfortunately, it's the QFN-32 package and they're not in stock anywhere. 

ka7ehk wrote:

Try slowing the ISP clock rate. The chips MAY be set for a low clock rate and ISP must be 1/4 that or slower.  For fuses, you can afford to set the ISP clock quite slow, then update the fuses. Remember that new fuses take effect only on a RESET which usually means "power-up".

 

Jim

 

I've tried setting the speed to various different options and end up with the same result.

awneil wrote:

kabasan wrote:
You can create an empty project in Microchip Studio, start debugging, and then switch back to ISP mode.

^^ This ^^

 

But this will require that you have a suitable debug probe.

If you don't have one, and can't find someone to lend you one, getting an XPlained or curiosity board with built-in debugger is going to be the cheapest option: https://www.avrfreaks.net/commen...

 

Please read the thread presented and learn to that extent. It shouldn't take a lot of time.

This one: 

awneil wrote:
Recent thread about switching between debugWIRE and ISP: https://www.avrfreaks.net/forum/why-disable-debugwire-and-close-after-debug-session

 

 

I may have to try this later when I have more time. I ran out of time to spend on this issue between yesterday and today.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:

Unfortunately, it's the QFN-32 package and they're not in stock anywhere.

 

 

Might be worth an email as they claim to have 60k of them.

 

https://www.pcbekey.com/products...

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Wed. Jan 5, 2022 - 10:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Beg Borrow or Steal an old STK500 and STK501. That combination allows High Voltage Parallel Programming.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Jan 5, 2022 - 10:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I received some ATMEGA64M1's recently and was planning on using them to replace the same part on boards that I rebuild.

Why? For what reason would you need to install a new AVR?  They should be extremely extremely reliable in operation...maybe if you had 1 million boards, one or two might quit functioning due to an AVR failure. 

If you are needing to replace more than one or two in a large batch of boards, something is seriously wrong with the design, or you are shotgunning your repair.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It may be a language issue (Texas, you know). To me, #1 sounds like the OP manufactures some boards and is not able to get new micros through usual sources. Because of this, "used" micros are being used.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Brian Fairchild wrote:

SaMirakle wrote:

Unfortunately, it's the QFN-32 package and they're not in stock anywhere.

 

 

Might be worth an email as they claim to have 60k of them.

 

https://www.pcbekey.com/products...

 

This won't work due to a lower working temperature range but thanks for the help!

 

N.Winterbottom wrote:

Beg Borrow or Steal an old STK500 and STK501. That combination allows High Voltage Parallel Programming.

 

 

Thanks. I may look into one of those in the near future if still needed.

 

 

Thanks! Do you know if the AVR Dragon is capable of HVPP? 

 

avrcandies wrote:

I received some ATMEGA64M1's recently and was planning on using them to replace the same part on boards that I rebuild.

Why? For what reason would you need to install a new AVR?  They should be extremely extremely reliable in operation...maybe if you had 1 million boards, one or two might quit functioning due to an AVR failure. 

If you are needing to replace more than one or two in a large batch of boards, something is seriously wrong with the design, or you are shotgunning your repair.

 

 

They're found on an automotive part so they undergo a bit of external stress to begin with. I'm troubleshooting a common failure with these boards and this is essentially the last embedded system component that I haven't been able to replace yet. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
I'm troubleshooting a common failure with these boards and this is essentially the last embedded system component that I haven't been able to replace yet.
Can we be clearer please?

 

1. Do you know for certain what the cause of failure is?

 

2. Is the ATmega64M1 the only component that you are replacing that restores the whole assembly to complete functionality?

 

 

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They're found on an automotive part so they undergo a bit of external stress to begin with. I'm troubleshooting a common failure with these boards

Yes that can be a tough environment...so hopefully your investigation (is it an investigation or repair?...your post says rebuilding)....reveals the culprit.  The AVR should be plenty tough enough (assuming you have the correct temp grade), but you need to ensure that the IO, power, etc are protected against transients/ESD, supply pin regulation overvoltages, etc. There's also mechanical things to consider, such as vibration.  It might be time for a design review. 

 

Watch out for "weak" counterfeit parts.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
They're found on an automotive part

Are you still hacking this: https://www.avrfreaks.net/commen... ?

 

SaMirakle wrote:
so they undergo a bit of external stress to begin with.

Surely, the design should be such that it protects the "sensitive" AVR from over stress?

 

I'm troubleshooting a common failure

If the design allows the AVR to be routinely over stressed - to the point that failure is common - then that's a design fault. If you just replace the failed AVR, then it's going to happen again.

 

and again.

 

avrcandies wrote:
It might be time for a design review. 

+1

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valusoft wrote:

SaMirakle wrote:
I'm troubleshooting a common failure with these boards and this is essentially the last embedded system component that I haven't been able to replace yet.
Can we be clearer please?

 

1. Do you know for certain what the cause of failure is?

 

2. Is the ATmega64M1 the only component that you are replacing that restores the whole assembly to complete functionality?

 

 

 

1. I'm still trying to figure that out but I'm pretty certain it's a communications/software-related issue. It could be a faulty MCU or possibly even corrupted memory. It also could be caused by high temperatures since it's located in the engine bay.

 

2. The MCU is pretty much the last embedded system component that I suspect might play a part in the issue. I've replaced the CAN transceiver and another IC that sends data to the MCU to control a motor. There's a hall effect IC that transmits a position signal to the MCU but I highly doubt it would be a suspect.

 

avrcandies wrote:

They're found on an automotive part so they undergo a bit of external stress to begin with. I'm troubleshooting a common failure with these boards

Yes that can be a tough environment...so hopefully your investigation (is it an investigation or repair?...your post says rebuilding)....reveals the culprit.  The AVR should be plenty tough enough (assuming you have the correct temp grade), but you need to ensure that the IO, power, etc are protected against transients/ESD, supply pin regulation overvoltages, etc. There's also mechanical things to consider, such as vibration.  It might be time for a design review. 

 

Watch out for "weak" counterfeit parts.

 

Yep, electronics in automotive applications can be a pain due to the extremities they're subjected to (heat, vibrations, moisture, etc). It doesn't happen with all of the units I rebuild but I've been seeing quite a few of them lately with this issue I'm trying to resolve. The ATMEGA that's in these is an automotive-grade so it's rated at 150 C but I worry that it may not be tough enough and could be causing data transmission issues. I have some tiny heatsinks I may try out in the near future to see if it corrects the defective units. I guess we'll see how things play out. It just really doesn't help when parts are becoming more and more scare now.

Last Edited: Fri. Jan 7, 2022 - 12:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
I have some tiny heatsinks 

They won't help the AVR.

 

Heatsinks are for when a component needs to dissipate heat - that's not going to be the problem here.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

@SaMirakle,

If you want to send me the parts I can put them in my STK-600 as I have the proper routing/socket card setup for JTAG/Parallel programming and check if they are salvageable for you.

 

PM me if you would like to set something up.

 

Cheers,

Jim

 

EDIT:

SaMirakle wrote:
Unfortunately, it's the QFN-32 package and they're not in stock anywhere. 

 

Missed that.  Lemme see if I have a QFN-32 socket card......

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Fri. Jan 7, 2022 - 01:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

SaMirakle wrote:

They're found on an automotive part

 

Are you still hacking this: https://www.avrfreaks.net/commen... ?

 

 

SaMirakle wrote:

so they undergo a bit of external stress to begin with.

 

Surely, the design should be such that it protects the "sensitive" AVR from over stress?

 

I'm troubleshooting a common failure

If the design allows the AVR to be routinely over stressed - to the point that failure is common - then that's a design fault. If you just replace the failed AVR, then it's going to happen again.

 

and again.

 

 

avrcandies wrote:

It might be time for a design review. 

 

+1

 

 

 

No, I gave up on that thing a long time ago haha. Anyway, I'm still trying to figure out what the actual cause of the problem is. Hopefully I can figure it out soon. Until then it's a game of trial and error.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
There's a hall effect IC that transmits a position signal to the MCU but I highly doubt it would be a suspect.
Somewhat concur; to confirm, can add an exception or assertion (range check)

Reason : original '00 F350 diesel camshaft sensors had a 30K mile lifetime (optoelectronics gain will reduce with age)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

SaMirakle wrote:
I have some tiny heatsinks 

They won't help the AVR.

 

Heatsinks are for when a component needs to dissipate heat - that's not going to be the problem here.

 

You may be right but it may be worth a try. A lot of automotive electronic modules tend to fail due to excessive heat stress. Of course, it could also be some passive component that's disrupting data signals when getting too hot or failing. Who knows, right?!?! cheeky

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Might be an option to get you moving:

 

https://www.ebay.com/sch/i.html?...

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
vibrations
Fractured wires and automotive safety - EDN

Reason : '06 VW New Beetle, intermittent false security alarm with pulsing horn, damaged cable sheath located after mechanic removed the dash top panel (warranty)

PCB traces can fracture ... QFN solder joints can fracture (some vehtronics have system requirements for QFP)

Underfill revisited: How a decades-old technique enables smaller, more durable PCBs - Embedded.com

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Might be an option to get you moving:

 

https://www.ebay.com/sch/i.html?...

 

Jim

plus US$64 shipping! WOW! The seller must be carrying them himself by air.

Ross McKenzie, Melbourne Australia

Last Edited: Fri. Jan 7, 2022 - 01:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valusoft wrote:

plus US$64 shipping! WOW! The seller must be carrying them himself by air.

 

I guess you are looking at teh Real world cost and subtracting that from the price gouge to get teh 'free shipping' charge LOL.

 

Yep, but right now, Microcontrollers are like toilet paper.....a necessity, hoarded, and overpriced....

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

SaMirakle wrote:
vibrations
Fractured wires and automotive safety - EDN

Reason : '06 VW New Beetle, intermittent false security alarm with pulsing horn, damaged cable sheath located after mechanic removed the dash top panel (warranty)

PCB traces can fracture ... QFN solder joints can fracture (some vehtronics have system requirements for QFP)

Underfill revisited: How a decades-old technique enables smaller, more durable PCBs - Embedded.com

 

 

Too bad there isn't any underfill on these boards. Shame shame! My application uses the QFN package, unfortunately.

 

valusoft wrote:

jgmdesign wrote:

Might be an option to get you moving:

 

https://www.ebay.com/sch/i.html?...

 

Jim

plus US$64 shipping! WOW! The seller must be carrying them himself by air.

 

Wow, those prices are nuts! They're not even the 150 C temp rated ones either. I was quoted about $55 each for new ones from that PCBE link I was referred to earlier. 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read somewhere that Automotive Electronics Designers shun QFN packages due to over-bearing soldering quality inspection requirements. (I can't find any link now)

 

However the Semiconductor Manufacturers seem to be trying to reverse this situation with Wettable Flank packages.

 

https://www.nxp.com/docs/en/application-note/AN3111.pdf

https://e2e.ti.com/blogs_/b/behind_the_wheel/posts/the-value-of-wettable-flank-plated-qfn-packaging-for-automotive-applications

 

I would suggest that OP's failures may be due to soldering quality. (and temperature cycling causing fractures)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SaMirakle wrote:
It also could be caused by high temperatures since it's located in the engine bay.

All of the ECU's and body controllers, etc., I've seen are usually located in the passenger compartment where conditions are not as extreme, is there a reason for the unit to be in the engine bay?

Jim

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

SaMirakle wrote:
It also could be caused by high temperatures since it's located in the engine bay.

All of the ECU's and body controllers, etc., I've seen are usually located in the passenger compartment where conditions are not as extreme, is there a reason for the unit to be in the engine bay?

Jim

 

not so sure about that.  The “main brain” of my 2004 Jeep is under the bonnet.  Many of the Porches I worked on as a youngster were in the engine bay, or in close proximity as well..

 

right side Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
... in the passenger compartment where conditions are not as extreme,
IIRC, automotive cab spec temperature range is up to 100C (atypical ranges?  20C .. 100C, -55C .. 0C)

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

IIRC, automotive cab spec temperature range is up to 100C (atypical ranges?  20C .. 100C, -55C .. 0C)

True, until the naked ape turns on the AC or Heater!

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's for a diesel application where it's not uncommon to have engine control units located in unconventional places 🤦‍♂️