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.

AFE4403 SPI

Other Parts Discussed in Thread: AFE4403, AFE4403EVM

I'm having trouble getting the communicating with the AFE4403 over SPI. I have tied AFE_PDNZ and RESETZ high, and not worrying about ADC_READY right now. I'm just trying to get register reads from the device. I write {0x0 0x0 0x0 0x1} to the AFE4403 which I assume means write to the control register SPI Read. Then the next Byte I assume means which register, and I believe the next 3 sets of 8 clocks should correspond to the data from the register. I see the correct data going out of SIMO but I get no response ever over SOMI

I probed the EVM and the ENABLE remains low in 4 Byte segments where all my read/writes pull low for each Byte. The setting the SPI Read bit leaves SIMO high until the 5th Byte too. Is there something that I have to change from the standard SPI setup to get basic communications running?

Thanks,

j

  • Jeff,

    We have received your post and hope to have a response back to you soon.
  • Jeff,

    Would it be possible to see a scope capture during your SPI communication? It would be great if you could capture all of the signals.

    Clarification: Are you using our EVM our your own application? If you are using you own, could I see your schematic?

  • Hi Amy,

    Here's the SPI connections that I've probed on the AFE4403EVM board

    Yellow = Enable

    Green = Clock

    Blue = MOSI

    Purple = MISO

    I believe MOSI says 0x0 0x0 0x0 0x1 0x1 0x0 0x0 0x0 ( write register 000 (control register) 1 (read spi bit of control register) 1 (register number) then clock out response

    I think the particular SPI implementation leaves the final bit whatever way it was to get the behaviour between clocks

    Here's my implementation from a different MCU

    I've held enable low and written out 0x0 0x0 0x0 0x1 0x1 0x0 0x0 0x0 I have never received anything on MISO. AFE_PDNZ and RESETZ are high. Is there anyway to force something out MISO?

    j

  • Hi Amy,

    in regards to a schematic, I can't cut and paste our board. We have a microcontroller with the Enable, SIMO, MOSI and CLOCK going directly to the AFE4403 without and pull-ups/downs. . . We have AFE_PDNZ pulled high, RESETZ pulled high and ADC_READY pulled low. I've noticed from probing the EVM that the introduction of the probes sometimes shifts the register read. Without probes Device Configuration --> Read LED2STC --> 0x001730 but with probes 0x000BE0. I've gone back to a breakout board with 3.3V and 5V level shifters without responses on SOMI.

    Thanks,

    J

  • Hi Amy,

    I've now gone as far as tombstoning the jumper resistors on the SPI lines for the AFE4403EVM  (R31, R29, R35, R33) and attaching them to out microcontroller. Still without any luck. If I attach the SFH7050 to this hacked EVM what do I have to write to turn the red LED off so I can check the writes are correct?

    j

  • Jeff,

    Is there any reason you are holding enable low the whole time? The device is looking for the falling edge of the enable, so you will not be able to see anything if it is held low all the time. For the first command you need to start high and go low on the enable line.
  • Hi Amy,

    I was just trying whatever I could, since I still can't find whether the message latches on the falling edge or takes the last 32 bits from the rising edge on the datasheet. My MCU's SPI hardware pulls CS low EVERY byte. But that's neither here nor there as I will toggle a GPIO. The core problem was a board problem (there were digital pots on the same bus that worked fine so I thought it was the AFE4403) that I couldn't deduce until now, so I went trying to match the EVM which led to a rabbit hole because probing the SPI lines changed the digital reads then trying bitbanging.

    You should probably delete this entire thread. Sorry for taking your time

    j
  • Jeff,

    No problem. Thank you for updating us.