Teensyduino reset routine

[psobiech]

Hi,
I think (at least in my opinion), it would be good to be able to use the soft reset capability that Teensyduino has. I did read Teensyduino code and it seems they are using CDC data_rate field magic value of 0x86 to mark a soft reset. I am no rust developer, but I was able to hack some example.

Would it be bad for imxrt-log to have a feature to enable this? I know its not technically responsibility of a logger, but .. this is where we are allocating the CDC device, so its the easiest place to put.

Please see my quick and dirty PoC: imxrt-rs/imxrt-hal@main...psobiech:imxrt-hal:main#diff-b73d632826be6b8fa8004b25a1e6d97b3680a564f1eea19785f9d9998c7c6e77R112

Usage is as follows: teensy_loader_cli -vs --mcu=TEENSY41 main.hex

We would need to change PID/VID (I dont know about the consequences of that, or rationale why they are different), otherwise teensy_loader_cli will not pick up our device, but with the above I can flash teensyduino / teensy4-bsp w/o any problems, flashing from Arduino IDE also works even if I have teensy4-bsp flashed.

Thanks!

[mciantyre]

I see how that reset behavior could be nifty. However, I also agree that this isn't the responsibility of the logger, particularly when the logger could be used across different i.MX RT processors.

imxrt-log is helpful when we need quick debug logging. ("Quick" tries to be both "easier to integrate" and also "lower overhead.") Once we start needing to do other things with the peripherals besides sending out text, it's time to consider something custom for our systems.

In light of #130, I've been thinking about ways to simplify imxrt-log. My goal would be to make it easier for others to build logging policies themselves. Instead of baking this into imxrt-log, maybe we could figure out a different, Teensy 4-specific logging / USB extensions that could support this reset behavior?

[Finomnis]

I have a similar problem, with the difference that I am on Windows and the -s flag of teensy_loader_cli on windows says "Soft reboot not implemented on windows".

Hence I started implementing the route of the hard reset, the so called rebootor. Although I had the idea to combine the two; as I use UART for logging instead of USB, my USB port is currently unused, so I could implement a self-rebootor on it that reboots itself instead of a different chip.

So far, this is working great: https://github.com/Finomnis/teensy4-selfrebootor

It can be programmed via teensy_loader_cli --mcu=TEENSY_MICROMOD -wrv main.hex.

Note that I got a teensy micromod - I didn't port the reboot code for teensy4.0 yet, which is a little bit more complicated according the the teensyduino repository.
For the micromod the simple asm("bkpt #251") is sufficient, but I'm not sure if it is also sufficient for the 4.0.

---

Now there's one problem that I do need help with, and maybe @mciantyre has an idea:

The rebootor only reacts to the message from teensy_loader_cli when it is sent within the first couple of seconds after MCU boot / USB connect. Afterwards, some step in the teensy_loader_cli seems to fail.

The error is consistent with the PORT_SUSPEND message I see on Wireshark USB capture, maybe indicating that the board or the attached USB hub may have trouble waking up from a suspend state. I do get some back and forth, though, so I'm not sure what exactly is going on.

I did capture the entire communication on Saleae with USB 1.1 Full-Speed, but my knowledge of USB isn't deep enough to decypher what's going on. I attached the Saleae log, maybe someone else understands what's going on?

[Finomnis]

@mciantyre I think I found something!

In imxrt_usbd::driver::Driver::poll, in the case of USBSTS::PCI::mask, I removed the self.initialize_endpoints() call, because I saw that it internally disables the endpoints.

Then, it worked after the suspend!

I'm sure they have a purpose though, so I'm not sure what a proper fix would be.

I looked up the PCI flag in the manual, and it says:

The Device Controller sets this bit to a one when the port controller enters the full or high-speed
operational state. When the port controller exits the full or high-speed operation states due to Reset or
Suspend events, the notification mechanisms are the USB Reset Received bit and the DCSuspend bits
respectively.

It sounds like this flag is expected when resuming from a suspend, so it's probably not a good idea to disable all endpoints in it.

What was the original though behind this? Is it part of the initialization routine that this bit happens at a specific time, before the endpoints get enabled again?

---

From my understanding, after doing a little more digging, the only place that can re-enable the endpoints is the BusAdapter::configure() method, which has to be called manually. Is there maybe a typo somewhere? Because I'm having a hard time understanding what's going on here ... :/

[mciantyre]

You're all good! Great find; my bad code is easier to troubleshoot that magic reset events.

If I remember correctly, the branch

        if usbsts & USBSTS::PCI::mask != 0 {
            ral::write_reg!(ral::usb, self.usb, USBSTS, PCI: 1);
            self.initialize_endpoints();
        }

intended to (re-)initialize endpoints if we are either reset or deconfigured. My interpretation of the RM is that we should only enable endpoints if we're configured. So if we're deconfigured, we should disable endpoints. An endpoint (re-)initialization achieves that, and coupling it with port change events meant that I didn't need to make the user call something like BusAdapter::unconfigure() (opposing BusAdapter::configure()) in their application. It should naturally work when coming out of reset, too.

Ian of ~2.5 years ago was wrong. Not only does this approach fail to consider suspend events, but it also doesn't handle the case when the host tells us to deconfigure, which is how deconfiguration actually happens.

Just riffing: I think we could move that self.initialize_endpoints() call into either the bus reset or driver initialization routine, and disable PCI interrupts. We can then figure out if deconfiguration happens in practice.

[mciantyre]

imxrt-rs/imxrt-usbd#23 is the tracking issue in the repo.

[Finomnis]

Sounds great!

I'll be gone until Sunday, so I won't be able to reply until then. But I also don't really understand the usb periphery as you do, so I'm not sure how much help I can be in creating a fix :/

[Finomnis]

For everyone looking at the conversation: this got fixed by a patch in imxrt-usbd.

[Finomnis]

I now finished the teensy4-selfrebootor crate.

This allows the device to be reprogrammed hands-off. Its only requirement is that nothing else uses the USB Port.

Here's a minimal example of a system that can get re-programmed via teensy_loader_cli -r:

#[rtic::app(device = teensy4_bsp)]
mod app {
    use teensy4_bsp::hal::usbd::{BusAdapter, EndpointMemory, EndpointState};
    use usb_device::bus::UsbBusAllocator;

    static EP_MEMORY: EndpointMemory<1024> = EndpointMemory::new();
    static EP_STATE: EndpointState<4> = EndpointState::new();

    #[local]
    struct Local {
        rebootor: teensy4_selfrebootor::Rebootor<'static>,
    }

    #[shared]
    struct Shared {}

    #[init(local = [bus: Option<UsbBusAllocator<BusAdapter>> = None])]
    fn init(cx: init::Context) -> (Shared, Local) {
        let teensy4_bsp::board::Resources { usb, .. } = teensy4_bsp::board::t40(cx.device);

        let usb_bus = cx.local.bus.insert(UsbBusAllocator::new(BusAdapter::new(
            usb, &EP_MEMORY, &EP_STATE,
        )));

        let rebootor = teensy4_selfrebootor::Rebootor::new(usb_bus);

        (Shared {}, Local { rebootor })
    }

    #[task(binds = USB_OTG1, priority = 5, local = [rebootor])]
    fn usb1(ctx: usb1::Context) {
        ctx.local.rebootor.poll();
    }
}