Closed h4mp3l closed 6 years ago
You may search thru esp32.com forum to find more about power consumption when you are using BLE and/or wifi device and reasons why brownout is triggered. It may be caused by poor quality usb cable, bad solder joints or low power from USB connector. If you can monitor voltage on esp32 during startup then you may have some clue
My experience in this areas is poor ... however, reading the forum recommended by @chegewara (https://esp32.com/index.php) has seemed to show that the brownout problem is hardware related and not software related. From the trace logs that you supplied, we don't seem to see any startup of the application.
Do other applications work on this module? Do you have other modules (ideally some pre-build boards) that work or exhibit the same problems?
One possible reason why the BLE application is showing a problem but other applications may not is that in the BLE application you enabled the ESP32 BLE subsystem. This may cause a higher power draw at the start. Another possibility is that including BLE increases the size of the application meaning more code may be moved from flash to RAM prior to execution ... which might mean a longer/higher draw at startup.
I'd suggest having a detailed study of the forum and testing on other boards to see if it is limited to just one board/module.
Thanks for the heads up guys!
I tried some other examples but those using wifi and ble are triggering brownout right at the init stage. Other programs work fine though. I couldn't see any voltage drops while measuring with the multimeter, but tbh that was a cheap-a-f 20€ one. I guess the multimeter is too slow to register any change in this time...
Do you think a ceramic cap between vdd and gnd may do anything? I still have some at home atm.
Anyways I'll try to buy another preassambled one, maybe i messed up the soldering part (although it keeps wondering me why other stuff is working then)
I'll give an update on that asap
Yes, you can try with some capacitator. I recolect that espressif admins advised something like that on forum. Why other programs works fine and those with wifi and bt dont? Just like @nkolban said, wifi and bt during startup draw more current and this causes brownouts.
Closing for just now.
I had this same error message when trying to use OTA-Uploading over the Arduino IDE. I was able to avoid the issue by delaying the execution of some parts of my code that I deemed to be power hungry for short periods of time. Whilst I do not regard this to be a real solution it might be a temporary workaround.
Edit: Whenever this particular code was being executed I saw my screen's back light flicker. This is a clear indication of power supply issues. I have the screen hooked up to the 3.3V Pin of the ESP32-Dev Board, clearly not the ideal solution.
I hav the same "Brownout was triggered" problem with my freshly installed DOIT ESP32 DEVKIT V1 board using a"SimpleTime" sketch from the "Example" directory. It made 98 times "Brownout..." than start to work normally. I observed that the problem happened when "WiFi.begin(ssid, password); was launched. It is similar to BLE because this use radio transmitting also. Now it work normally since about more than 60 minutes. What do you think about it?
In my case switching to USB2 port solved the issue.
When I turn it OFF and than ON the problem repeated. Finally I soldered a 100nF ceramic capacitor on the 3,3V output of the regulator IC on the DEVKIT and since that it works well.
I finally got it working by increased the power supply to 3.93V and 0.730A. With it running averaging at 0.94AM after connected to wifi. It only measure 3.69V at the chip pins after going through 2 jumper wires and the breadboard power rails after dropping 0.24. The jumper each measured 1ohm. Breadboard 0.5 board. That's 2.5ohm x 0.100A = 0.25V. It won't have matter with higher power chips like 5V but at low power chips like 3.3 even voltage drops across jumpers become a problem! I'm using the ESP32F bare chip with pin breakout adapter.
I had to put 7.0V on Vin of my DOIT Devkit v1 to stop the constant brownouts/resets. Either this or combining the regular 5.0V on Vin plus USB-connection.
@royassas an others this suggests that you don't / might not have sufficient bypass capacitance ;) I'd recommend to put maybe 100 to 470µF in series with the Vin Pin. Alternatively / additionally you could add another capacitor in series with the 3.3V line on the regulated output. It might be advisable to add several capacitors, one bigger "bulk" cap and one smaller ceramic cap for quick current spikes. Please see this excellent video(s): General explanation: https://youtu.be/BcJ6UdDx1vg Demonstration: https://youtu.be/1xicZF9glH0
Do I understand this correct: having the bypass caps in series will give the power-input fast acting reservoirs to pull their Amps, so voltage won't drop as much? So i might get away with lowering my input voltage back down to 5v?
@royassas exactly. Having a lower input voltage is not only more practical, it does increase the efficiency of you whole set-up too.
I have the same problem. I found that solution in a forum :
void setup(){ WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0); //disable brownout detector
Just to confirm, that a bad USB cable is a possible root cause. Just had the case, used an usb cable of about 60 cm, could easily flash the program but crashed with a brownout at wifi startup. Changing the USB cable made the problem disappear. So there are a lot of USB cables on the market with an internal resistance which is just too high.
Disabling the brownout detector didn't change my situation. As suggested elsewhere I think there are other things happening which cause the brownout error. Adding bypass caps in different sizes up to 2000uF only brought the voltage needed down to 6.6V.
@vortex using the USB cable in parallel to my power source actually solves my problems. Using only the USB cable results in brownout errors.
I changed new ic AMS1117 3.3v, and the current did not drop now.
@h4mp3l, I had the same problem and the solution was not in voltage regulation. I had a little bug concerning wrong usage of extern and static keyword. Compiler did not say anything about it but when I founded what was wrong the 'Brownout detector was triggered' disappeared
that sounds like a bug. Would you mind filing that as an issue on Github?
Wrt your specific problem: I'm not sure if disabling the brownout detector is what you want here. Usually, if the brownout detector is disabled in situations like this, you instead get an ESP32 that crashes horribly. Maybe you're better off getting a more powerful boost converter (we advise a power supply that can deliver at least 500mA) or as a hack add a bunch of capacitance to the 3.3V line.
Wrt 'soft start': We are actually thinking of something like that, but I'm not sure if and how soon it'll end up in esp-idf.
Aconteceu-me o mesmo com o NodeMCU ESP32.
Problema ultrapassado: Utilizar uma boa fonte de 5v / 500mA. A linha de 3.3v fica estável.
Another solution: I use an ESP32 Doit Board. By replacing the small diode on the USB input I could successfully fix this problem. (red) Use a Schottky Diode with a low voltage drop! Extra capacitance is good, too (yellow). I re-soldered all ESPP32 Pins, just in case (blue).
Just for brevity I had the same problem just a moment ago with MH-ET DevKit, in my case it seemed that the USB hub (passive) I've been using was the culprit... So it seems that @rezaajdarkosh suggestion is correct make sure input can provide 500mA, my hub provided less it seems.
I have faced the same, then I figure-out its cable fault. The power supply is not proper. Change the cable try.
I have faced the same, then I figure-out its cable fault. The power supply is not proper. Change the cable try.
exactly same case here.
I have faced the same, then I figure-out its cable fault. The power supply is not proper. Change the cable try.
exactly same case here.
I have faced the same, then I figure-out its cable fault. The power supply is not proper. Change the cable try.
exactly same case here.
Mine too. changing USB port solving the problem. USB2->USB3. must be something with power supply
I got a similar issue and fixed it by bypassing the diode protecting the USB power supply from external 5V supply. I've got a board similar to this https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf D3 causes a voltage drop of 0.5V, so I removed this diode, and problem is solved :)
This error raised in my project when I used to long USB cable (with extension cord). It disappeared when I change USB port.
I got a similar issue and fixed it by bypassing the diode protecting the USB power supply from external 5V supply. I've got a board similar to this https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf D3 causes a voltage drop of 0.5V, so I removed this diode, and problem is solved :)
This also solved the issue for me. This seems like a serious flaw in the dev board design.
active USB hub with solid 2,5A minimum 5V powersupply solved this. And when deployed , board are powered by polulu stepdown regulators with 3A output, and the wifi works.
I had similar problem with "Brownout detector was triggered" error. And after some examination I've found the problem. I used USB extension cable and it caused lower voltage of power supply. When I plugged the cable directly to USB charger it started to work. Hopefully it would help to someone.
Hi all, I am trying to work with ESP32-CAM (https://robotzero.one/esp32-camera-module/#comment-3073) i can able to take a still with the camera but face detection and face reorganization is not happening, Do any one know for what reason it is not happening.please help me out to solve this issue.
dhcps: send_offer>>udp_sendto result 0 I (63186) camera_httpd: JPG: 6335B 1573ms I (66456) camera_httpd: vflip = 1 dhcps: send_offer>>udp_sendto result 0 I (72716) camera_httpd: JPG: 7267B 118ms I (78976) camera_httpd: face_detect = 1 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 I (1752586) wifi: max connection, deauth! dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 I (1873156) wifi: max connection, deauth! dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 I (2301736) wifi: station: b4:ef:fa:79:e6:e2 leave, AID = 1, bss_flags is 134243 I (2301736) wifi: new:<6,0>, old:<6,2>, ap:<6,2>, sta:<6,0>, prof:6 I (2301736) camera wifi: station:b4:ef:fa:79:e6:e2leave, AID=1 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_offer>>udp_sendto result 0 dhcps: send_nak>>udp_sendto result 0
thanks in advance
iam trying using vision kit while using other demos i get this error even i stopped joy_detection but also i get this error so can anyone suggest me how to correct this.
LoadModel: Cannot load model during processing.
Traceback (most recent call last):
File "./face_detection_camera.py", line 78, in
Just had this on an ESP32 Mini. Switching from USB port power to a dedicated charger resolved it.
For me it was the cable, thought it might have been the frequency also but after testing 4 cables looks like the one that looked cheap was cheap :) All good not using quality USB cables.
I have ran into the Brownout issue on 2 of my Wemos mini D1 esp32's when enabling the BLE. I have discovered that this maybe because these are not genuine LOLIN boards and use a 150mA 4B2x voltage regulator instead of the 500mA S2RC regulator on the genuine boards. I have also used the D1 lithium battery module in the D1 circuit stack that should have no problem delivery the required current while the BLE is enabled , but the brownout still happens. Unfortunately i can't get hold of the S2RC regulator to swap the 4B2x off my boards to confirm this is the cause and i can't find a substitute 500mA regulator that has the same pin configuration to use instead . But i am in the process of confirming with sellers they will send me a genuine LOLIN D1 ESP32 with the S2RC reg fitted to confirm if the problem actually is due to 150mA reg fitted to a lot of boards.
UPDATE: 10/02/2020 Found S2RC regulators listed as ME6211C33M5G Power Supply Management 3.3V SOT 23-5 on ebay. So waiting for them to arrive to swap with the 4B2x on my fake boards
[Edited to correct previous comments]
No combination of cables and power supplies solved the problem for me. I always see a brownout after the message: *WM: [1] AutoConnect
.
This is on a "clone" Mini D1 esp32 (like @Andy1968T). What's odd is that I get the brownout, the ESP32 reboots, and then it works fine for days with no further brownouts. This is 100% repeatable. Boot -> brownout -> restart -> works fine. A 1000uf cap between 3.3 and ground seems to alleviate the problem.
Hi All, Jpasqua's reply has prompted me to update the situation regarding my D1 esp32's . The new 500mA S2RC arrived a while back and so I have now replaced the 150mA 4B2x with the new 500mA S2RC on two of my boards. And can confirm this has solved the problem of brownouts when enabling WIfi BLE on the Wemos(fake) Desp32's. This was a good outcome. However it does require a hot solder heat gun to perform the task. and microscope. This solved the brown out issue. I also then removed the red power LED to save power, because my project requires long battery life and long sleep times.
Thank you for the update @Andy1968T. It's good to know that having a proper voltage regulator does the trick. Have you find a reliable source for D1 ESP32's which have an S2RC or equivalent? I'd prefer not to have to do surgery on every board.
Sorry no I did not look for a reliable source for D1's. I only purchase them for specific low power small footprint projects anyway. And there are better Esp32 modules out there for most other projects. As I have the equipment and spare 500mA regulators that make it more cost effective to just replace the voltage regulators when required. And I suspect that it will be difficult to guarantee what I will get each time I order even from the same seller. I think Wemos should get these fake ones taken off the market or get genuine sellers to make themselves know as to be selling genuine D1's with 500mA, as this is harming the trade for Wemos.
@jpasqua @Andy1968T I’d be more than happy if someone uploaded an “upgraded” d1 mini esp32 to https://www.pcbway.com/project/ (or somewhere else I’m not aware of) so that I could order them direct with assembly for a reasonable price and great shipping.
And, while we’re on the subject: also with the circuitry to be able to have the board powered from 5v on vcc
For me it was a matter of switching the FT232 to 5v and connecting it to the 5v on the camera module.... Then I got "Camera Ready!" Hoe it works for some of you.
I've been trying to fix an issue where the brownout detector is randomly triggered from deep sleep and have tried this code that I've seen at several sources for Arduino, and was suggested earlier in this thread. `#include "soc/soc.h"
void setup(){ WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0); //disable brownout detector` However, this causes the brownout detector to be triggered constantly.
I've been trying to fix an issue where the brownout detector is randomly triggered from deep sleep and have tried this code that I've seen at several sources for Arduino, and was suggested earlier in this thread.
#include "soc/soc.h" #include "soc/rtc_cntl_reg.h" void setup(){ WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0); //disable brownout detector
However, this causes the brownout detector to be triggered constantly.
I did this and now I receive
[E][camera.c:1113] camera_probe(): Detected camera not supported. [E][camera.c:1379] esp_camera_init(): Camera probe failed with error 0x20004
I had the exact same problem when enabling bluetooth, I found out it was a junk usb cable, chipsce brand, I used a usb cable from my smartphone and everything runs perfectly. I tested it on 4 ESP32 and 4 junk cables, I was sure it's the brand of the cable. :)
Brownout detector was triggered
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:812 load:0x40078000,len:0 load:0x40078000,len:10212 entry 0x40078a00
Brownout detector was triggered
When I was trying to get a BLE Server to work i always get this message, I've also read in other forums and an other issue in this repo that power consumption might be the issue, but even a powered USB hub didn't do it...
I used your BLE sources from your esp_snippets repo, is the Arduino_BLE the more recent one?
Do you have a clue what could be the issue? I'm also guessing solder joints as I soldered the chip on the dev base board myself (which is quite tricky considering the pin distance of the wroom) but an example using Serial works fine so I'm not quite sure....
Kind regards