Split from: Chip Reset/Hang

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

HI guys

I am new to this forum and have a similar problem so wondered if you ever got to the root of this problem?  My board is small and no heavy currents at all BUT the Atmega328 I am using can sometimes hang in this strange state.  Resetting does nothing, the only way to get it back is disconnecting the battery and start it up again.  When it hangs, the clock signals become smaller (1.5v ish) even though the supply is 3.3v. I wondered if anyone knows what state the 328 is in when it does this?  I have lots of smoothing caps close to the 328 and there should be no currents above 15mA anywhere on the board. Thanks in advance for any suggestions.

Edmo117

Last Edited: Sat. Nov 9, 2019 - 04:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The L298 is pretty old & sad...there are much better chips now, that include things like temperature protection (if too hot , shuts off) and short circuit protections.  Also, the new chips are mosfet based, so they drop 0.1volts instead of 2 Volts!! 

Take a look at something newer & be happy you did.

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

Hi Avrcandies and thanks for the swift reply however, I am not using L298 or any other motor driver.  The small board I have does not take very much current at all, only powering up a LCD and a BlueTooth module some of the time.  My problem occurs at switch on when the micro AtMega328p does not start up properly.  The clock is running but it does not start up the program code.  It just hangs and a reset does nothing so I have no idea what state the AVR is in at this time.  For now, I am investigating if power supply glitches can cause such a problem but have not, as yet, found a definitive answer so that I can put in place the correct fix.  I have seen this before on other boards but have never found out what could cause such a strange effect.

 

All suggestions most welcome.

 

Thanks

Edmo117

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

Welcome to the Forum.

 

Perhaps a Moderator will split this off into its own Thread, beginning with post #41.

 

Edmo,

Please post a complete and accurate schematic diagram of your project and its power supply.

Please post a photo of your setup.

 

It is often helpful to post a short, complete, program that demonstrates your problem.

 

Is the problem present on a commercial PCB, or is this a custom designed board?

What is your power supply? (Wall wart, batteries, bench top supply, etc.).

 

You mentioned a change in the clock signal's amplitude.

Is that an SPI clock, or the clock driving the micro, (Crystal, etc.)?

Presumably it is the former.

 

JC

 

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

Thanks for the response JC.

Unfortunately I cannot publish the schematic for NDA reasons but suffice to say it is an AtMega328p talking to an MPU9250 accelerometer chip and a LCD (just a small one). It also has a BlueTooth module on there but that is not powered up most of the time, only when required (power switched by FET as needed).  I have 0.1uF caps within 3mm of the Atmega supply pins as well as a 1uF for any peaks.  The power is supplied by a Li-Po Battery (3.7v) into an MCP1700-3.3v regulator that has 1uF on its inpit and output very close to the regulator.  It is a new custom design PCB.  I have observed a strange effect at switch on.  With the BlueTooth module removed from the board, it starts up OK every time.  With the BlueTooth module connected (power and GND only) it freezes on switch on even though the module supply FET is off.  If I connect the module directly to the 3.3v there is not a problem at switch on so I am thinking it is to do with some sort of power surge at switch on somehow getting through the FET.  Since it works OK with the module connected to the 3.3v directly I can "fix" the problem by fitting a 0.1uF cap between the gate of the FET and GND so that at the instant of switch on, the FET is turned hard on before the AVR even starts to wake up.  The FET is then turned off by the AVR as it starts to run its program and all is nice day.  The problem is, I don't like "fixes" I want to find the route cause of the problem so am now scoping the power lines everywhere to see if I can see any spikes that may cause the AVR to freeze although I have to say I do not understand what state the AVR is at that time.

Edmo117

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

So, I'm guessing the BT is switched by a High Side PFet?

Does it switch with logic levels, or is it an NFet driving a PFet which then drives the BT module?

 

From your description I would guess that the uC pin that is transmitting to the BT is logic High, before the BT has its power turned on.

The BT is then --> partially <-- powered up via its RxData signal line.

This is causing the BT module to be only partially functioning correctly, and it is drawing power and not working correctly.

 

The micro's pin will power up as in input, (Hi impedance state).

So, ideally, turn on the BT's power supply before you make the TxData line an output, and high.

 

You might wish to put a pull down resistor on the TxData line, if needed.

 

Low side NFet power switching the BT module is not a good idea for several reasons.

I assume, as mentioned above, you are using a high side driver.

 

A cap on the Fets gate may not be a good idea, either, (It all depends...).

A simple pull-down resistor might be better.

With a cap the Fet will be in its linear state, with a slow turn on and turn off, every time you power it on and off.

When in its linear state it has a high Rds and will burn up energy as heat.

 

When the Gate is cleanly switched the Fet is either on with a low Rds on, or off, and it burns up much less energy as heat.

So, some attention to current flow, Rds values, and heat is in order if you cap the Gate.

 

JC 

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

Post #1 needs considerable rewriting to explain the problem, it makes almost zero sense.

 

Edmo117 wrote:
Unfortunately I cannot publish the schematic for NDA reasons

But you can redraw it, even a pen & paper sketch will help.

 


EDIT Due to overlapping posts:

DocJC wrote:

The BT is then --> partially <-- powered up via its RxData signal line.

The OP says he connected PWR & GND only. I'm struggling to believe any of this. Unless he's soldered the MOSFET back to front; swapping source & drain.

 

Last Edited: Sat. Nov 9, 2019 - 05:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Edmo117 wrote:
The power is supplied by a Li-Po Battery (3.7v) into an MCP1700-3.3v regulator that has 1uF on its inpit and output very close to the regulator.
X5R was changed to X7R in Feb'07.

C = Q/V isn't constant for MLCC (C dependent on V and its temperature range) (X5, X7, etc)

MCP1700 near maximum step load graph apparently shows an electrolytic output capacitor.

MCP1700 is low bandwidth (low quiescent current); stability is dependent on the capacitors and source's impedance (ESR, ESL)

Most regulators are conditionally stable.

fyi, Bluetooth 2 and 3 are practical step loads which are a likely match for that Li-Po cell; Bluetooth 4 and subsequent can be powered from coin cell(s) (the MCP1700 source ESR limit will be a concern)

Edmo117 wrote:
With the BlueTooth module connected (power and GND only) it freezes on switch on even though the module supply FET is off.
Consider the FET's body diode as per your thought in your next sentence.

Edmo117 wrote:
Since it works OK with the module connected to the 3.3v directly I can "fix" the problem by fitting a 0.1uF cap between the gate of the FET and GND so that at the instant of switch on, ...
Similar issue with the Pololu AVR ISP v2 (P-FET); the solution was a load switch to replace the P-FET.

Some load switches have a capacitor for timing the slow start.

 


MCP1700 - Linear Regulators

MCP1700 Low Quiescent Current LDO Data Sheet

[page 8, bottom]

FIGURE 2-15: Power Supply Ripple Rejection vs. Frequency (VR = 2.8V).

[page 9, bottom]

FIGURE 2-21: Dynamic Load Step (VR = 2.8V).

AVR have BOR and BOD (minimum VDD to exit reset, minimum VDD to start per VDD vs frequency)

Pololu - New product: Pololu USB AVR Programmer v2.1

 

edit :

Power Switches – Load Switches Products - Microchip Technology Inc

[Soft Start column, 2.7ms down to 60microsec]

[Max switch current, 1A to 7A]

MIC94300 - Linear Regulators (Micrel nee Microchip Ripple Blocker™ load switch with a LPF to the pass NFET's gate, 200mA, 20microsec soft start)

 

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

Last Edited: Sat. Nov 9, 2019 - 08:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

+1

Letting the smoke out since 1978

 

 

 

 

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

big caps

 

Your "fix" of adding the cap to the gate is not a fix, it is almost standard procedure!  It is called inrush limiting & very common.

Especially if you have modern ceramic caps  lurking...they have such low ESR, that they can pack a HUGE surge demand on whatever is charging them up.

The old ,small,  electrolytics were much less of an issue.  If you had huge electrolytics (like in a 150W stereo amp), then you'd add the inrush limiting.

 

There are some load switches (fet based) that include current limiting as part of the switch.  However, these are often for bigger steady loads (like 2 amps min).

 

I went to look for these big caps now & found I have an LCR meter hiding around back....need to make a space for it!  These big caps are about 9 inches (23cm) tall

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

Last Edited: Sun. Nov 10, 2019 - 01:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

5,312px × 2,988px, Seriously?

Letting the smoke out since 1978

 

 

 

 

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

I thought I reduced it, got the pix is lowered...remember when 1 meg was maxed out

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

Thanks, loads in good time now.

Letting the smoke out since 1978

 

 

 

 

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

Thanks to everyone for their constructive comments.

After considerable testing and scoping, I can confirm that the inrush current to the BTModule is the cause of the latching up issue.  I can cure it in 3 different ways......1) A small 100nF cap on the gate of the FET to stop it switching so quickly....2) a 10uF cap directly on the source of the FET to provide the pulse of current needed and finally 3) increasing the size of the smoothing capacitor directly on the ATMEGA328p from 1uF to 10uF.

 

Having solved the problem, or at least preventing it from freezing the ATMEGA, I am still at a loss to know what state the ATMEGA is in when it hangs up and will not reset even with a hard reset applied.  The voltage at this time is stable and the clock is running fine so why will it not reset?

 

Any suggestions - most welcome.

 

Edmo117

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

if the regulator does not have the required capacitance, it may oscillate and cause the AVR to latch up. Refer post #8. The choice of capacitor and layout can be critical. The AVR should have 100nF close to it. The 10uF should be for the regulator. Two different requirements.

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

Edmo117 wrote:
I can confirm that the inrush current to the BTModule is the cause of the latching up issue

I could have told you that back in #7 but you told us the Bluetooth power was OFF so I discounted that particular fault mode.

 

[Just don't ask how I wasn't surprised about Bluetooth Module inrush current blush; and also don't ask how I solved it. devil]

 

Last Edited: Wed. Nov 13, 2019 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman

 

Thanks for the feedback but I have looked at the supply line and it is clean - no oscillation at all.  I have used 1uF on the input and output of 1700-3.3v regulators on many other applications with no problem at all.

 

Given the supply is clean can you suggest what mode the CPU is in when it hangs and cannot be reset?

 

Mr Winterbottom - you can't just leave me hanging like the CPU !! How did you solve your issue??

Edmo117

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

Edmo117 wrote:
The voltage at this time is stable and the clock is running fine so why will it not reset?

  • VCC > BODLEVEL?
  • VCC : SRON within limits?
  • VCC within SOA?
  • crystal oscillator errata
  • "... the latching up issue." - a reset will not clear a CMOS latch-up

Some external watchdogs will power cycle the MCU in-lieu of resetting the MCU.

Voltage regulators can have a current limit such that the MCU is not destroyed by a CMOS latch-up.

 

ATmega48A, ATmega48PA, ATmega88A, ATmega88PA, ATmega168A, ATmega1688PA, ATmega328, ATmega328P datasheet (pages 312, 314, 654)

via ATmega328P - 8-bit AVR Microcontrollers

AN-600 Understanding Latch-Up in Advanced CMOS Logic (ON Semiconductor)

Latch-up is typically by injection current (AVR have an injection current limit) though

Application Note 339 Fairchild's Process Enhancements Eliminate the CMOS SCR Latch-Up Problem In 74HC Logic (ON Semiconductor)

[page 5, right column]

OTHER LATCH UP TRIGGER METHODS

...

Another latch up mechanism is the application of a fast rise or fall spike to the supply inputs of a CMOS device.

...

 

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

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

Vcc is 3.3v and BOD level is 2.7v 

 

Vcc is 3.3v which is well within SOA for 8MHz use with crystal.

 

I have the older die not latest version K so Osc errata does not apply I think.

 

The latch up is non destructive and can be recovered by cycling the power.

 

Reading those documents I think the most likely cause is a spike on the supply line although I cannot see one with my 100MHz scope.

 

Thanks for the comments they certainly make you think.

 

Edmo117

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

Edmo117 wrote:
...  I think the most likely cause is a spike on the supply line ...
Is there more than one way?

(so far, the Bluetooth module)

Injection current through the MCU will increase or decrease VCC relative to GND making latch-up more likely; recommend reviewing the design wrt ESD and EOS.

MCU's ESD suppressors will have current (injection) due to EMI though Bluetooth's ERP may be low enough not to be such an issue.

Edmo117 wrote:
... although I cannot see one with my 100MHz scope.
Scope's dwell time, and your patience, will limit the data (waveforms/second after samples/second)

Some scopes have differentiation and pass/fail so can monitor during testing.

The bandwidth of inexpensive USB scopes is enough for this case and may be a match for the bandwidth of fast LDO error amplifiers (1 MHz); these sample into PC RAM (zero dwell)

 

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

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

Edmo117 wrote:
Mr Winterbottom - you can't just leave me hanging like the CPU !! How did you solve your issue??

Oh OK. But the rest of the freaks will be horrified.

 

  • I was switching the supply to my Bluetooth module with a microcontroller pin to gate of a p-channel mosfet.
  • The module had a large ceramic on its Vdd for bypassing its own internal LDO.
  • This capacitor was of same order of magnitude as my own 3VD rail capacitance.
  • You may know that modern ceramic multilayer caps have very low ESR (a few milliohm at most).
  • The side-effect then of powering up the Bluetooth module was to effectively double the bypass capacitance on my 3VD rail.
  • My boost converter was of course too slow to cope with this transient and the rail voltage almost halved instantly.
  • The microcontroller then crashed (and subsequently reset).

 

I was looking for a software solution and even a single cycle toggle of the mosfet gate still caused a crash.

The only thing I could do was to:

  1. Leave the mosfet off but turn on UART_TX, and UART_RTS as output highs.
  2. Leave them high for about 1s to allow the capacitors on the module to pre-charge via the I/O lines.
  3. Drop UART_TX, and UART_RTS to output lows to avoid latchup (as gchapman linked) then turn on the mosfet.
  4. Continue with normal module initialisation.

 

Despite the horrendousness of this activity it was 100% reliable.

 

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

That sounds OK to me. Sometime you have to do things that do not necessarily obey conversation. My situation was almost identical to yours but I was unable to reset my Microcontroller.
Anyway, thanks for the heads up.

Good luck to all and thanks for the comments

Edmo117

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

Just because something worked before, doesn’t mean it will work in different circumstances!
If it is a regulator issue, the you can disconnect the data pins to the bt module and simply switch the power to see if the issue remains. In order to trigger the scope just before the event, use another port pin for the trigger and have your code change its level just before you enable the mosfet. The oscillation may be a very short event. Also consider pcb track inductance - ground bounce.
Substitute the bt module with an equivalent amount of capacitance the module presents on its power input. Does the problem remain? Look to identify the mechanism that is causing the problem. Once identified, you can then look to resolve the issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  1. Leave the mosfet off but turn on UART_TX, and UART_RTS as output highs.
  2. Leave them high for about 1s to allow the capacitors on the module to pre-charge via the I/O lines.

That's a clever trick. You could put an RC on the mosfet gate to ramp up the turn on (limit the inrush)...Of course, that is a bunch of nonlinear things (such as Vgs vs conduction) happening, blended together.

Your trick reminds me of anti-counterfeiting...someone can build a clone of the circuit, but can't make it work without the "secret".  I've seen other boards that had "secrets" purposely designed in, but don't recall what those boards were.    

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