Idle current

Can someone tell me what should the idle current be. My is 130mA, for doing absolute nothing.
I ask, because my design has no kill switch and battery change is not easy. So it has to be on charger for the whole time.

Short answer: less than one mA.
Longer answer: There are a lot of things that can cause this to not be the case. Primary reason is usually styles that keep some blades awake even when the saber is not ignited. Layers that are on top of the inout layer can cause these sort of problems. Sometimes it’s possible to fix that by modifying the style, sometimes it isn’t. Usually it’s easier to just use the IDLE_OFF_TIME which will force the blade off after some time.

If IDLE_OFF_TIME doesn’t help, then the problem might not be a blade, but something else. There is a serial monitor command called whatison that might help, but it could also be a wiring issue.

Hi, first of all: respect for your reaction time.
Short answer was sufficient. I already checked all.
I disassembled and desoldered all. Ignore the 3 cables, they are not connected anymore.
Then I used an flircam to see what is getting hot. I attached the Image.
1715600657962_100

Bootup Video

When I look what is hot, I can see that not only cpu, but also a part near the 5V, Batt+.
Think its the 3,3 Voltage regulator.
Which is normal, because it dont want to bring so much power.

BTW: Board starts with 200mA, then after idle_time_out it drops to 130mA.
whatison shows everything off.
Everything is functional, except the power usage.

Here is the Top View
|Audio DMA|0.00%|
|Wav reading|0.00%|
|Pixel DMA|0.00%|
|LOOP|43.60%|
|Motion|0.00%|
|Global loops / second|10745.45|
|High frequency loops / second|10586.96|
|blade fps||
|Acceleration measurements per second|1728.81|
|Hybrid Font loop|15.41%|
|WS2811_Blade loop|1.50%|
|ClockControl loop|2.63%|
|Booster loop|3.38%|
|SDCard loop|2.26%|
|Amplifier loop|2.26%|
|LSM6DS3H loop|1.88%|
|I2CBus loop|1.50%|
|Parser loop|3.01%|
|pow loop|3.38%|
|SaberFett263Buttons loop|0.38%|
|StatusLED loop|3.01%|
|BatteryMonitor loop|3.38%|
|Fusor loop|0.38%|
|AudioDynamicMixer loop|1.88%|
|MonitorHelper loop|3.76%|

Possible a production failure ? It was ordered by artekit.

best regards

It’s possible that something has been shorted/fried and is now causing a permanent drain. The other possibility is that it’s a software/configuration thing. Maybe post your config file and/or try a super-simple config file (as generated by my configuration generator) and see if that makes a difference?

Does anything get warm or draw significant power on the other side of the board?

The other side is slowly getting warm. So its definitve the cpu.
To exclude a config problem I reboot to DFU Mode. Same Result.
Finally I came to the conclusion that there is a Hardware/Production Failure
and I contacted the manufacturer. Now I will order another one and compare it.

thx for your help.

DFU mode busy-waits though, while ProffieOS doesn’t. Under normal circumstances DFU mode draws more power than ProffieOS. (Until you turn the saber on that is.)

oh, thx. I will give it on more try with stupid simple config.

I tested simple config: same result.
I realized that you have implemented a “shutdown” command in developer comands.
So I activated this and test. When board is shutdowned, it is drain the current also.
Other values that might be important to you:

stm32info (battery not connected, only USB)
VBAT: 3.30
VREF: 3.27
TEMP: 62.79
portstates
PORTA: gggg gaaa aaaa oaaI -du- ---- ---- —u llhl llll llll lllh 100A A01D 1000 0001
PORTB: aiaa aaaG Gaag giaa -u-- —u u–u -d-- lhll lllL Lllh lhll 0000 00D4 4000 0020
PORTC: aaIi iiii aaaa aaaa ---- -uuu ---- ---- lllh Hhhh lllL llll 000C CCCC 0000 D000
PORTH: iiii iiii iiii aiaO ---- ---- ---- ---- llll llll llll llLl 0000 0000 0000 0000
CLK
Clocks: hse=0 lse=32768 sys=79953920 f=79953920 h=80000000 p1=40000000 p2=40000000 sai=0
whatispowered
ON: FLASH GPIOA GPIOB GPIOC GPIOD GPIOH+ ADC+ USBFS+ TIM2+ TIM15+ RTCAPB CRS+ SYSCFG
VBUS: 1
USBD connected: 1
i2cstate
I2CBUS: last_request = 139999 (now = 276342) i2c_detected_ = 0 used = 0
I2C STATE: 1
current: 0 id= 0 next= 0
last: 0 id= 0 next= 0
Motion requested: 0 (millis() - last_motion_request=156343)

What about “whatison” ?

whatison
Saber bases: Off
Beeper: Off
Talker: Off
Wav player 0: Off (eof = 1 volume = 0.50 refs = 0 fade speed = 0.00 filename=)
Wav player 1: Off (eof = 1 volume = 0.50 refs = 0 fade speed = 0.00 filename=)
Wav player 2: Off (eof = 1 volume = 0.50 refs = 0 fade speed = 0.00 filename=)
Wav player 3: Off (eof = 1 volume = 0.50 refs = 0 fade speed = 0.00 filename=)
Wav player 4: Off (eof = 1 volume = 0.50 refs = 0 fade speed = 0.00 filename=)
Wav player 5: Off (eof = 1 volume = 0.50 refs = 0 fade speed = 0.00 filename=)
Wav player 6: Off (eof = 1 volume = 0.50 refs = 0 fade speed = 0.00 filename=)

Sometimes stm32info give

VBAT: 0.00
VREF: ovf
TEMP: -210.47

Yeah, I must admit, I don’t know.
I think you’re probably right that this is a hardware problem.