This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

No MISO Responce

Hello, support team:)

Currently I am working on SPI communication with LSM6DSOXTR.

CLK, MOSI, SS is working as expected. But there is no MISO signal.

0) All SPI PIN is configured as NRF_PIN_DISCON_NOPULL

1) SPI Read function

static int32_t lsm_read(void *handle, uint8_t reg, uint8_t *bufp, uint16_t len)
{
ret_code_t err_code;
uint8_t s_tx_buf;

s_tx_buf = (reg | 0x80); // MSB 1 --> Read

spi1_xfer_done = false;

err_code = nrf_drv_spi_transfer(&m_spi_lsm, &s_tx_buf, 1, bufp, len);
RETURN_IF_ERROR(err_code);

while (!spi1_xfer_done)
{
__WFE();
}

return DRV_ACC_STATUS_CODE_SUCCESS;
}

2) WHO AM I register is 0x0FU. 

It becomes 0x8F(MSB to 1: read). And It sent to MOSI.

And 16 bit clock is created correctly.

But there is no MISO signal.

Parents
  • Hello,

    Read function is updated. Now WHO_AM_I is read correctly.

    But It seems like write function doesn't work correctly.

    I wonder why delay should be done between each 8 bit in read function?

    And how could I fix write function?

    static int32_t lsm_write(void *handle, uint8_t reg, uint8_t *bufp, uint16_t len)
    {
        ret_code_t err_code;
        uint8_t s_tx_buf[I2C_TX_LEN_MAX];
        uint8_t i;
    
        // Data to send: Register address + contents.
        s_tx_buf[0] = (reg ^ 0x80);
        memcpy(&s_tx_buf[1], bufp, len);
        
        nrf_gpio_pin_write(PIN_LSM_SPI_SS, 0);
    
        //spi1_xfer_done = false;
    
        //err_code = nrf_drv_spi_transfer(&m_spi_lsm, s_tx_buf, len + 1, &no_use, 1);
        //RETURN_IF_ERROR(err_code);
    
        //while (!spi1_xfer_done)
        //{
        //    __WFE();
        //}
        
        nrf_delay_us(5);
    
        for(i = 0; i < len + 1; i ++)
        {
            spi1_xfer_done = false;
    
            err_code = nrf_drv_spi_transfer(&m_spi_lsm, &(s_tx_buf[i]), 1, NULL, 0);
            RETURN_IF_ERROR(err_code);
    
            while (!spi1_xfer_done)
            {
                __WFE();
            }
        
            nrf_delay_us(1);
        }
        
        nrf_delay_us(5);
    
        nrf_gpio_pin_write(PIN_LSM_SPI_SS, 1);
    
        return DRV_ACC_STATUS_CODE_SUCCESS;   
    }
    
    static int32_t lsm_read(void *handle, uint8_t reg, uint8_t *bufp, uint16_t len)
    {
        ret_code_t err_code;
        uint8_t s_tx_buf;
        uint8_t read_temp[I2C_TX_LEN_MAX] ;
        uint8_t i;
    
        s_tx_buf = (reg | 0x80);
        
        nrf_gpio_pin_write(PIN_LSM_SPI_SS, 0);
    
        nrf_delay_us(5);
        
        //spi1_xfer_done = false; 
    
        //err_code = nrf_drv_spi_transfer(&m_spi_lsm, &s_tx_buf, 1, read_temp, len+1);
        //RETURN_IF_ERROR(err_code);
    
        //while (!spi1_xfer_done)
        //{
        //    __WFE();
        //}
    
        //for(i = 1 ; i < len + 1 ; i ++ )
        //{
        //    bufp[i-1] = read_temp[i] ;
        //}  
        
        spi1_xfer_done = false; 
    
        err_code = nrf_drv_spi_transfer(&m_spi_lsm, &s_tx_buf, 1, NULL, 0);
        RETURN_IF_ERROR(err_code);
    
        while (!spi1_xfer_done)
        {
            __WFE();
        }
        
        nrf_delay_us(10);
        
        for(i = 0; i < len ; i ++ )
        {   
            spi1_xfer_done = false; 
    
            err_code = nrf_drv_spi_transfer(&m_spi_lsm, NULL, 0, &bufp[i], 1);
            RETURN_IF_ERROR(err_code);
    
            while (!spi1_xfer_done)
            {
                __WFE();
            }
        
            nrf_delay_us(1);
        }
        
        nrf_delay_us(5);
    
        nrf_gpio_pin_write(PIN_LSM_SPI_SS, 1);
        
        return DRV_ACC_STATUS_CODE_SUCCESS;
    }
    

  • What is the context in which you are calling lsm_read? probably the answer to that question might give some hints as to why replacing __WFE with busy delay helps in your case. I have not seen into the timing requirement of your sensor.

    5us delay does not look bad in a lower priority threads, so if it works, keep it.

Reply Children
No Data
Related