Brown out after Jaguar update
# help
k
Chip is ESP32-D0WDQ6-V3 (revision v3.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz After jaguar update (from V ~1.13 to 1.18) the device reports brown out instead of deep sleep. (ESP-RST-BROWNOUT ::= 9 // Brownout reset (software or hardware). ----- Version: v1.12.0 SDK version: v2.0.0-alpha.99 Build date: 2023-09-07T13:53:42Z runs properly ----- Any suggestions ?
k
Are you sure the device is getting enough power? Do you have any way of measuring that?
k
yes, it works in the same condition with V1.12
f
Can you provide a bit more context? From what I understand: - you call deep sleep, but - the device wakes up and claims that it experienced a brownout, instead of a regular deep-sleep). Correct?
We had the brownout detector disabled in earlier versions. It was enabled in https://github.com/toitlang/toit/pull/1795 (September 6)
I'm guessing Jaguar 1.13 was released before then.
To me this looks like the ESP32 is indeed detecting a brownout, and we just didn't report it before. There are some boards that are known to have brownout issues. Could you tell us which board you use? Independently: if you want to continue running without brownout detection, we (or you) can create an envelope that has that feature disabled. The https://github.com/toitlang/envelopes repository has multiple variants, and is designed to be forked. Iirc we finished the work in Jaguar to fetch envelopes from custom forked envelope repositories.
k
Board: ESP32 D1 mini (WROOM)
f
Wemos?
k
with Jag V1.12 the device wakeup code 08 with newer V device wakep code 09 (brown out)
f
The brownout detector was disabled a few releases ago.
Is it an az-delivery board?
I remember those had a regulator that wasn't strong enough
f
Maybe see if you can figure out which regulator is on that board.
k
- onboard regulator removed - replaced with external regulator - updated to V1.18
- application runs without problems (brown outs)
Thank you for the right hint !
f
Nice. Removing the regulator is not something a lot of people would be able to do.
max 300 mA
(they had it in mind already at design time 😂 )
f
From what I can find online, 300mA might not be enough.
That said, I think these are peaks. So a capacitor should help a lot.
k
f
I'm not an expert in these, but I think that should work. It's probably even overpowered.
r
In v2.0.0-alpha.117 with jaguar v1.17.0 i've also started to see brown outs.
No changes to hardware, and ive never seen it before updating
But as far as i can see, it only happens in our power on/off test of the device.
b
In my product I have a 500mA continuous switchmode reg, is 500mA enough? I have lot's of capacitance on the output .. just wondering, as every 3 or 4 days get an unexplained reset.
f
The
esp32.reset-reason
should give you the cause of the reset. One of them is
ESP-RST-BROWNOUT
.
b
@floitsch Hi, is that stored in flash for retrieval later? Would it be possible to retrieve that off a clients machine somehow?
f
You can retrieve the reset reason anytime. It's stored by the system.
The easiest is probably to just have a program that has a boot-trigger and then just looks at the value.
You can also just use
artemis device container install
to temporary install that program and have a look at the reset reason.
b
@floitsch I wish it was that easy. This is a remote system, I can't get to the serial. And can't duplicate it on my local machine.
f
In my example I print the reset reason, but you can just upload it to somewhere. I would install a simple container that is triggered at boot and which uploads the reason. You could always store it in flash (maybe using Artemis channels) if you don't want to go online too often
b
@floitsch Thanks. When you say "upload" do you mean by FTP or some other protocol? Do you have any examples?
f
Really depends on your setup. You can send it via telegram, to supabase, to Google spreadsheet, mqtt to adafruit or the mosquitto test server... If you look at the tutorial section of docs.toit.io you find tutorials for all of them there
b
Thanks @floitsch I used google sheets method, works great 🙂
@floitsch Interesting thing. On my local machine I uploaded the container on my running system with boot,install flags and I logged a reset reason of 3 (ESP-RST-SW) as expected. I did the same to a remote machine, but this time got a returned reset reason of 1 (ESP-RST-POWERON) Do you have any idea why that could be?
f
That's indeed curious. POWERON should only happen after a power-cut, or when the chip was reset (either with the reset button or through the UART; and the UART reset can be avoided by
jag monitor --attach
). I googled a bit, but couldn't find any lead that looked promising.