trigger code when USB host triggers DFU mode?

[myklemykle]

Is there a way to trigger a bit of code on the Pico at that moment when the USB host sends the magic baudrate-request that kicks the Pico into DFU mode? I'm using TinyUSB, but not yet finding anything about this in their docs. I don't want to prevent DFU mode, I just want to update the screen on the device to say "DFU MODE" or similar.

[earlephilhower]

Nope, there's no special hook. You can hack your copy of the core to handle this. Check in SerialUSB.cpp.

[myklemykle]

Thanks for the tip ... that didn't end up working, but it got me on the right track. I'm not sure what situation triggers that method in SerialUSB.cpp. Maybe if I was using the other USB stack? Using TinyUSB, the handler that's triggered when I set baud rate to 1200 on the USB device is TinyUSB_Port_EnterDFU() in Adafruit_TinyUSB_rp2040.cpp , and it's the same sort of thing.

I put a hack in there and it works for me. The implementation could be cleaner. Are you interested in having that feature in the core?

[earlephilhower]

It shouldn't really be a hack. If you define a __attribute__((weak)) callback function for the "I'm gonna reboot" notification and call it, if defined, in the actual CheckSerialReset function, it would "just work" (as in do nothing unless you defined a CB function)...

arduino-pico/cores/rp2040/SerialUSB.cpp

Lines 182 to 198 in 6a5f98c

	static void CheckSerialReset() {
	if (!_rebooting && (_bps == 1200) && (!_dtr)) {
	if (__isFreeRTOS) {
	__freertos_idle_other_core();
	}
	_rebooting = true;
	// Disable NVIC IRQ, so that we don't get bothered anymore
	irq_set_enabled(USBCTRL_IRQ, false);
	// Reset the whole USB hardware block
	reset_block(RESETS_RESET_USBCTRL_BITS);
	unreset_block(RESETS_RESET_USBCTRL_BITS);
	// Delay a bit, so the PC can figure out that we have disconnected.
	busy_wait_ms(3);
	reset_usb_boot(0, 0);
	while (1); // WDT will fire here
	}
	}

[earlephilhower]

Actually, on further thought, what you're suggesting can't work in general. The USB processing is IRQ driven and if you were in the middle of an SPI transaction to your display to, say, update status, you can't just use the SPI device to send another command in the middle of things. So, simple things without external dependencies can be hooked in here, but use of peripherals probably not.