[solved] brown-out module running berserk ?

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

I'm using an ATtiny24 (8MHz, internal RC oscillator, 5V) to control a LED driver, essentially an 8-bit shift register with internal current control. Total current is about 1.5A.

I've added decoupling capacitors close to the mcu. I started with 100nF and just a couple of µF and ended with several 1000 + an inductor to keep high frequency stuff away. The brown-out voltage is set to 2.7V. Sometimes adding 220µF causes the chip to do repetitive resets.

On my scope I can see some noise on the supply lines, but nothing that would dip down to anywhere near of 2.7V, the worst spike I could see was 500mV. According to the datasheet the BOR module kicks in after about 5µs below the limit, nothing about dV/dt activation (which could explain the bahaviour I see). I should add that my scope is pretty old and it's likely that I miss short glitches. Even worse in storage mode.

The only way to make it work properly is to disable the brown-out reset completely. After that it works just fine.

The same setup (LED driver + load) works with a different 'dev-board' (ATtiny4313 + active BOR @ 2.7V), which doesn't have any fancy supply line filtering either.

Broken BOR module or chi imbalance ?

Last Edited: Fri. Apr 22, 2011 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since it looks as a board specific more than software, more details would be needed. Register clock frequency, current control method and scope bandwidth in particular.
For a short test just leave GND single point connection to high current part and supply 5V to the MCU from separate source. Regulated one would be at a hand, since it could make possible checking BOR triggering. If this works and BOR performs correctly, there must be an issue in supply lines and routing.

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

The scope's analog bandwidth is just 10MHz. Or it was 35 years ago (Tektronix 314). That's why I'm very likely to miss fast and aperiodic dips.

As the LED driver (MBI5168) doesn't need an inductor, it must be a linear regulator. The datasheet doesn't tell, but as it tends to get quite warm it is likely. The driver chip is fed with data (via USI-SPI, about 700kHz clock) to produce a low frequency PWM signal on the outputs of about 244Hz.

I had already tested using 2 supplies, but it's still unreliable. The best improvement was adding the inductor (33µH) on the Vcc pin.

The ATtiny24's BOR module appears to work correctly when I hook it up to my power supply (linear, with fat output caps) and nothing else. It reliably triggers at 2.7V-ish, as set by the fuses.

I'll build another prototype. Maybe the wires are cursed or something.

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

For test just split Vcc and GND wires from proto board and driver (assuming these are separate units). Connect these together only at PSU terminals. Make wires thick and possibly short. Take care about unused mcu pins.

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

IF you have bad ground/power layout topology your high current pulses can easily create short high energy dips in the VCC or ground bounce that will trigger the BOD circuitry.

I do a lot of LED driver designs with compact boards that contain tiny85/led driver circuitry. Partitioning the power between the uC and LED driver cores requires thinking about current paths. Sprinkling capacitors (especially large value ones) incorrectly can cause more problems that they solve - e.g. the ground of a cap connected to the switcher core end of a ground plane versus the uC ground pin can introduce ground bounce induced spikes on the VCC rail. Been there & done that...

Anyhow, as others have written, start by isolating the ground/Vcc domains between the uC and LED driver core and be careful where the uC bypass caps connect.

cheers,
george.

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

I'll look into that some more.

Thanks.

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

Solved. The real thing works perfectly. The main difference between the prototype and the final board is an additional voltage regulator + caps for the 'brain' and a much higher input voltage for the LED driver section. The power carrying traces are much wider as well.