标签: bor

In a recent blog, I recommended against using the brown-out reset (BOR) circuit found on many MCUs. My argument was that BOR’s often have a wide tolerance range, which means one could give up nearly all of a coin cell’s capacity. For instance, some are rated as triggering a reset at some nominal voltage, but the tolerance bands are 2.05 to 2.35 volts. Worst case design means assuming it’ll fire at 2.35, which, with a decent load on the battery, means it may initiate a reset when there’s 90% or more of the battery’s capacity left.   Further, some BOR circuits use quite a bit of juice, in some cases too much to support years of (mostly sleeping) operation off a coin cell.   I suggested, instead, waking up once in a while and reading Vdd with an A/D, and did write that the load during this measurement must reflect the real, expected load while awake. I still think this is good advice. However, in some situations this solution might be impossible to implement.   The nice folks at Microchip called to explain some of the scenarios they see their customers experiencing. One I hadn’t considered is writing to flash memory. This can suck some serious coulombs; on their PIC18LF46K22 writes can take 10 mA for around 6 ms/block (not an unusual number; TI’s MSP430F2013 needs 7 mA during flash erase). As the battery is slowly depleted its internal resistance may be low enough to run code, but so high that Vdd will drop below the minimum allowed during the flash write. The result: who knows? With Vdd below the minimum the CPU needs, any internal register, like the program counter, could become corrupt.   Why not use the A/D to check Vdd during the flash write? Well, on some MCUs that’s quite impossible, since all instruction execution is suspended during the write.   Perhaps it makes sense to turn the BOR on only when the processor is not sleeping, and let it issue a reset when writing to flash if the battery just isn’t able to power the system properly. However, if the BOR goes off at 2.35 volts, and flash writes eat 10 mA, then, assuming no other significant loads during the write, the BOR will signal battery failure when around 160 mAh have been consumed. That is, about 30% of the battery’s capacity will be wasted.   Newer parts, though, have better specs. Microchip’s PIC16LF170X series spec a very tight range of BOR voltages. The numbers are a function of temperature and selected mode, so are too complicated to list here. However, the BOR uncertainty is generally better than 0.1 V, and is well documented. In this case enabling BOR during awake times does make sense.   Interestingly, and unusually, the PIC16LF170X datasheets explain the meaning of max, min and typ for each parameter. For instance, on a graph for the BOR voltage max is listed as “typ+3σ,” which of course means typical is max-3σ. This is the first time I have ever seen these important parameters defined. Bravo Microchip!     Some systems need more than 10 mA when awake; wireless comm can eat tens of mA. In that case turning on the communications logic will drop Vdd more than a flash write does. If comm is a requirement, then using the A/D to measure the battery’s condition with the comm on will also Ensure flash writes will be safe.   Do remember, though, that the cutoff point is when the loaded Vdd is approaching the MCU’s rated minimum allowable value. The battery’s internal resistance will be in the many tens to hundreds of ohms. When the load is removed the voltage will be much higher; measuring it then will give no useful information.   Absent any sort of BOR monitoring, on any MCU a flash write can drop Vdd enough to make the system run mad, even overwriting code space and bricking the device.   The bottom line is that on many MCUs you can’t use the A/D to monitor Vdd during flash writes unless there’s some way to simulate the expected load. As always, do a careful, worst case, engineering analysis.

A few readers have written about how they defend against a dying battery using a brown-out reset (BOR) circuit, a feature pretty much every low-power microcontroller has. Unfortunately, most are poorly designed and/or lightly documented and should not be used. One popular ultra-low power MCU, from a vendor who noisily advertises two to three decades of coin cell operation, has a BOR which is off by default. On, it requires somewhere between 8 (typical) and 16 uA (worst case). Remember that, for a decade of life from a CR2032, the system’s average power draw cannot exceed 2.5 uA. Even if one were to foolishly use the typical number, the BOR by itself will deplete the battery in just a couple of years. Another vendor, pushing extremely-low power ARM parts, rates the BOR at 0.49 to 1.26 uA – typical. There’s no max listed; there’s not the slightest guidance of what statistical distribution one can expect when making thousands of systems. 1,26 uA eats half the 2.5 uA budget. In another case the datasheet reads about the BOR: “In the deeper sleep modes, this will contribute significantly to the total current consumption.” As Deming said: “In God we trust, all others bring data.” They didn’t, and it strikes me as risky to expect divine intervention instead of doing careful analysis. I’d be wary of using these uncharacterized parts in long-lived applications. As always, read the datasheets pessimistically and carefully. When does the BOR interrupt occur? In some cases the voltage range is very wide; an example is an MCU where it is listed as 2.05 (min), 2.2 (typ), and 2.35 volts (max). Doing worst-case design you’d have to assume that the BOR may occur at 2.35 volts. The following graph is one I have used before; it shows the voltage a CR2032 can deliver as it discharges as a function of load. The 10 mA load line is pretty common for an awake MCU with enabled peripherals; 30 mA is not unexpected if there’s any sort of wireless comm going on. The heavy red line is at 2.35 volts, the max value where we may see a BOR interrupt. Note that in this case the BOR circuit will signal a dead battery, if there’s a 30 mA load, shortly after you ship the product. With a 10 mA load the battery-dead indication happens when there’s still 31% capacity left.   In other words, the BOR circuit is useless. A much better alternative is to leave the BOR off and use the A/D. Wake up from time to time, apply a load similar to what the system normally needs when awake, and read Vcc. If it’s near 2.0, then signal a battery failure (or take whatever action your system needs in this situation). If such a reading is taken once every ten hours (surely, more often than needed), and 10 mA were pulled for 1 ms, over a decade this eats only 0.03 mAh, or 0.01% of a CR2032’s capacity. And, by manually reading the A/D a more nuanced approach to battery management is possible than by relying on a single, poorly-controlled, BOR voltage.

BOR功能 是STM32L系列特有的复位和启动电压调整功能。 BOR 关闭时STM32L的供电范围是 1.65 V to 3.6 V， BOR 关闭时STM32L的供电范围是 1.8 V to 3.6 V ，BOR 共有5个级别，依次是 OB_BOR_LEVEL1  /*! BOR Reset threshold levels for 1.7V - 1.8V VDD power supply */  OB_BOR_LEVEL2  /*! BOR Reset threshold levels for 1.9V - 2.0V VDD power supply */ OB_BOR_LEVEL3  /*! BOR Reset threshold levels for 2.3V - 2.4V VDD power supply */ OB_BOR_LEVEL4  /*! BOR Reset threshold levels for 2.55V - 2.65V VDD power supply */ OB_BOR_LEVEL5  /*! BOR Reset threshold levels for 2.8V - 2.9V VDD power supply */   以下是BOR功能演示   /* Get BOR Option Bytes */   BOROptionBytes = FLASH_OB_GetBOR();      #ifdef BOR_MODIFY   if((BOROptionBytes 0x0F) != BOR_LEVEL)    {     /* Unlocks the option bytes block access */     FLASH_OB_Unlock();       /* Clears the FLASH pending flags */     FLASH_ClearFlag(FLASH_FLAG_EOP|FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR                   | FLASH_FLAG_SIZERR | FLASH_FLAG_OPTVERR);       /* Select the desired V(BOR) Level ---------------------------------------*/     FLASH_OB_BORConfig(BOR_LEVEL);        /* Launch the option byte loading */     FLASH_OB_Launch();     }