SPI problem with nRF52832 and MPU-9250

RE: SPI problem with nRF52832 and MPU-9250

arne — Mon, 27 Jun 2016 10:03:53 GMT

This did the trick! I'm now able to talk to the MPU-9250 over SPI.

RE: SPI problem with nRF52832 and MPU-9250

Øyvind Karlsen — Mon, 27 Jun 2016 08:01:53 GMT

Using pins 9 and 10 will cause issues as they are default NFC pins, please see this answer for how to unset them. Sorry for not noticing this earlier, I was copy pasting your code, but didn't change the spi_config from the one from my previous answer. As long as you change pins 9 and 10 (sck and mosi) your code compiles and runs successfully on the nRF52 DK, both using Keil and GNU make utility under Windows.

RE: SPI problem with nRF52832 and MPU-9250

arne — Fri, 24 Jun 2016 13:01:55 GMT

What exactly do you mean by SPI events? If you ask whether or not the spi_event_handler is ran, the answer is no. I believe the code is getting stuck at «__WFE();», waiting for events that isn't happening.

I'm compiling on linux using armgcc. Simply by running «make» in the armgcc folder, and I flash the board with «nrfjprog --chiperase --program nrf52832_xxaa.hex && nrfjprog --reset -f nrf52»

My LEDs are active high.

I have not done any changes to nrf_drv_config.

RE: SPI problem with nRF52832 and MPU-9250

Øyvind Karlsen — Fri, 24 Jun 2016 12:09:20 GMT

Are you getting SPI events now?

What toolchain are you using?

Are your LEDs active high or active low?

Have you done any changes to the nrf_drv_config file found in \examples\peripheral\spi\config\spi_pca10040

RE: SPI problem with nRF52832 and MPU-9250

arne — Thu, 23 Jun 2016 15:54:21 GMT

Great answer, but still not much luck. See the original post for the latest update.

RE: SPI problem with nRF52832 and MPU-9250

Øyvind Karlsen — Thu, 23 Jun 2016 13:46:59 GMT

Hi,

If you are using the nRF52 DK be aware of a couple of things, LEDs are active low. Pins 7 and 8 are used as CTS and RXD in the UART module and 9 and 10 are used in the NFC module.

Since the event handler is never called it is likely that either initialization or transfer fails, the event handler will be called even with no SPI device connected. To monitor this you can use APP_ERROR_CHECK along with the information from this post to find which error you are experiencing.

Doing this we find that both nrf_drv_spi_transfer sometimes fail with the return code NRF_ERROR_BUSY, this happens when the transfer function is called before the previous transfer is finished. When you get a returncode with APP_ERROR_CHECK that is different from NRF_SUCCESS and DEBUG is not defined in the list of preprocessors your application will reset.

Try the following code:

void spi_event_handler(nrf_drv_spi_evt_t const * p_event)
{
    nrf_gpio_pin_toggle(17);
    nrf_delay_ms(200);
}

int main(void)
{
    nrf_gpio_cfg_output(17); // CH1, LED used for debug

    nrf_drv_spi_config_t spi_config = {
        .sck_pin        = 13,
        .mosi_pin       = 12,
        .miso_pin       = 11,
        .ss_pin         = 10,
        .irq_priority   = 3,
        .orc            = 0xFF,
        .frequency      = NRF_DRV_SPI_FREQ_125K,
        .mode           = NRF_DRV_SPI_MODE_3,
        .bit_order      = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST,
    };

    uint32_t err_code = nrf_drv_spi_init(&spi, &spi_config, spi_event_handler);
    if (err_code != NRF_SUCCESS)
    {
        nrf_gpio_cfg_output(18); //Initialization failed, light LED as warning
    }

    while(1)
    {
        while(nrf_drv_spi_transfer(&spi, m_tx_buf, 1, m_rx_buf, m_length) != NRF_SUCCESS)
        {
            nrf_delay_ms(200); //Wait for the previous transfer to finish
        } 
        __WFE();       
    }
}

I also removed the calls to NRF_LOG_PRINTF which will not work unless you initialize the UART module, and changed to different pins. Note that using nrf_delay_ms is not a good way to wait in a final application. nrf_delay_ms uses __NOP to keep the time, this means that the CPU is active causing high current consumption. Implementing a timer is a better solution, for example by using the application timer as shown in this tutorial.

Best regards,

Øyvind

RE: SPI problem with nRF52832 and MPU-9250

arne — Thu, 23 Jun 2016 10:53:43 GMT

Hmm no, it doesn't seem like I get SPI events. My breaking point inside the spi_event_handler isn't triggered.

RE: SPI problem with nRF52832 and MPU-9250

Øyvind Karlsen — Thu, 23 Jun 2016 10:25:51 GMT

Hi,

Are you getting SPI events? Try setting breakpoints inside the spi_event_handler and see if they trigger, if so, just add a delay before nrf_gpio_pin_clear(3);. The current implementation will set and then immediately clear the pin.