STM32H562 + MicroPython frozen + PRODUCT_STATE=CLOSED: WS2812 / machine.bitstream hangs

[daleka]

I have a MicroPython project for an STM32H562. The project code is frozen into the firmware using frozen / manifest.py.

The main startup code is located in main.py on the SD card:

from protolyx import run

if __name__ == "__main__":
    run()

While the MCU was in the open state, everything worked normally: SD card, frozen modules, telemetry, UART protocols, and RGB indicators.

After switching the STM32H5 to:

PRODUCT_STATE = CLOSED

the firmware started hanging during startup.

At first, it looked like the problem might be related to the SD card or frozen modules. But after step-by-step testing, I found that the hang happens during initialization of the WS2812 RGB indicators.

The RGB chain is connected to pin PE4.

The old driver used:

from machine import Pin, bitstream

p = Pin("PE4", Pin.OUT)
bitstream(p, 0, (400, 850, 800, 450), buffer)

In the open state, this worked.
After PRODUCT_STATE = CLOSED, the code hangs exactly on the machine.bitstream() call.

I separately tested normal GPIO access to the pin:

from machine import Pin

p = Pin("PE4", Pin.OUT)
p.value(0)
p.value(1)

This works. So the GPIO itself is not blocked, and the pin is accessible.

I also tried replacing machine.bitstream() with my own driver using @micropython.viper, direct GPIO register access, and IRQ blocking. But after freeze and PRODUCT_STATE = CLOSED, this approach also did not give a reliable result.

As a temporary safe mode, I removed the physical WS2812 data output and left only this in NeoPixel.write():

def write(self):
    self.pin.value(0)

After that, the firmware starts normally, protolyx.run() runs, telemetry works, and the protocols work. But of course, the RGB LEDs do not light up.

My current conclusions:

• the problem is not the SD card;
• the problem is not the frozen code itself;
• the problem is not GPIO access to PE4;
• the hang happens specifically when trying to generate the WS2812 signal;
• it works in the open state, but not after PRODUCT_STATE = CLOSED.

I would like to understand whether anyone has seen similar behavior on STM32H5 with MicroPython.

I am interested in why machine.bitstream() or a similar runtime driver may hang after PRODUCT_STATE = CLOSED, even though normal GPIO access still works.

What is the correct way to handle WS2812 in this situation so that it works reliably after freezing the code and closing the MCU?

[daleka]

I continued investigating the machine.bitstream() hang on STM32H562 after switching to:

PRODUCT_STATE = CLOSED

The issue turned out not to be related to GPIO or frozen code. Normal access to pin PE4 works fine:

from machine import Pin

p = Pin("PE4", Pin.OUT)
p.value(0)
p.value(1)

The problem is inside the STM32 implementation of machine.bitstream().

In ports/stm32/machine_bitstream.c, Cortex-M uses DWT->CYCCNT:

DWT->CYCCNT = 0;
*bsrr = high_mask;

while (DWT->CYCCNT < t[0]) {
    ;
}

After PRODUCT_STATE = CLOSED, I checked DWT->CYCCNT directly:

import stm

DEMCR = 0xE000EDFC
DWT_CTRL = 0xE0001000
DWT_CYCCNT = 0xE0001004

stm.mem32[DEMCR] |= 1 << 24
stm.mem32[DWT_CYCCNT] = 0
stm.mem32[DWT_CTRL] |= 1

a = stm.mem32[DWT_CYCCNT]

for i in range(100000):
    pass

b = stm.mem32[DWT_CYCCNT]

print("a =", a)
print("b =", b)
print("ctrl =", hex(stm.mem32[DWT_CTRL]))

Result:

a = 0
b = 0
ctrl = 0x40000001

So the enable bit is set, but DWT->CYCCNT itself does not increment. Because of that, machine.bitstream() hangs forever inside the while.

I made a local patch in ports/stm32/machine_bitstream.c: before using DWT, I check whether DWT->CYCCNT is actually counting. If it is, the old DWT path is used. If not, it falls back to SysTick.

After that, the old Python code using from machine import Pin, bitstream works without any additional patches.

I think it would be useful to add a similar check in one of the next MicroPython releases, so that machine.bitstream() cannot hang forever in this situation. Even if a SysTick fallback is not ideal for every case, having a safe fallback or a clear error would be much better than a complete MCU hang.

[Josverl]

Could you please use 'triple backtick'
```py
# code goes here
``` around your code snippets to get syntax highlighting and proper indenting.

You should be able to edit your post, select the code , and then use the <> button.

Also see the section https://github.com/orgs/micropython/discussions/9111

[daleka]

Thank you for the hint, and sorry for the messy formatting in the first version.
I fixed the formatting.