djsundog/circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

stm32/mboot: Disable polling mode by default and use IRQ mode instead.

Browse Source 
Polling mode will cause failures with the mass-erase command due to USB
timeouts, because the USB IRQs are not being serviced.  Swiching from
polling to IRQ mode fixes this because the USB IRQs can be serviced between
page erases.

Note that when the flash is being programmed or erased the MCU is halted
and cannot respond to USB IRQs, because mboot runs from flash, as opposed
to the built-in bootloader which is in system ROM.  But the maximum delay
in responding to an IRQ is the time taken to erase a single page, about
100ms for large pages, and that is short enough that the USB does not
timeout on the host side.

Recent tests have shown that in the current mboot code IRQ mode is pretty
much the same speed as polling mode (within timing error), code size is
slightly reduced in IRQ mode, and IRQ mode idles at about half of the power
consumption as polling mode.
This commit is contained in:
Andrew Leech 2020-07-01 15:06:14 +10:00 committed by Damien George
parent 95ec0debec
commit 494bcad8ab
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
ports/stm32/mboot/main.c
View File

@ -38,14 +38,12 @@
#include "powerctrl.h"
#include "dfu.h"
// Using polling is about 10% faster than not using it (and using IRQ instead)
// This DFU code with polling runs in about 70% of the time of the ST bootloader
// This option selects whether to use explicit polling or IRQs for USB events.
// In some test cases polling mode can run slightly faster, but it uses more power.
// Polling mode will also cause failures with the mass-erase command because USB
// events will not be serviced for the duration of the mass erase.
// With STM32WB MCUs only non-polling/IRQ mode is supported.
#if defined(STM32WB)
#define USE_USB_POLLING (0)
#else
#define USE_USB_POLLING (1)
#endif
// Using cache probably won't make it faster because we run at a low frequency, and best
// to keep the MCU config as minimal as possible.