Home Forums Hardware No data from CM4 ADC chip SPI

Tagged: , ,

Viewing 4 reply threads
  • Author
    Posts
    • craigbealcraigbeal
      Participant
      Post count: 7

      I’m working on interfacing some new sensors (load cells) which required me to use the CM4 ADC subsystem. I had a “bench setup” for this in the past where I used the MCU 5V and a potentiometer to test the ADC system. It worked then (several months ago), but now I am not able to see anything when querying the ADC chip over SPI. The bytes come back either all high or all low. I’ve used both the Simulink test model that I wrote a while ago and a python test script and get the same result. Interestingly, one CM4 gives me the all high bytes and another gives me all low bytes. I did have to re-flash the linux OS on one or maybe both. Is it possible that something isn’t configured properly now? Other ideas?

    • ConnorConnor
      Keymaster
      Post count: 20

      A couple things to try:

      On the MCU side, see if temporarily disabling MCU<>MPU SPI helps, which can narrow down the problem. You can check to make sure that the MCU SPI tristates are set to floating when not transmitting, which will help with interference with other SPI devices on the same bus. The current MCU samples have the tristate setting code in the “System Start” block in the “Hardware Modules Config” subsystem.

      On the MPU side, make sure you’re comparing the CM4s on the same FlexCase to isolate the problem to the CM4. Assuming the two CM4s have different behavior on the same FlexCase, double check that /boot/config.txt has the same GPIO/SPI settings for both CM4s, and try the updated Python script in the ADC guide (checks all channels, may have to change the bus index if using FlexCase 1.1).

    • craigbealcraigbeal
      Participant
      Post count: 7

      Can you post a valid /boot/config.txt for reference?

      I’ve uploaded the current Empty_Project to the MCU after commenting out the MCU-MPU SPI transmission blocks and building it. I used the r1.5 samples, which seems to be different by one line in the System Start block, but I’m not quite sure what “RCM->RPC = 0x1002” does in this context. Other than that, the MCU should not be transmitting, and the MPU is not requesting data over SPI.

      On the MPU side, I did use the two CM4’s in their own individual FlexCase chassis as opposed to swapping them. I had made an ADC check python script very similar to yours (except with the loop unrolled) and I was not seeing anything on any channel, other than the fact that one system gave me all high bytes over SPI (0xFF) and the other gave me all low (0x00). I’ll give the swapping CM4’s a try.

    • ConnorConnor
      Keymaster
      Post count: 20

      “RCM->RPC = 0x1002” Is a stability improvement that prevents large inducive spikes from erroneously affecting the MCU reset circuit. It is good to have in general, but unrelated to this issue. The LPSPI1 register settings in the “Exit” section of the System Start Block are the relevant ones.

      On a FCS1.1 with CM4, the end of the boot config should look like this:

      gpio=4=op,pd,dl
      gpio=45=pu
      dtoverlay=spi1-3cs
      dtoverlay=spi0-2cs
      dtoverlay=dwc2,dr_mode=host

      For FCS1.2 with CM4:

      gpio=20=op,pd,dl
      dtoverlay=spi0-2cs
      dtoverlay=dwc2,dr_mode=host

      • This reply was modified 1 year, 6 months ago by ConnorConnor.
    • craigbealcraigbeal
      Participant
      Post count: 7

      OK, that all makes sense. Confirmed the same behavior (SPI returning 0xFF on both bytes of all channels) on both CM4 boards plugged into the same FlexCase chassis (either chassis). The chassis is not connected to anything when doing this text. The boot config file matches (for an FCS1.1 with CM4). SPI works fine when pulling data from the IMU chip. Next steps?

      • This reply was modified 1 year, 6 months ago by craigbealcraigbeal.
Viewing 4 reply threads
  • You must be logged in to reply to this topic.