Pod: Uploaded program doesn't work after reset

I use the example SimpleButton for the pod.
I’m able to upload the program to my pod and it works as expected. Button 1 switches LED 1 to white while pressed and Button 2 toggles LED 2 to white.
But after a reset or power off/on the program works only partial.
Button 1 switches LED 1 to red while pressed and Button 2 has no function any more.
Similar is to other examples. Encoder or so.
After upload with make program-dfu the program is working one time, after reset or power off/on not.
It seems the program is only uploaded to a RAM like memory.

hardy@misterbig:/second/downloads/Kickstarter/Daisy/DaisyExamples/pod/SimpleButton$ make program-dfu
dfu-util -a 0 -s 0x08000000:leave -D build/SimpleButton.bin -d 0483:df11
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08000000, size = 29148
Download        [=========================] 100%        29148 bytes
Download done.
File downloaded successfully
dfu-util: Error during download get_status
make: *** [../../libdaisy/core/Makefile:250: program-dfu] Fehler 74

I’ve seen such behavior too and haven’t quite figured out what exactly was going on. Somehow device wouldn’t load FW flashed with DFU or programmer after full restart. The problem is that if I upload it with programmer again, it works fine. So I can’t debug it as using programmer solves the issue. Another strange thing is that this was happening with debug build, but not release build of the same code.

My problem was, uploading with programmer stlink worked a few days before and also I has been able to debug with it. But not anymore. So I switched back to program-dfu.
Stlink programmer does a reset after upload. Maybe because of that the program will start not correct after the first start.

hardy@misterbig:/second/downloads/Kickstarter/Daisy/DaisyExamples/pod/SimpleButton$ make program
openocd -s /usr/local/share/openocd/scripts -f interface/stlink.cfg -f target/stm32h7x.cfg \
        -c "program ./build/SimpleButton.elf verify reset exit"
Open On-Chip Debugger 0.10.0+dev-01321-ge8cfdd4a-dirty (2020-07-11-19:17)
Licensed under GNU GPL v2
For bug reports, read
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1800 kHz
Info : STLINK V2J36S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.162427
Info : stm32h7x.cpu0: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800035c msp: 0x20020000
** Programming Started **
Info : Device: STM32H74x/75x
Info : flash size probed value 128
Info : STM32H7 flash has a single bank
Info : Bank (0) size is 128 kb, base address is 0x8000000
Info : Padding image section 1 at 0x080071dc with 4 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x080071e0 .. 0x0801ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

IIRC, I could boot after flashing with ST-Link specifically if I flash at least once with DFU after turning on the device. So you could try that if you want to use programmer for debugging. And check if switching between debug/release builds makes any difference.

I suspect that this has something to do with correct ISR vector location, but I haven’t learned enough about STM32H7 DFU bootloader to understand what exactly happens there. I’m running custom firmware now, but I think I’ve seen this issue when using libDaisy too.

I just noticed this happening with a few other examples as well (encoder not working on the Petal after reset, or when flashed with st-link).

I’m looking into a fix right now, and will keep you posted. But it seems things are working as expected on libdaisy commit d075637 if you’re impatient.

sorry for the inconvenience!

For future big-updates I’m going to set up a develop branch that can act as a testing ground (for the brave among us) before things get merged to master.

This could be 2 unrelated issues, because I haven’t experienced issues with encoder before. But I’ve ran into issues with flashed firmware not booting both with libDaisy and without it. I would definitely want to understand what caused those boot problems.

Yeah, definitely seems like two issues to me as well.

I can confirm I just found the cause of the partial-functionality for petal (one enc pin), and pod (one of the tactile switches). There are likely a few other oddities like this on the other boards as well.

That issue is that the old SAI code started the RCC for all GPIO ports. Apparently this was not happening in the generic GPIO Init code. So with the new code, certain ports clocks weren’t being started.

I’m adding this to the GPIO init function now, and testing it on a few of the platforms. Should be merged in a little bit.

I don’t think I’ve experienced the not booting after reset issue that you mentioned previously (with libdaisy) I have seen it on custom firmware for other ST chips when I was doing weird VTOR stuff (jumping to/from custom bootloaders and such).

So could be that, but if you have seen it happen with libdaisy, and could provide any steps for repro that would be really helpful.

The issue that I’m getting now with OWL should not be related to jump from bootloader, because it happens before I get the breakpoint in bootloader’s startup ASM. So this is really a fairly typical code from Cube export that doesn’t seem to run if I boot it from flash in some cases.

I haven’t used libDaisy for over a month now, so I’ll check if I can reproduce this on whatever checkout I have and if upgrading it makes a difference. But I’m pretty sure that it happened with libDaisy before and was surprised that nobody else had the same issue.

Yeah, that seems like a different issue for sure.

I’ve done a decent amount of stuff with both just Cube/HAL and libDaisy without experiencing it just not booting back to the flash correctly… So if you end up with something replicable feel free to send it my way so I can see what’s happening.

@smallangel Alright, the fix for your issue has been merged onto master. Sorry again for the inconvenience!

Your ST-Link related issues could be related to the issue that @antisvin mentioned. However, my experience with this issue was that programming over DFU would work consistently until reset, or power-cycle. Programming from ST-Link would have the partial functionality regardless of power state.

If you continue to have issues with ST-Link uploading feel free to reach out directly, or create a new topic that’s a bit more specific to that issue (as it does seem to be a separate issue so far).

@shensley Thank you for the very fast solution. The program flashed with program-dfu is now also working after reset and powercycle again.
Your fix worked for the buttons and the encoder.
But the knobs are not read. For instance in the SimpleLed example. I tried other examples with the same result. Knob 1 and 2 are showing no influence.

@smallangel Alright, this is fixed! The pod had a leftover use of the old “callback_rate” that was uninitialized. This triggered a hard-fault from This has been fixed on the latest master.


I’m able to confirm the fix. Thank you.

1 Like