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 )
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.
-Philippe
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
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.