To set DFU_Util mode you press reset and hold the mode button down for the required period of time. The boot loader is started by the reset and monitors the mode button, and places the spark core as responsive to DFU_Util commands. I’m pretty sure the boot loader does nothing with GPIO pins, as pin mapping is done later in the hardware initialization in the spark firmware.
The following in an extract from RM0008, the technical reference for the STM32F1XX.
**8.1.1 General-purpose I/O (GPIO)**
During and just after reset, the alternate functions are not active and the I/O ports are configured in Input Floating mode (CNFx[1:0]=01b, MODEx[1:0]=00b).
The JTAG pins are in input PU/PD after reset:
PA15: JTDI in PU
PA14: JTCK in PD
PA13: JTMS in PU
PB4: NJTRST in PU
When configured as output, the value written to the Output Data register (GPIOx_ODR) is output on the I/O pin. It is possible to use the output driver in Push-Pull mode or Open-Drain mode (only the N-MOS is activated when outputting 0).
The Input Data register (GPIOx_IDR) captures the data present on the I/O pin at every APB2 clock cycle.
All GPIO pins have an internal weak pull-up and weak pull-down which can be activated or not when configured as input.
D7 is PA13/JTMS so it will have an internal pull-up applied until the spark firmware runs and performs its hardware initialization. I’ve noticed in the past that when using the JTAG shield and STLink, the D7 Led is always doing something (which is should being JTMS). To use JTAG you have to set/change a #define in the firmware to prevent hardware initialization from remapping the JTAG pins as GPIO.
This explains a constant signal on D7 while flashing with DFU_Util. It will stay on until DFU_Util completes and the boot loader gives control to the spark firmware. I have no idea what would cause it to flash if that is happening, which now doesn’t appear to be the case anymore.