Why different behavior with same hex file on stm32g474vet6?

[MRibb.1]

I'm new to stm32 programming, but have experience with other complex low level drivers. I'm looking for ideas because I'm confused by this issue.

I hired a contractor to write code to view a few sensors, monitor a few rotary encoders, and use a 320x240 1 bit lcd using SPI (he used the lvgl library for this) since I'm not familiar with stm32.

This seem to work pretty well on his system. However, when I load his hex file (or build it myself) it runs around 100x slower, and has a few other minor issues that don't seem related to performance, but maybe they are? It mostly works, like the encoders are working, sensors are giving reasonable values, but one encoder doesn't work and the fps of the screen is about 0.3 instead of 30. I've seen a video of his device and it works well.

We both have multiple programmers (I'm mostly using the official st link v3), and both have multiple copies of the pcb with the stm32 chip.

I did use HAL_RCC_GetSysClockFreq to check the frequency and it reports the correct 160 Mhz. I also checked the timing of the main program loop and it was going through that code quickly. The main thing that runs outside that loop is the display via lvgl. I did try turning off the display completely and that made my encoders fast. Maybe this points towards a misconfigured SPI port or something (perhaps due to undefined registers), but checking all that will take me awhile since I'm new to stm32.

Is there something I could setup incorrectly on my computer to make it slow? It seems like this is pretty minimal since I see the problems even when using his hex file that works for him.

Are there some registers I should check on the hardware? I would hope if we both clear the chip and then program it using the same hex file that we'd get the same behavior, but we are not.

In my past job we would have had ways to dump the state of the hardware and look for diffs, but I don't know of anything like that for stm32.

Right now I'm kind of just going to at the code for undefined registers to setup hardware we might be using, but that will be a painful process since I don't know much about stm32 hardware. If you have any ideas on better ways to look at this, or things I might be missing please let me know.

Thanks!

[Tesla DeLorean]

Check the clock and PLL settings.

If the external clock is missing, or otherwise fails to start, the MCU will keep running at a slower HSI/MSI clock it started with. If one clock doesn't start this can cascade into failure to start the PLL.

Watch the external crystal, and that HSE_VALUE is consistent with this clock's speed.

Instrument the code, output something in Error_Handler() or HardFault_Handler() even if it's toggling a GPIO/LED

The debugger should provide a Peripheral View of the registers.

The registers for the peripherals exist in memory, you can read the content and print to the screen or serial terminal.

[MRibb.1]

Thanks for these suggestions. I've started looking into these, but there is a lot of things related to these that I need to learn to understand them so it will take some time.

[FBL]

Hello @MRibb.1 

Which STM32 product you are using? So far, as mentioned you can start by checking the clock being used, then you may need to probe the clock on MCO. You may need to dig deeper into your hardware setup. Providing more details about the issue would help to locate the fault.