https://github.com/lvgl/lv_port_stm32h745i_disco => to stm32h750b disco

[pk84]

I am trying to get the https://github.com/lvgl/lv_port_stm32h745i_disco to run on the STM32H750 instead of the H745 disco.

I have selected the external loader and at startup the corresponding project loader. In the main.c file of the disco port project I have removed the QSPI inits.

I replaced the linker script file with the content from the linker script of LTDC_Paint example for the STM32H750.

It compiles and flashes everything without errors, but nothing works, also no LED starts.

What else do I have to adjust or should I consider?

[Pavel A.]

How do you expect the program to access the external flash after removal of QSPI init?

Have you tried to debug? 

[Tesla DeLorean]

Perhaps by doing the external memory initialization earlier, and in a loader, so as not to repeat, nor teardown the environment it's already executing in? H750 supposedly only has 128KB of FLASH

[pk84]

see screenshot below of my setup.

the lv_port_stm32h745.. project is loaded on the external QSPI flash (with external loader), so of course it does not need any QSPI init.

In the internal flash I load the STM32H750B_DISCO project, which is the program that makes the QSPI init + jump to the main program on the QSPI.

This internal flash program I already tested with another project (LTDC_Paint) and it works fine...

So that with the QSPI, external loader I should have considered, have I forgotten anything else?

I have no error, but even though nothing happens, no LED blinking, nothing...

[Tesla DeLorean]

Check the .LD file is building for the right memory space.

That SystemInit() points SCB->VTOR to the basis in memory where the vector table resides. Ideally use a symbol so that it just inherits the basis the linker is using auto-magically, instead of the stupidity ST uses..

extern uint32_t *__Vectors; // KEIL

SCB->VTOR = (uint32_t)&__Vectors;

extern uint32_t *g_pfnVectors; // GNU/GCC

SCB->VTOR = (uint32_t)&g_pfnVectors;

[Pavel A.]

Won't it be a good idea to copy the vectors to internal RAM?

[Tesla DeLorean]

One could certainly have a carve out space and do that.

One could perhaps have a block of code/data that gets migrated to ITCM and DTCM RAM for efficiencies sake, that the QSPI based startup.s deploys. The QSPI should be cacheable.

As a "can I build it and run it" test, probably not immediately necessary, and adds complication.

The general philosophy I've pushed is that the boot loader should do the bulk of the rough startup work to get the PLL's, clocks and external memories viable, and then transfer control to the external QSPI code, which then doesn't tear down the prior configuration, but is additive in terms of peripherals, and functionality.

And the linker should do it's job, without random defines in the code for stuff the linker manages symbols for directly, in its primary role.

[pk84]

as mentioned in the beginning, I replaced the linkerscript content of the lv_port project (STM32H745XIHX_FLASH.ld) with the content of the linker from the LTDC_Paint project STM32H750XBHx_FLASH.ld.

The LTDC_Paint project I could already test on external QSPI, and it works... so I assume the the linkerscript content should be correct, or is this wrong?

But maybe something is wrong in the lv_port project, so I tried to load this project first to the internal (128kB) flash and test it.

I have commented out as much as possible and only added a LED blink function.

Unfortunately I get the following error message when loading.

 

[pk84]

Could it be that the sysclock configuration of the STM32H745 is different from that of the H750?

[pk84]

ok, I forgot to change to internal flash in the ld-script, because of that I got the Error above.

So the lv_port program looks ok, at least the blink part... but I have no chance to make it work on the external flash - still nothing happens?? But no error.. how can I debug this? Or can somebody port this lv_port H745 to H750 for me?

--- edited by moderation team to ensure adherence to our community guidelines ---