Using the USBDFU_OverrideEnterDFU() function, a board/application can
define extra conditions when the system should boot in DFU mode, even if
it was not explicitly switched to DFU mode from the application.
The app/dfu/main.c uses this mechanism to boot into DFU mode if the
stack + reset vector addresses are not plausible (i.e. some random junk
appears to be flashed in the application partition) or if the user
places a jumper accross the RxD+TxD lines of the debug UART. The idea
is that the system can be recovered by placing this jumper and then
re-installing the application from DFU.
This makes sure that we'll re-enumerate on the USB, as a CPU reset
apparently doesn't automatically release the pull-up and notify the hub
that we were gone?
For some strange reason my output is garbled in both the 'screen' and
'cu' teerminal programs and 'raw' terminal (stty) mode. I fail to
understand why, but let's simply adjust the code as needed for now.
We need to refer to g_dfu as a pointer from all code. In DFU mode, it
gets assigned to the address of _g_dfu, which is placed by the linker
script at the start of RAM. In runtime mode, the pointer is statically
defined to point at the start of RAM. The linker script for the runtime
(dfu environment) is adjusted to save the first 32 bytes for the _g_dfu
structure.
* we now actually route the EP0 control requests in DFU mode to the
correct handler (weak linker symbols are tricky)
* we now actually call code to read/write data from/to RAM/FLASH
