Setting appcore to 128 MHz before SPI init

[Joost Voorhaar]

So, we have an application running on a nRF5340, using an LCD connected to SPIM4. The project uses Zephyr + LVGL.

We want to speed up communication to the LCD. At boot time, the app core runs at 64 MHz, causing SPIM4 to run at 16 MHz. I can set it to 128 MHz in main(), but at that point SPIM4 already is initialized by Zephyr. I checked using a test app and nrfx and setting the core speed to 128 MHz indeed speeds up SPIM4 to 32 MHz.

Is there a way to set te app cpu to 128 MHz before main() starts?

[Kazi Afroza Sultana]

Hello,

You can try to run initialization fuction https://docs.zephyrproject.org/3.1.0/kernel/drivers/index.html#c.SYS_INIT at boot with specified priority.

Thanks.

Best Regards,

Kazi Afroza Sultana

[Joost Voorhaar]

Thanks. Tried that, but it seems there's a qspi driver that actually throttles the speed down to 32 MHz.That's horrible behavior... are you guys aware of any other parts where it is throttled down?

[Kazi Afroza Sultana]

Hello,

Could you please share your code so we can try to reproduce the issue?

[Joost Voorhaar]

I cannot send the whole project for obvious reasons.

However, check qspi_init(), qspi_nor_init() and qspi_unlock() in ~/zephyr/drivers/flash/nrf_qspi_nor.c. They just force the system to fall back to 32 MHz. IMHO, the driver should check the used clockspeed and restore it when done, not just set it to 32 MHz.

It looks like locking and unlocking are mixed up. qspi_lock() sets the driver to BASE_CLOCK_DIV and qspi_unlock() switches it back to a hardcoded NRF_CLOCK_HFCLK_DIV_4

See also github.com/.../nrf_qspi_nor.c

[Kazi Afroza Sultana]

You can override this behavior by calling nrf_qspi_nor_base_clock_div_force (sdk-zephyr/nrf_qspi_nor.h at main · nrfconnect/sdk-zephyr · GitHub).

[Joost Voorhaar]

Works, thanks!