Author Topic: MCU Lock Up  (Read 2865 times)

0 Members and 1 Guest are viewing this topic.

Offline FaultlineAudioTopic starter

  • Supporter
  • ****
  • Posts: 17
MCU Lock Up
« on: April 27, 2015, 08:36:03 pm »
Would it be more or less likely that a Micro-Controller would lock up and need to be reset, after a utility power outage was restored if:

1. The backup battery were disconnected

2. The backup battery had been connected

Thanks
Chris
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3644
  • Country: us
Re: MCU Lock Up
« Reply #1 on: April 27, 2015, 09:05:07 pm »
I don't think the problem is specified enough: do you mean manually reset? A regular watchdog should be able to reset the chip if it locks up for whatever reason.
In situation 1 the MCU has been powered off and is just turning on. If there are spikes or brownouts in the line voltage it could be negatively affected. Many MCUs have brown-out detection to hold the chip in reset when the power quality is bad. You want some inductance on the line (like from a line filter) to deal with spikes.
In situation 2, the MCU keeps running. Using a properly rated PMIC is likely to survive line irregularities better than a plain diode in series with the battery circuit.
 

Offline FaultlineAudioTopic starter

  • Supporter
  • ****
  • Posts: 17
Re: MCU Lock Up
« Reply #2 on: April 27, 2015, 11:15:12 pm »
Here's the situation:

In a mid 1990's receiver which uses a NEC UPD75328 4 bit single chip microcomputer.  During a brownout or after a utility power outage, the receiver will not function until the MCU is rest manually.

There is a battery backup in the unit, however there isn't any watchdog circuit.  My question stems for the observation that we have more calls for this problem with units where the backup battery was never connected, than units where the battery was connected.

Does that lack of battery backup to the MCU contribute to the MCU locking up?

Thanks
Chris

 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3644
  • Country: us
Re: MCU Lock Up
« Reply #3 on: April 28, 2015, 12:07:56 am »
I'd guess that the battery only powers the settings SRAM, and not the MCU, because a receiver is pretty useless without a main power source. Some receivers used EDLC supercaps for settings retention, powering a SRAM with 2.5 to 4.5 V.
What could be happening is that the settings SRAM gets scrambled when the power fails, confusing the MCU. The MCU isn't programmed to clear the SRAM on reset because user settings are stored there. So for example, if half of the bits in the SRAM get flipped, it doesn't know that the contents are no longer valid.
After being powered off, an SRAM can power on with a random bitpattern, or be influenced partially by the data stored there before.
 

Offline FaultlineAudioTopic starter

  • Supporter
  • ****
  • Posts: 17
Re: MCU Lock Up
« Reply #4 on: April 28, 2015, 12:52:58 am »
So if the backup battery is connected and the contents of the SRAM is maintained, is it less likely that the MCU will lockup and need to be reset when the power is restored?

Thanks for your help in explaining this

Chris
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3644
  • Country: us
Re: MCU Lock Up
« Reply #5 on: April 28, 2015, 04:13:13 am »
So if the backup battery is connected and the contents of the SRAM is maintained, is it less likely that the MCU will lockup and need to be reset when the power is restored?
That seems like a likely hypothesis. Proving it could require a logic analyzer, if the MCU doesn't have an accessible debug port.
The proper way to avoid this in engineering is to verify the RAM contents using a CRC. If you use a naive checksum to verify the contents, you can get false positives when the same number of bits flip from 1 to 0 as from 0 to 1. But you must then generate a CRC every time you write to the settings RAM.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf