This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BEAGL-BONE-BLACK: SPI problem

Part Number: BEAGL-BONE-BLACK

Hello,

we are trying to use a BELA audio cape with a BB and are writing our own code to test the ADC on board the cape (AD7699). We are using the PRU to synchronize timings and are seeing some issue with the SPI bus. The same code has worked previously on the Pocket beagle and Bela Mini hence we are not sure what is going on.

To summarize the problem, we can trigger the ADC conversion correctly and see correct data for maybe 10 seconds. After that the SPI bus just shuts off. We are not sure if the problem is with the Sitara or with the ADC chip. I am attaching two screenshots from our Oscilloscope. In the first, the pink impulses are the conversion triggers (approx 3µs). The blue curve is the SPI clock (1.5 MHz). We are reading 16 bits from the ADC. The yellow curve is the MISO signal. Here is where it gets a bit interesting. One can notice that the MISO bus changes behaviour after some transmissions. Why does it do that? I am guessing that the MISO pin is tristated by the Sitara when reading and after the transmission is over, the ADC releases this pin, thus we see the slow rising bus. In most cases though it looks like one of the two parties keeps driving the MISO pin where it shouldn't be. Could this cause the SPI to crash?

Is there any register that I can observe to detect what is going on?

The second image shows that the MISO pin is trying to send something but is unable due to the missing clock.

Any ideas or suggestions are welcome!

  • The MISO pin is receiving data from the ADC and therefore should be configured as an input. Therefore it is the ADC that is driving the signal. Does the ADC release the pin when not driving (I assume yes).

    For the second issue, look for errors in the SPI status registers (assuming AM335x is the controller). 

    Review the padconf register settings for the both the SPI CLOCK and MISO pins before and after the the change in behavior

    --Paul 

  • I think I have an explanation for the MISO behavior. When the last bit is 1, the pin release is not visible but when the last bit is a 0, we can see the voltage on the pin recover to 3.3V. I am now wondering why my SPI stops transferring after some time?

    I will have a look at the padconf register settings and post here if I find something.

  • I would like to quickly update this topic. After debugging a lot of registers and finding nothing, we debugged the CH0CONF and found out that our SPI configuration was being overwritten by another program in the background which caused our SPI communication to crash. After stopping this rogue application, all works well.