stm32l4 not leaving dfu mode and starting program.

[VBarb.1]

So for this question, I'm using stm32l4 device. It is a Cortex M4. I've been developing with stmcubemx and Kiel compiler.

I have a program that can jump to the stm32 provided dfu mode. That works great. I can update the code using DfuSe Demo.

I've run into this issue I don't know if is an issue with my code, how it is compiled, or something else? I use DfuSe Demo to "leave DFU mode" and the program doesn't appear to start running? I'd expect to leave DFU mode and my program to run, which happened earlier in development with simple code.

But lately, it doesn't start running. I used stm32 st-link utility to pull the core info from the device.

R0-R12 is 0x0.

R13: 0x20003cc0 (I think this is SRAM1)

R14: 0xffffffff

APSR: 0x0

IPSR: 0x0

EPSR: 0x10000000

XPSR: 0x10000000

PSP: 0x0

MSP: 0x20003cc0

PC: 0x800029c

I looked at my map file and it appears that the PC is

.text 0x0800029c Section 64 startup_stm32l496xx.o(.text)

Any advice as to where to start understanding what is happening? Why my code wouldn't start? Is there something I should look into?

If I program via JTAG or SW it works just find and will load and run the program. Just if I leave via dfu mode.

[TDK]

If this only happens when you jump to DFU through your system program, you need to ensure the state of the device is correct, peripherals interrupts disabled, clock settings compatible, etc.

However, your PC and MSP certainly suggest your program is running from flash and that it's not in the system bootloader anymore. Perhaps it's in the hardfault handler, or waiting on a flag to reset, or something.

If you can view the disassembly, see what is at 0x0800029c.

[VBarb.1]

Thanks for responding. I definitely am close to reset state when I jump to DFU. I write a magic number, turn off all peripherals, reboot and on boot that is the first value I read and then decide to jump to dfu mode or not. This code has been tested across different applications with no issues and is the suggested code in a tutorial I read on stm32 website.

Actually (correcting myself, not you) 0x8 is not 0x08 like I thought so the above memory map doesn't seem to mean anything. It appears to be FMC Bank3?

Its possible the original case was a low battery case. And the program decided not run due to lower battery. But this one seems strange.

I just tried this with another device and got a PC in: 0x1fff range (which doesn't appear to be SRAM but rather in the "code section" per the chip memory map). But none of my code is that high in memory per the .map file?

[TDK]

> Actually (correcting myself, not you) 0x8 is not 0x08 like I thought so the above memory map doesn't seem to mean anything. It appears to be FMC Bank3?

Both 0x800029c and 0x0800029c refer to the same place in flash. The leading zero is not important. You can't stop reading at "0x8", the number of digits after the 8 is important.

PC in 0x1FFFxxxx range is likely in the system bootloader.

[VBarb.1]

So any idea why it would be stuck at

.text 0x0800029c Section 64 startup_stm32l496xx.o(.text)

or in the system bootloader?

[TDK]

I suggested some possibilities and what steps to take in my first post.

[VBarb.1]

If this only happens when you jump to DFU through your system program, you need to ensure the state of the device is correct, peripherals interrupts disabled, clock settings compatible, etc.

--> jumping to dfu state seems to be correct as I mentioned above. I reset before I jump to.

However, your PC and MSP certainly suggest your program is running from flash and that it's not in the system bootloader anymore. Perhaps it's in the hardfault handler, or waiting on a flag to reset, or something.

---> How would I know if it is waiting on something to start? I don't intentionally do that in my code. Sometimes it starts fine (and slightly different version of the same code it starts fine). All hard faults are handled and should go to flash an led and reset. It isn't doing that.

If you can view the disassembly, see what is at 0x0800029c.

--> how do I view disassembly? I found map file and shared above it is in the startup_stm32l496xx text.