Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: How to trigger software reset on Teensy 4.1?

  1. #1
    Senior Member
    Join Date
    Oct 2020
    Posts
    175

    How to trigger software reset on Teensy 4.1?

    How do I reset the processor in software? Is there a reset() function to call, a register bit to set, etc? I wish to reset the processor and any hardware, essentially causing a reset like a power-on reset. If there's not a way, I wish to reset the processor and both USB cores. Thanks.

    In case you want to know why I want to reset, I have a long story

    I'm trying to emulate some USB device with my teensy 4.1. The feature I'm trying to develop is for teensy to change what USB device it emulates without reprogramming and hopefully without resetting. Say it starts off not emulating any USB device. But if a button labeled "KYBD" is pressed, teensy will initialize usb device side to emulate a keyboard. Then if another button labeled "MOUSE" is pressed, teensy will detach from USB and reattach as a mouse, or maybe detach and reattach as a composite device with both keyboard and mouse. In order to do this, I must find where usb_init() gets called and whether it is possible at all to reset usb hardware and software so I can reinitialize with a different set of descriptors and functions.

    I'm digging into the startup sequence and I found where teensy 4.1 initializes the USB device hardware, which is in ResetHandler() towards the end, before calling main() which calls setup() then loop(). In case I can't find a way to properly detach USB device side and reattach as a different device, I'd like to cause the board to reset.

  2. #2
    Senior Member
    Join Date
    Oct 2020
    Posts
    175
    Is this the reset call? I found it in usb.c in core folder:

    FLASHMEM void _reboot_Teensyduino_(void)

  3. #3
    This works for all Teensy with ARM processors.

    Code:
    void doReboot() {
      SCB_AIRCR = 0x05FA0004;
    }

  4. #4
    Senior Member
    Join Date
    Oct 2020
    Posts
    175
    Thanks. With the register name I found this snippet in void unused_interrupt_vector(void) in startup.c

    Code:
    	// reboot
    	SRC_GPR5 = 0x0BAD00F1;
    	SCB_AIRCR = 0x05FA0004;
    	while (1) ;
    I found some reference that SRC_GPR5 must be written a value before SYSRESETREQ is set (I can't find which register it's in).

  5. #5
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    4,060
    the ROM doesn't use all of the SRC_GPRn registers; however, there is potential future ROM patches or other RT parts that might use more of these registers. Essentially it is not recommended for use by customers to avoid having potential issues if the ROM is changed or if the customer decides to migrate to a different RT product.

    The only exception is SRC_GPR5. This is one is allocated for customer use, you may write different values that could have an objective or meaning in your application. If the value remains through a reset , then you know the reset was a system reset or core lockup instead of a POR.
    this is what i found online, so only the AIRCR is needed for general purpose resets

  6. #6
    Senior Member
    Join Date
    Oct 2020
    Posts
    175
    Thanks. That makes sense. The message reads O BAD OOFI. So it's the hint the CPU leaves for determining what happened before the reset. I can assign any values that will be checked after reset.

  7. #7
    Senior Member
    Join Date
    Oct 2020
    Posts
    175
    FYI, my long story was to reset USB Device Controller without having to reset CPU. This may be how to:

    P2354:

    A hardware reset can be performed by writing a one to the device controller reset bit
    in the USBCMD reset. Note: a hardware reset will cause the device to detach from
    the bus by clearing the Run/Stop bit. Thus, the DCD must completely re-initialize the
    device controller after a hardware reset.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,573
    To turn off the USB port, I believe just writing zero to USB1_USBCMD is usually enough.

    For your computer or a USB hub to recognize device disconnect, you should wait at least 10 milliseconds before reinitializing the port.

  9. #9
    Senior Member
    Join Date
    Oct 2020
    Posts
    175
    Thanks Paul! I'll follow your debounce time recommendation. I may decide to reboot instead if I can't tackle all of the resource freeing in addition to rebooting the USB controller.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •