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.

IWR6843: SPI CS signal behaviour

Part Number: IWR6843
Other Parts Discussed in Thread: LP87745-Q1

Hello Community,

I am working with the custom board where IWR6843 is connected with LP87745-Q1 PMIC via SPI.

When I am trying to write on the PMIC user register on address 0x0A with data 0x9B to unlock the register, I am getting unexpected behavior from CS signal and hence the write is not successful.

After writing 0x9B on address 0x0A I am expecting 0x10EF00 as response on SDO line whereas I am getting 0x101010, which just first byte getting repeated two times. 

I am guessing its because after every 8-bit CS is going high for few micro seconds and thats why maybe PMIC is understanding it as end of transmission and sending again same first byte.

For SPI I am using data size 8 bit here.

Below is the signal pattern observed on oscilloscope 

Expected behaviour from SPI driver when writing to PMIC.

The above diagram is from the complete datasheet of LP87754.

It is the same behavior while reading as well from the user register address.

When using 8-bit data size I could read only the first byte 0x10. Whereas when I use 16-bit data size I could read 0x10EF but not the third byte. The same two bytes get repeated again.

Not sure if it's the problem with SPI driver behavior here.

Thanks and Regards,


  • Hi Neil,

    Can you share the following info so that we can debug this a bit further?

    • mmWave SDK version
    • SPI driver configuration

    Best Regards,

  • Hello Alec,

    Thank you for your reply. 

    1. mmWaveSDK Version:

    2. SPI Driver configuration:

    params.mode = SPI_MASTER;

    params.u.masterParams.bitRate = 1000000U;
    params.u.masterParams.numSlaves = 1;
    params.u.masterParams.slaveProf[0].chipSelect = 0;
    params.u.masterParams.slaveProf[0].ramBufLen = 64U;
    params.u.masterParams.slaveProf[0].dmaCfg.txDmaChanNum =1U;
    params.u.masterParams.slaveProf[0].dmaCfg.rxDmaChanNum =0U;

    params.u.masterParams.c2tDelay = 0x5;
    params.u.masterParams.t2cDelay = 0x5;
    params.u.masterParams.wDelay = 0;

    /* Enable DMA and set DMA channels */
    params.dmaEnable = 1;
    params.dmaHandle = gDmaHandle;
    params.dataSize = 8;

    params.frameFormat = SPI_POL0_PHA1;
    params.pinMode = SPI_PINMODE_4PIN_CS;

    I have used this above configuration of SPI for to for interfacing IWR6843 with  LP87754.

    Thanks and Regards,


  • Neil,

    Your configuration looks fine to me. After digging around the driver a bit, I see that for our devices we set the SPIDEF register to all 1's, which means that the CS value will be set to 1 whenever the SPI module is idle. Perhaps there is a few microseconds after the first byte where the SPI module believes it is idle, and sets the CS value to its default value? 

    In order to debug this, you would need to include the SPI driver into your project and rebuild it. If you want to try this, you would want to modify the following line of mibspi_dma.c 

    You would write the value 0 to this register rather than 7, and see if the behavior changes.

    Best Regards,

  • Hi Alec,

    Thank you for response. I tried what you suggested, but still I have same response. I tried to read from 0x01 user register.

    I sent : 0x011000

    In response I was expecting: 0x10EF96

    But same first byte was repeated two times: 0x101010

    The value I set in mibspi_dma.c


    Thanks and Regards,


  • Neil,

       SPI ports can be pin muxed for other IPs, Is the pin mux is configured for the SPI port?

    Also could you please share the custom board schematic relating to SPI operation, Chip select signal needs pull up on the board.

    Thanks and regards,


  • Hello Chethan,

    I think pull-up might be the problem in our custom board. The CS pin is connected to a pull-down resistor and I think that should be changed to up.

    Thanks and Regards,