From ea63778f7b20c66e4e4b7db25ab94b723a47265e Mon Sep 17 00:00:00 2001 From: Purdea Andrei Date: Mon, 6 Oct 2025 02:58:27 +0300 Subject: [PATCH] boot-cypress: Fix lingering rejected control transfer This is equivalent to the following change in glasgow firmware: https://github.com/GlasgowEmbedded/glasgow/pull/660 In boot-cypress this was triggered if I did the following: - `python3 -m fx2.fx2tool read_eeprom -f filename.bin 0 32768` - result: `Command timeout (bootloader not loaded?)` - `python3 -m fx2.fx2tool load boot-cypress.ihex` - `python3 -m fx2.fx2tool read_eeprom -f filename.bin 0 32768` - result: `Command not acknowledged (wrong address width?)` This sometimes even resulted in total corruption of the flash memory, and should be fixed since it's an easy mistake to make. This happened, because while there was no firmware loaded, the SUDAV interrupt is sticky. When the bootloader firmware is loaded It immediately tries to process a setup packet. But in the endpoint buffer it actually sees the control transfer that took the CPU out of reset, and it doesn't know what to do with it, so it falls through to the EP0_STALL. From this point on the same thing happens as in glasgow firmware: The rejected control transfer is retried again and again. And it is retired again and again while the EP0 buffer is getting gradually filled with a new control transfer that has not arrived yet. So the CPU will see a mix of the old control transfer and the new control transfer, which will result in data corruption. --- firmware/boot-cypress/main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/firmware/boot-cypress/main.c b/firmware/boot-cypress/main.c index b8f9d31..38d1550 100644 --- a/firmware/boot-cypress/main.c +++ b/firmware/boot-cypress/main.c @@ -191,6 +191,7 @@ void handle_pending_usb_setup(void) { return; } + pending_setup = false; STALL_EP0(); }