Processor died?

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

I have a board based on an ATMega1284P.  I am using a 20mhz xtal bypassed with 22pf caps.  These boards have been in use for over 5 years (on for maybe 10 hours per week).

 

The other day the board was running when I put my scope probe on XTAL1 or XTAL2 (I do not recall which) and the board no longer runs - correctly.  The scope was grounded to the signal GND on the board but the probe was on 1X rather than 10X.

 

I can connect with JTAG, load memory, read memory, read fuses, etc. but it will no longer run - correctly.

 

I say "correctly" because it appears to execute the bootloader.  My (serial) bootloader turns on a status LED when it is invoked and turns it off when it exits to the application.  The status led is coming on but never going off.  During the 1 second the bootloader is accessing the on-board USART looking for a connect.  If it does not receive a connect within 1 second it starts the application.

 

I'm about to go out to the shop and investigate some more but I wonder if anyone can shed any light before I resort to removing the (SMD) processor.

 

I'll post testing results later.

 

Chuck Hackett

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

If they are not set then set the fuses for the full swing crystal oscillator.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

Bummer.

 

Your onw custom PCB or a commercial PCB?

 

Connecting the O'scope might well (mis) load the oscillator, and make it stop oscillating, but when you remove the probe, and perhaps re-cycle power, the board would be expected to spring back to life.

 

The fact that it didn't makes one wonder if you zapped it with static electricity, perhaps?

 

I don't use JTAG, so I don't recall if JTAG inserts its own clock signal while it is connected and active.

If so, that would perhaps imply that the reset of the uC is working, and the clock is non-functional.

 

Have you adjusted the micro's Fuses at any recent point in time?

Can you simply set the Fuses back to use the internal RC oscillator and see if that works, before moving on with other Fuse settings?

 

Cliff has a Tutorial on un-bricking a micro whose Fuses have been mis-set for a non-present clock source, you might wish to search it out and see if that helps prior to doing a heart transplant on your PCB.

 

JC 

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

Your onw custom PCB or a commercial PCB?

My own design ...

 

I changed the osc to full swing, powered it on and the 0-scope (10X) showed a good clock.  I then re-flashed the bootloader and the bootloader worked.  Then I changed osc fuses back to what I had before and ... it worked ... hmm, I might have missed a step the other day - it was late is all I can say.

 

Then I had an issue with another board.  This one would not run at all but I could load it via JTAG.  After some digging around I discovered that the "reset" line was at 0 all the time.  I evaluated the likely causes that were easiest to eliminate.  I cut the "reset" trace going to a I2C LED driver (TLC59116TSSOP) and everything now worked (except for the TLC59116TSSOP of course).  The customer had reported that he had removed the board (it plugs into a 40-pin connector) and re-inserted it while under power.  I suspect that V+ got connected before GND and that's what fried the LED driver.  In the past I have seen I2C devices (EEPROMS) fried by GND not getting connected first.  There is a lot of field wiring and I suspect that the field wiring was momentarily providing the GND causing things to be reverse biased.

 

So, all in all, it was a good day.

 

Regards,

 

Chuck Hackett

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

Glad to hear it works!

 

It is always nice to definitively determine the cause for a failure, but sometimes that isn't possible, especially in the first case where the failure was intermittent / resolved.

 

There have been lots of "hot swappable" designs and busses over the years.

They were often based on the power connections being physically longer than the signals, so as to insure that they made contact first.

 

The problem, of course, is when a product isn't intended to be hot swappable, and yet the customer proceeds in that manner....

 

JC

 

 

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

DocJC wrote:
They were often based on the power connections being physically longer than the signals, so as to insure that they made contact first.

I worked on a project recently which was intended to be hot-swappable, but they forgot about this!

 

It caused a lot of weird problems and took quite a bit of head-scratching to pin down the cause.

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...