Spi-app.c crashes if we just change the repetition Number

I am running on Orin AGX ( Jetpack 5.1.2 ) the demo app to test the SPI ( spi-app.c ).
For 5 times, this app transmits data on the SPI and check received data. I did not short MISO and MOSI so I expect to see “received incorrect data” in the debug printf. What I can see, no problem.
Now if I change the 5 times into 25 times (define SPI_TEST_RETRIES 25) , this makes the system crashes after the 6th retry, in the “middle” of Linux booting… I believe when Linux reaches a certain step, all crashes. I strictly followed the edit of the dtsi files (pinmux, GPIO, firewall )

minicom.cap (58.9 KB)

Hi philippe12,

Are you using the devkit or custom board for Orin AGX?

What’s your use case to change it to 25 times?

What do you mean about “system crashes”?
I can’t find the related crash log in your current provided serial console log.

Have you verified SPI loopback test before?

I am using the dev Kit
I wanted the test to last longer than 5 iterations. The test (spi-app.c) sends “abcd” on spi, expects to recieve the same"abcd" waits for 5 seconds and do it again 5 times. I just want the test to last longer so it continues even after linux is done booting. The test works great 5 times but if it continues longer Linux boot is frozen. ( if you at the minicom.cap) there is an abnormal end. Does no present the login promt because it freezes before.
The only change i made i spi-app.c is the repetition number.

Why would you like to do this?

Maybe the freeze is caused from the delay in spi-app.c due to the SPI retries.
Have you tried to use other value for SPI_TEST_RETRIES between 5 to 25?

I have tried different repeat values
I have tried different delays values between the repeats. ( in that case the test does more repeats before it freezes)
So the freezes happens at the same time after booting.
-1 what kind of conflict can exist between linux when it starts and spi?
-2 is there a way to delay the start of the spe application until after linux is completely done booting? (Ie when the login prompt is presented)?

More information: If I delay the start of the spi-app until after the linux boot is done then the system never freezes and spi-app ( and other concurrent tasks) can work/loop forever.
( I delayed the start of spi by creating the spi_task from another tasks that waits for a timer to create the spi task).
So this leads me again to think that there might a conflict between SPI and Linux booting ? What this could be ?
If you have any idea, that would be super helpful

Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks

Thank you. You can close this one. unrelated to delays I had added “printf” in interrupt handler functions (without knowing they were interrupt handlers).
Thank you to have gotten back to me though.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.