[STM32H7] Cant get user code running

[elpekenin]

Operating System

Windows 11

INFO_UF2.TXT

TinyUF2 Bootloader 0.5.1-39-gaf609f0-dirty - st/cmsis_device_h7 (v1.10.0) st/stm32h7xx_hal_driver (v1.10.0) tinyusb (0.10.1-109-g9b3ec69b2) Model: STM32 STM32FH750VBT6 Board-ID: STM32H750VB-MiniSTM-v1.1 Date: Jul 31 2023

What happened ?

Going insane trying to flash my board (beware this is code from an open PR)

Using 0x9000_0000 as base address for my .ld (as per https://github.com/adafruit/tinyuf2/pull/144/files#diff-b61bf541adb93685c7c187c1a8abfb836197a5f08fcf1db49558fd68d96a86e8R55)

However, i have tried several things with uf2conv.py with no avail -- Should i be using -b 0x90000000 or not?

Seems like stuff is not being (correclty) written to the flash and, on boot, detects there's no -valid- app to jump into

How to reproduce ?

1. Flash code from H7xx PR
2. Compile and flash a file (i most likely did something wrong along the way, please bear with me)

Debug Log

No STLink yet, cant debug properly. I could grab very little info by drawing on the board's display (ie: that app is checked as invalid)

Screenshots

No response

[bhav97]

For the firmware you're trying to program, can you share the .elf and .map file from the build. You can generate a map file by passing -Wl,-Map=${PROJECT_NAME}.map to gcc

The board_app_valid performs 2 checks,

1. the SP in your firmware must lie in one of the RAMs (I've tried to include all available RAM in H7xx, but maybe I missed some)
2. the Reset vector must lie in QSPI (0x9000_0004) or AXISRAM (0x2400_0004) (for temporary apps)

---

Passing -b 0x90000000 is correct. You should use it. This is the command I use to generate the uf2 file

$uf2conv -f 0x6db66082 -b 0x90000000 -c -o ${PROJECT_NAME}.uf2 ${PROJECT_NAME}.bin

For the weact board in the H7 port, 0x90000000 will target QSPI flash, and 0x60000000 will target SPI flash. H750 only has a single internal flash bank that contains tinyuf2, so passing any 0x80--- address will not work.

[elpekenin]

Im no expert but this looks right to me: https://gist.github.com/elpekenin/5abb3a7926a316572ff75fcaedac6500

This should be the relevant code (mainly the ld + UF2 settings on post_rules) https://github.com/elpekenin/qmk_firmware/tree/19ed6908999f2ebbbb8e02039d886032d13465c4/keyboards/handwired/onekey/weact_stm32h750vbt6

Edit: Oh, and this... https://github.com/elpekenin/qmk_firmware/blob/19ed6908999f2ebbbb8e02039d886032d13465c4/platforms/chibios/mcu_selection.mk#L747

[bhav97]

SP (in DTCM) and Reset_Handler (in QSPI) look good. I can't think of a reason why board_app_valid would fail.

I can try and debug qmk on my hardware but make handwired/onekey:default DEFAULT_FOLDER=handwired/onekey/weact_stm32h750vbt6 fails with #error "invalid STM32_PLL2_DIVP_VALUE value specified". Can you help me build qmk and reproduce this issue?

[elpekenin]

I compile with qmk compile -c - kb handwired/onekey/weact... -km default

[elpekenin]

I just realized i was working with an earlier version of your code and checked current version out. Still the same :(

[bhav97]

Thank you! I was able to get the h750-support branch compiling but I couldn't exactly replicate the issue

My observations,

1. Programming completes successfully
2. QMK starts but gets stuck during the ChibiOs init (stm32_gpio_init, maybe some config error?)
3. Double tap into DFU works normally

I was able to reproduce the issue if I interrupted the flash erase, Programming would complete normally in the next attempt but board_app_valid always fails because the QSPI read 0xFFFFFFFF.

I'm not sure why this happens (maybe the erase before write isn't implemented properly), but I was able to get back to a working state by flashing the tinyuf2 erase-app. Can you give erase-app a try?

[elpekenin]

Will do, i can confirm i also saw a bunch of F from QSPI yesterday, as i just received the STLink, but had very little time for test. Will have some updates in like 10h from now. Thanks again for the help

[elpekenin]

Got it to boot (and early crash), thanks!!

Time to double check my pin configs on ChibiStudio, this should be fixed tu2-wise, thus closing the issue.