STM32H750 not booting

[elpekenin]

Hello, it's my first time making a post here, so bear with me if i do something wrong/stupid :)
Note: Couldn't find any relevant info looking at the forum nor Discord server

I've bought this dev board (more info about it here) and I'm trying to get it running using demos/STM32/RT-STM32H750XB-DISCOVERY as a base.

I cd'ed into the folder, changed to code to blink the B10 pin, ran make clean && make, and flashed the build/ch.bin file -- Is that right?
But... the LED i've hooked there isn't lighthing up at all.

Board isn't damaged as it came flashed with a firmware that interacted with several peripherals and worked fine. So, there has to be some issue with the code's settings, perhaps something is right for the Discovery board but not quite compatible with this one. Any ideas what/where to look at?

Can't provide further info for now, i've just ordered a STLink so time to wait

[Giovanni]

Hi,

You need to create board files for your board, clock frequencies and GPIO settings are most likely different.

Make a comparison with the discovery schematics.

Giovanni

[elpekenin]

Clock speed matched mine, i just had to `#undef` the `STM32_HSE_BYPASS` thing (thanks sigprof who told me this was problematic on QMK's discord), didn't notice it was on the demo file, it booted now

And thank you too for the reply, Giovanni, of course.

[elpekenin]

Im now trying to get everything correctly configured for my board (https://github.com/WeActStudio/MiniSTM32H7xx/tree/master)

I've downloaded ChibiStudio* to setup alternate functions following the datasheet(note: i manually removed HSE_BYPASS from generated board.h) and im trying to get this flashed using tinyuf2(https://github.com/adafruit/tinyuf2/pull/144).
- Flashed the compiled bin from above PR
- Made an LD file -first time using this, probably something is wrong- such that the only flash section is 0x90000000(where QSPI gets mapped) with size of 8m
- Flashing the uf2 onto the board makes nothing, it just reboots back into uf2 bootloader every single time

My current hypothesis are:
- A problem with the QSPI settings, preventing the MCU from reading memory
- LD being wrong, leading to garbage on memory

Link to my code, sorry for the mess: https://github.com/elpekenin/qmk_firmware/commit/9a47da77858181df3bbc75990e53a0cfeca91845

* By the way, i couldnt get it to generate the files from the chcfg file on windows (didn't report any erros either, tho), and had to install fmpp under WSL to do it, noting just in case there's something broken with the package, and not only a mis-config or mis-use on my end.

PS: This will probably get long, i dont mind taking the convo to discord if you feel like it would be benefitial.

[Giovanni]

Hi,

Make sure things get flashed as you expect. Also consider possible problems with cache, it is not coherent and can cause trouble if not handled correctly.

I am in vacation so no problems for a chat in discord sometime.

Giovanni

[elpekenin]

Hey,

Small updates here (they took embarrassingly long):

• Downloaded STM's IDE and dropped part of my settings, as far as i can tell my clock settings are okay(ish?)
• Modified tinyUF2 a bit, so that it increments a value on the QSPI flash on each reboot, and show it on screen.
  
  • It does work, so both the hardware and (most part of?) tinyUF2's code are fine.
    
  • Value changed upon dropping a .uf2 file on the folder, so it seems like my code is getting dumped to flash correctly
    

So im fairly confidet to say that the issue is on .ld and/or ChibiOS' startup. Next ideas to test:

• Find some useful information via STLink (waiting for delivery)
• Do i need to configure someting to run code off the QSPI?
  
  • Maybe re-initialize/configure the device, but i guess tinyUF2 gets it to the correct state before jumping to user code.
    
  • I could also be missing some config on the MCU to get it reading addresses over 0x9000 0000 through the QSPI, i dont know
    

[Giovanni]

Hi,

If the OSPI is in memory mapped mode you should be able to read flash locations using the debugger at 0x90000000, do you see there what you expect?

Giovanni

[elpekenin]

No debugger yet, made a quick test right now

// same code as before, except changing w25q_read by pointer
uint8_t value = *(uint8_t *)QSPI_BASE_ADDR;
char buffer[10] = {0};
itoa(value, buffer, 10);
print(0, 50, COLOR_BLACK, buffer);

But doesnt seem to work, no idea if user code can also use addresses like that, but i guess/hope so

[steved]

* By the way, i couldnt get it to generate the files from the chcfg file on windows (didn't report any erros either, tho), and had to install fmpp under WSL to do it, noting just in case there's something broken with the package, and not only a mis-config or mis-use on my end.

IIRC you need to make sure that the chcfg file is selected (highlighted) in the left-hand panel before selecting the option to generate config files.

However, I recently tried to generate some config files using the latest ChibiStudio on Windoze, and it didn't work for me - nothing was generated. I didn't pursue it far, partly because my file locations were somewhat non-standard (board file within project, rather than in the HAL library). I just used an earlier verson of ChibiStudio, which worked.

[elpekenin]

> File selected

Yeah, did that, but it didnt spit anything. Neither code nor any error/warning

Read somewhere that it may be due to not having JRE but didnt seem to fix it either (could very well be a user error)


I could try an older release indeed