STM32H750 not booting

[elpekenin]

I just found out why it crashed... It's because tu2 was doing:

• Init QSPI in mem-mapped mode
• Check if we should jump to user code and do so if appropriate. I will later try and find out whether this config is keep or we need to re-config it...
• if no jump, re-inits the QSPI bus without mem-mapping (apparently author couldnt get it working by just exiting mapped mode). This is to be able to write on the QSPI flash the file received over USB, i guess (as mem-mapped is read-only)
• After this, my code tried reading as mem-mapped, obviously failed . I could get it to read from 0x90000000 by going into the mode again

So i "just" need to figure out why it is either:

• Not detecting the code on QSPI as bootable and jumping to it (pretty sure this is what happens)
• Crashing when user code (ChibiOS) runs and falling back to bootloader (not sure if that's even the behaviour on crash)

[elpekenin]

Good news, i can jump into the uf2 now. Had to use the erase-firmware "app" first, to get the "is app valid?" check to pass, probably a little bug somewhere.
Bad news, it breaks early on init

According to STLink, program halts...

Code: Select all

__STATIC_INLINE void __rccResetAHB4(uint32_t mask) {
  /* Resetting the peripherals.*/
  RCC->AHB4RSTR |= mask;
  RCC->AHB4RSTR &= ~mask; // << HERE
  (void)RCC->AHB4RSTR;
}

With call stack being (some weirdness as this is QMK, and not "vanilla" ChibiOS)

Code: Select all

__rccResetAHB4
stm32_gpio_init
__chibios_override___early_init
__early_init


However, as far as i can tell from RefManual, this register doesnt affect the QSPI peripheral. That would be problematic since the .uf2 gets loaded in the QSPI flash, and code would have to send a (sequence?) command to put the flash on MemoryMapped mode....

My understanding is that, since tinyuf2 is managing QSPI before jumping into ChibiOS, i wouldn't need any QSPI configuration (not even enable it on HAL) and code would transparently read addresses on the 0x9000_0000 range as it is already working as desired. Am i mis-understanding anything?

[Giovanni]

ChibiOS resets all peripherals on halInit() so any OSPI setting done before that call is undone internally, you need to perform halInit() before any other peripheral-related initialization.

Giovanni

[elpekenin]

Tried adapting from testhal/STM32/multi/WSPI-MFS, however, even tho i added this (is itwrong? im a mk noob) to my QMK's board.mk file

Code: Select all

include $(CHIBIOS)/os/hal/lib/complex/serial_nor/devices/micron_n25q/hal_flash_device.mk

I can't get my code past

Code: Select all

Compiling: platforms/chibios/boards/WEACT_STM32_H750VBT6/board/extra.c                             platforms/chibios/boards/WEACT_STM32_H750VBT6/board/extra.c:7:10: fatal error: hal_serial_nor.h: No such file or directory
    7 | #include "hal_serial_nor.h"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

Anyway, even if i got this to compile i would have 2 issues:

• My hardware is W25Q64, im guessing i would need to write a specific driver
• Some function would need a __attribute__((section(<RAM>))), because code would stop working (program counter would point at an unreachable address) as soon as QSPI peripheral is shut down, right? No idea which one that would be

---

After this, i've also tried some combinations of

• Commenting out part of the init code
• Changing the GPIO mask used on init, to value 0
• Adding #define STM32_QSPI_NO_RESET
• Setting #define STM32_NO_INIT TRUE

Of course, with no avail