Brownout reset problem.

[reddomon]

Hi, i am experiencing brownout reset issues. I double check power module, use 10A 5V and even splitted esp32 from 5v and powered 5A 3V but nothing changes. When homing, randomly brownout reset occurs but when printing begins prints perfectly and no brownout reset. PS I added directly a 100uf cap on esp32 module power pins.

[vivian-ng]

@reddomon Are you sure it is brownout reset? Maybe connect the board to a computer, and see what the serial output is.

I had random resets when homing before, turned out it was noise from the endstops that triggered the EN pin. Added a capacitor between the EN pin and GND and it helped to get rid of the resets.

[reddomon]

Thanks for your reply. Yeap I am pretty sure. Serial output says it is brownout reset. I will give a try with your suggestion. But if it was noise, why serial output says brownout reset.? :(

[reddomon]

I tried many things but did not solve my problem. added a cap between EN and GND pin that @vivian-ng suggested bu it did not work.added 100uf ceramic cap didint work, 100nf didbnot work, seperate 3.3 v powersupply did not work, seperate 5v powersupply did not work. I even soldered directly to esp32 module 100uf and 100nf caps bu it did not work either. I lost my mind.

[Aggebitter]

@reddomon BOR in my experience happens often when WiFi gets enabled (300-400mA current peak).

If you can connect an Oscilloscope at the 3.3V rail. check the voltage when homing.
Is there any drop in voltage on the 3.3V rail ?
Is there a drop in voltage when end stops are activated ?

A fast Multimeter might catch a voltage drop as well but often the voltage drop is very short.

An other issue is the internal reference voltage on some rev of ESP32.
You can test (not attached to any GPIOS) if it's an chip issue by connecting the 3.3V to a external power supply that can deliver more than 1A. Run a common WiFi sketch. If it doesn't work you might have a "bad" ESP, I had some of those. The issue is that the internal reference voltage trigger is at 1.1V +-10% below that BOR is tripped. But I'm sure that this part is not tested at factory. I always use a electrolytic cap at the 3.3 rail as an extra current buffer. but on the "bad" ones I still get BOR some times

[reddomon]

@Aggebitter Hi. Wifi is not enabled and i tried 3.3v 5A Meanwell powersupply, but did not work. When i examine with oscilloscope doesnt catch any negative spike. Tried diffrent brand esp32. I will test again for 3.3v voltage drop. I think I have a clone card,because doesnt have any namings on it.
P.S. Sometimes 3 or 4 times BOR occurs repeatedly.

[vivian-ng]

@reddomon Are you able to connect to the ESP32 via serial terminal to see what are the error messages that are thrown when brownout occurs? If there is something like a stack trace that is thrown, it would help if you can get the stack trace decoded so that we can see where the error actually occurred.

For my case, I had

Guru Meditation Error: Core  1 panic'ed (Coprocessor exception)
Core 1 register dump:
PC      : 0x400f418e  PS      : 0x00060931  A0      : 0x800f2abd  A1      : 0x3ffbe620  
A2      : 0x00000000  A3      : 0x00000001  A4      : 0x3f000000  A5      : 0x00000000  
A6      : 0x637f0000  A7      : 0xcc800000  A8      : 0x800f4188  A9      : 0x3ffc3080  
A10     : 0x00000000  A11     : 0x3ffb0060  A12     : 0x40083907  A13     : 0x3ffbe7c0  
A14     : 0x02ffffff  A15     : 0x00000000  SAR     : 0x00000020  EXCCAUSE: 0x00000004  
EXCVADDR: 0x00000000  LBEG    : 0x40002390  LEND    : 0x4000239f  LCOUNT  : 0x00000000  
Core 1 was running in ISR context:
EPC1    : 0x400f418e  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x40082a51

Backtrace: 0x400f418e:0x3ffbe620 0x400f2aba:0x3ffbe700 0x400f15a6:0x3ffbe720 0x400f1613:0x3ffbe740 0x400f509f:0x3ffbe760 0x400f50bf:0x3ffbe780 0x40080fa5:0x3ffbe7a0 0x40081859:0x3ffbe7c0 0x40083904:0x3ffb1d80 0x4008362b:0x3ffb1da0 0x4008132f:0x3ffb1dc0 0x400ee6f3:0x3ffb1de0 0x400ee9a0:0x3ffb1e00 0x400e1343:0x3ffb1e30 0x400f2bae:0x3ffb1e50 0x400f1e77:0x3ffb1e70 0x400f1f3a:0x3ffb1ed0 0x400e3295:0x3ffb1f00 0x400e4b0b:0x3ffb1f30 0x400e52ad:0x3ffb1f50 0x400e695c:0x3ffb1f70 0x400e15c5:0x3ffb1f90 0x40107529:0x3ffb1fb0 0x400884a5:0x3ffb1fd0

And it seems to suggest an error occurred in

Stepper::endstop_triggered(AxisEnum) at Marlin/src/module/stepper.cpp line 2228

You can decode the stack trace using this tool.

I suspect the issue is with how I2S handles count_position because this only seems to occur when using I2S on a coreXY setup. But we will probably need someone like @simon-jouet to advise since I am not very sure how the I2S implementation works with the ISR.

[reddomon]

I will try rightaway and add results

[vivian-ng]

@reddomon While you are testing, can you also try out this possible solution?

Basically, it seems that there is an issue with using float calculation in the endstop_triggered function. When I used / 2 instead of 0.5f *, it seems to solve the reset issue with coreXY. Just need someone else to confirm.

[reddomon]

Hi @vivian-ng I tried divide 2 instead of 0.5f is working like a charm. 250+ homing cycles tried and no more brownout reset or any other reset issues. Thank you for your effort. Se you an another problem :). By the way I am working on an nextion display controller for marlin 2+.

[misan]

A double would do just fine too.
http://fightpc.blogspot.com/2018/04/moving-code-from-esp8266-to-esp32.html

[reddomon]

You said that Fpu is not permitted on ISR, but double is performed by software so it is permitted. Thank you for your contribution @misan .

[misan]

@reddomon What I understood is that FPU registers are not saved during the ISR, so using the FPU is not allowed there. Both integers, longs, and doubles seem to work ok as they do not use the FPU. The integer solution is the fastest, but I mentioned this as in some other cases floating-point might be needed and using doubles may enable that (though it is slower).

[vivian-ng]

My bad, I forgot to add the link to why float cannot be used in interrupts.

Crash in timer interupt when data type "float" is used

This is actually a known issue for a while, but the Marlin firmware never really had ESP32 support until sometime last year, and I don't think many of us were playing around with coreXY+ESP32 and so this problem was not discovered for a while.

Hopefully, someone can make the necessary changes and push a PR back to MarlinFirmware. Maybe encapsulate the changes inside #ifdef ESP32 statements so that it does not affect other platforms. I would do it if I could, but unfortunately, my fork of Marlin is based on luc's and we are still pending decision on how his fork can be merged back to Marlin.