How to trigger software reset on Teensy 4.1?


Well-known member
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 :D

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.
Is this the reset call? I found it in usb.c in core folder:

FLASHMEM void _reboot_Teensyduino_(void)
Thanks. With the register name I found this snippet in void unused_interrupt_vector(void) in startup.c

	// 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).
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
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.
FYI, my long story was to reset USB Device Controller without having to reset CPU. This may be how to:


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.
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.
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.