I have a a few questions.
#1 - Can the STM32H747XI on the STM32H747I-DISCO board be put into a DFU mode?
#2 - I have a test app where after it is booted, you can push the WAKE button on the board. The handler for that will then set a magic pattern into a DTCM located variable and call NVIC_SystemReset(). This forces a reset of the board, which will then boot the same app. The very first thing the app code does inside of main, is check that DTCM located variable's value. If it is not the magic value, continue running. If it is the magic value, then it should jump to the bootloader, preferably only the DFU portion of it. AN2606 says:
In addition to the patterns described above, the user can execute bootloader by performing
a jump to system memory from user code. Before jumping to bootloader:
• Disable all peripheral clocks
• Disable used PLL
• Disable interrupts
• Clear pending interrupts
I've tried numerous iterations of these things as found in the postings on this forum. None of them cause the DFU device to be listed in the Windows Device Manager. They are doing something, as I can click the Suspend button in CubeIDE and see it is in system memory, but of course I don't know ST's code. The current iteration of jumping to bootloader that I'm trying is this:
uint32_t i=0;
void (*SysMemBootJump)(void);
/* Set the address of the entry point to bootloader */
volatile uint32_t BootAddrStack = 0x1FF09800;
volatile uint32_t BootAddr = 0x1FF09804;
BSP_LED_DeInit(LED4);
BSP_LED_DeInit(LED3);
BSP_LED_DeInit(LED2);
BSP_LED_DeInit(LED1);
BSP_PB_DeInit(BUTTON_WAKEUP);
HAL_RCC_DeInit();
HAL_DeInit();
/* Disable all interrupts */
__disable_irq();
/* Disable Systick timer */
SysTick->CTRL = SysTick->LOAD = SysTick->VAL = 0;
/* Set the clock to the default state */
// HAL_RCC_DeInit();
/* Clear Interrupt Enable Register & Interrupt Pending Register */
uint8_t cnt = (sizeof(NVIC->ICER) / sizeof(*NVIC->ICER));
for (i=0;i<cnt;i++)
{
NVIC->ICER[i]=0xFFFFFFFF;
NVIC->ICPR[i]=0xFFFFFFFF;
}
/* Re-enable all interrupts */
// __enable_irq();
/* Set up the jump to booloader address + 4 */
SysMemBootJump = (void (*)(void)) (*((uint32_t *) ((BootAddr))));
/* Set the main stack pointer to the bootloader stack */
__set_MSP(*(uint32_t *)BootAddrStack);
/* Call the function to jump to bootloader location */
SysMemBootJump();
/* Jump is done successfully */
while (1)
{
/* Code should never reach this loop */
}
The test app does not configure any USB pins/peripherals. The board is currently being powered via the VIN pin and a ground pin available on CN8 (Arduino connector on the board, but the pins go straight to a power supply, jumper is set to E5V). I'm debugging via an STLINK-V3SET (rather than the board's built in STLINK).
If I am debugging, and I plug a USB into CN2 (ST-LINK V3E) after I execute the jump to bootloader code, the app starts running as if it was newly powered up. This sort of behaves like it did jump to the bootloader, waited for a USB device change/notification, and then continued on with the boot process, finally pulling from the internal storage to boot the app.
If I am not debugging and power up the board, hit the button to execute the jump to bootloader code, then plug in the CN2 USB, nothing happens. So I suspect that the above mentioned behavior has more to do with being debugged and then connecting the internal debugger via CN2.
Admittedly, I don't know which of the 3 available USB connectors should be used for DFU (the reason for asking #1), but I have tried testing with all 3 of them.
Any help?
