• State Verified Answer
  • Replies 8 replies
  • Subscribers 87 subscribers
  • Views 787 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 350177
Options

nRF52840 SPI3 data corruption at 16 Mhz - anomaly workaround included

Sam-IIT

citing the following issues

 Nrf 52840 SPIM3 slew rate issue at 16 Mhz   RE: nRF52840 BLE causing display glitch on GC9A01 using SPIM 

 SPIM3 tx data corruption, byte carried over from previous operation. 

I've been able to implement the 16 Mhz on the SPIM3. However, the incoming data on the MISO is still corrupted. With my oscilloscope I can see the incoming data is correct. 

I've implemented the CONFIG_NRF52_ANOMALY_198_WORKAROUND in my proj.conf, even thought this config is now enabled by default in the Connect SDK. 

The solution proposed in  RE: nRF52840 BLE causing display glitch on GC9A01 using SPIM is not really clear to me and touching files in the build folder is not ideal. 

Is there any extra anomaly that I might be missing and/or configuration of the SPI3 for speed above 8 Mhz? 

[EDIT]
Apparently the incoming data is shifted by 1 bit to the RIGHT. As I wrote before, is correctly detected by my oscilloscope, but once in the nRF it gets shifted.
This is still an issue since I cannot state the value of the missing right-most bit. CPOL and CPHA are correct by the datasheet on the interfaced device.
Parents
  • 0

    Hello,

    Simon is out of office for a while.

    It is difficult to test without the sensor that you are using.

    1: Does the device work if you turn down the SPI3 speed? 

    2: Does it work if you turn down the speed, and change to another SPI instance (0, 1 or 2)?

    Best regards,
    Edvin

  • 0 in reply to Edvin

    Hi Edvin,

    thank you for your response. I have no issue with other SPIs and everything works fine at 8 Mhz. Right now I just implemented a workaround that shift the data and drop the comparison for the LSB bit. Could this be related to cable length and similar issues?

    The SPI3 is connected to a RHS2116 intan device and uses the nrfx interface.

  • +1 in reply to Sam-IIT

    Bit-shift is likely due to hardware timing issues, very different to byte-corruption due to SPIM3 anomaly issues.

    "Standard four-wire 32-bit SPI interface with CMOS or low-voltage differential signaling (LVDS) I/O pins". If using LVDS_en tied high a 100R termination resistor is required on the digital inputs to the RHS2116 and the differential receive circuit on MISO may be adding a delay. If LVDS_en is tied low is there a single-ended buffer in the MISO path contributing to phase delay?

    In both cases connection wires or traces above 1 or 2 inch should be suspect. Test effect of connection wires or traces by doubling or tripling the connection length of SCLK, MOSI and MISO and see if a further bit shift to the right occurs. If possible test with a connection length of 1 inch or less and see if the bit shift disappears. Yes, not so easy ..

Reply
  • +1 in reply to Sam-IIT

    Bit-shift is likely due to hardware timing issues, very different to byte-corruption due to SPIM3 anomaly issues.

    "Standard four-wire 32-bit SPI interface with CMOS or low-voltage differential signaling (LVDS) I/O pins". If using LVDS_en tied high a 100R termination resistor is required on the digital inputs to the RHS2116 and the differential receive circuit on MISO may be adding a delay. If LVDS_en is tied low is there a single-ended buffer in the MISO path contributing to phase delay?

    In both cases connection wires or traces above 1 or 2 inch should be suspect. Test effect of connection wires or traces by doubling or tripling the connection length of SCLK, MOSI and MISO and see if a further bit shift to the right occurs. If possible test with a connection length of 1 inch or less and see if the bit shift disappears. Yes, not so easy ..

Children
Related
Terms of service