If we compile the gpio-app with -O3 it can toggle GPIO 10 times faster. (150ns vs 1.5us)
If we compile the spi-app with -O1 (let alone O3), the SOM fails to boot, and we are stuck…
This usually indicates that code is relying on undefined behaviour, and higher optimization levels are exposing it
Can you reproduce this on your end? And what would be the fix?
Hi akhil.veeraghanta,
What’s your Jetpack version in use?
Could you share the full steps how you compile the spi-app?
and also the full serial console log when the SOM fails to boot?
Jetpack 5.1.2
We compile the SPI app with make -j32 ENABLE_SPI_APP=1 bin_t23x
But in the makefile on line 158 we are changing
-fdata-sections -ffunction-sections -mlong-calls -g3
to
-fdata-sections -ffunction-sections -mlong-calls -g3 -O3
With the same change we can run the GPIO app
make -j32 ENABLE_GPIO_APP=1 bin_t23x
And it runs 10 times faster and continues to boot
Where do you get the spi-app.c?
Do you also setup the CROSS_COMPILE to build this application?
Could you also share your makefile for further check?
This is all coming from the publically available SPE documentation.
Here is the toolchain and fsp with examples:
https://docs.nvidia.com/jetson/archives/r35.3.1/spe/rt-compiling.html
But given that we cannot debug, and the example is bricking the boot process
we have decided not to use the SPE, its very high risk
Thanks!
1 Like