STM32L496 - DFU Exit detection

[AFahr.1]

Hello, I'm running into a bit of trouble updating firmware using DFU. This would not be such a big deal, apart from the fact that sometimes an upgrade needs to be made without the ST-Link tool.

First of all, entering DFU mode and re-flashing the firmware using CubeProgrammer works.

 

I'm using the settings shown above.

When the flashing is finished, I'm reading a Backup register. If it's 0 (it seems they zero out after DFU mode, I do a reset by calling HAL_NVIC_SystemReset(). However, I don't think that works.

Is there a reliable way of detecting if the system just exited from DFU mode (status bit, register, etc...), and would that be available just after reset, i.e, at the start of the main() program?

Cheers,

Alberto

[AFahr.1]

I just mean to clarify that after leaving the DFU mode, the system does not start as expected. I wonder if there's some USB issue or other at hand...

Cheers,

Alberto

[AFahr.1]

I just found this on one of the application notes (AN3156, page 19)

Note:

1 The Jump to application works only if the user application sets the vector table correctly to point to the application address.

2 When performing a jump from the bootloader to a loaded application code using the USB IP, the application has to disable all pending USB interrupts and reset the core before enabling interrupts. Otherwise, a pending interrupt (issued from the bootloader code) may interfere with the user code and cause a functional failure. This procedure is not needed after exiting the system memory boot mode.

Can someone explain how to do this or what this means? If I reset the core... doesn't it mean the application will go into an endless reset start loop?

Cheers,

Alberto

[AFahr.1]

I haven't had much progress on this, having had to look at other issues, however, this is still in the back of my mind.

Is there a way for ST programmers to add an "Exit DFU Mode and Reset chip" button on the STM32 Programmer? I find myself in the situation that I want to just enter and then exit USB DFU mode (you know, for fun!).

Cheers,

Alberto

[AFahr.1]

So, here's an update on what was happening, in case anyone ever encounters the issue. It's not solved 100% yet, but enough for me to get it working. I will add no code, but I will try to explain as best I can.

At Power Up, the system initialises the clocks, LSE being one of them. If the RTC has a valid date, it will not reconfigure, or basically not re-set the date on the RTC. If it has an invalid date, it will re-set it to 01/01/2000.

Also, during clock configuration, the CSS is enabled.

If I reset the system, or go to sleep mode, or wakeup and sleep, or any other thing within the application all works well.

If I jump to Bootloader mode, and re-flash my firmware, I noticed after a lot of looking that LSECSSD had been set! So after a restart, the unit effectively had a CSS LSE error, and so, it would go into Error_Handler (while(1)).

It took me a while to realise that to reset the LSECSSD bit on the RCC BDCR register the Backup Domain must be reset with

/* Backup reset domain to reset CSS error */
__HAL_RCC_BACKUPRESET_FORCE();
__HAL_RCC_BACKUPRESET_RELEASE();

So, after that, even though I lose my RTC information (which I don't really care after a firmware upgrade) the unit cleared the LSECSSD bit and it could start.

Funny aftereffect which I'm still looking at, after clearing the backup register, the MX_RTC_Init function returns a timeout. However, at the moment, I'm getting around this issue by resetting the whole micro just after I reset the backup domain. And that does the trick so far.

I will need to get around the RTC init error at some point, but at least this will allow me to re-flash the firmware on site.

Cheers,

Alberto