Deepsleep works. That's fine. There is some strange effect: Before deepsleep, the current consumption at a Teensy 4.1 is 71 mA. After waking up from deepsleep, it is 102 mA. Similar to the state after firmware update, where the board boots into a 102mA state as well. Calling machine.reset() at a 71mA state does not change the current consumption.

There is some strange effect: Before deepsleep, the current consumption at a Teensy 4.1 is 71 mA. After waking up from deepsleep, it is 102 mA

I have no idea, it doesn't seem like we're enabling anything after wakeup. Any suggested fixes ?

Any suggested fixes ?

I do not know what causes this power consumption increase. It is not affected by machine.reset(). Clearing it requires a power cycle. And it does not happen always, as I noticed just now! So it maybe a hardware issue, like a latch-up.

@robert-hh - Not sure why the current would have increased. We don't have that issue on our boards. I don't see any major differences between us and the Teensy power system.

There is no consistent machine RTC API. If you look at the different boards they all have slightly different APIs that are actually implemented.

I raised a issue about that #10578 and made a PR #10607, which is held for further consideration about a common API. So a RTC alarm can fit into these plans, but hopefully be merged before.

@robert-hh Speaking of machine, do you have any plans for a machine_led ? I have lots of scripts that use LEDs, and I'm trying to make them more portable, but there's just no single way to control those pins because on different boards they have different polarities.

There is a machine.LED class at mimxrt boards, and machine.Signal. Or do you think of something different.
Edit: Loosk like there is a problem in led.c. machine.LED does work on a mimxrt1011 board, but not on mimxrt1020 or -106x. The respective Pin gets not properly configured.

There is a machine.LED class at mimxrt boards

Yes I was thinking if something like that can be moved to extmod and shared with other ports, right now I extend umachine with an LED class:

class LED:
    def __init__(self, pin_name):
        self.pin = Pin(pin_name, Pin.OUT)
        board = self.boardname()
        if board in []: # All boards have inverted LEDs, add ones that don't here.
            self.inverted = False
        else:
            self.inverted = True
    def on(self):
        self.pin(int(not self.inverted))

# And so on...
.....

Then lets me support boards with/without inverted LEDs, and it will have to do until there's an upstream machine.LED class.

machine.LED does work on a mimxrt1011 board, but not on mimxrt1020 or -106x. The respective Pin gets not properly configured.

I never actually tested it before, I used machine.Pin and they worked fine on our board.

But what is the difference then to the Signal class, which as well allows to declare it as inverted.

But what is the difference then to the Signal class, which as well allows to declare it as inverted.

You don't know if the pins are inverted or not unless you know which board the code is running on by checking os.uname or platform etc.. which makes writing a simple blinky that works on all boards more complex than it needs to be, and then this code has to be in every example that uses an LED.

For machine.LED the pins are defined in a way, that led.on() and led.off() work as expected. But there is only one definition for all pins of a board. So maybe that could be improved.
I fixed machine.LED(). It was a kind of typo bug. And I simplified the code. The commit is in the next service type branch, to be submitted as PR later. Maybe more small changes/fixes appear.
https://github.com/robert-hh/micropython/tree/mimxrt_sp18

For machine.LED the pins are defined in a way, that led.on() and led.off() work as expected.

Yes that's why it's better than Signal, a machine.LED would know if LEDs are inverted or not. Like I said I have a machine.PIN extension to machine module and this works fine for now until there's one upstream.

Thanks for updating. Now merged.