BLE and GPIOTE interrupt problem

RE: BLE and GPIOTE interrupt problem

Susheel Nuguru — Mon, 11 Sep 2023 05:12:48 GMT

It is hard for me to say where the bottleneck is Federico.

When you send 0x00CC from board A to board B and you can see on the logic analyzer or oscilloscope that your message is transmitted on the pins but board A did not process it. Then most likely there is something that is executing on board A that is masking the SPI driver.

Start both boards in debug mode and just before sending 0X00CC from board A, set a breakpoint in board B SPI callback handler. When you send 0x00CC then this callback should have been called. But the issue is that it isn't called. So at this instance, pause the debugger to see what context is being executed (top function of the function call stack) and find out the priority in which it is being executed and compare it with SPI driver priority. I am basing all this assuming that you have actually transmitted the byte from BoardA but BoardB isn't receiving/processing it for some reason.

RE: BLE and GPIOTE interrupt problem

FedericoDeSario — Thu, 07 Sep 2023 13:55:54 GMT

When i send 0x00CC from boardA on BoardB seems that i don't receive nothing.
But if I try a lot of times in a little interval I can read on the log of board A that the command 0x00CC has been sended and board A has received 0xFFFF. This is strange becouse the tx_buffer of the SPI on board B is initialized with the word "OK" so it should be always 0x4F4B. And infact it is always 0x4F4B but not when I send the stop command.

Can the problem be this function here?

APP_ERROR_CHECK(nrf_drv_spis_buffers_set(&spis, m_tx_buf, m_length, m_rx_buf, m_length));

I was thinking that probably, when I send the STOP command the buffers of the SPI of board B are not ready to receive data, due to the interrupt that has sended a freme a bit before.

If this is the problem, how can i solve it?

RE: BLE and GPIOTE interrupt problem

Susheel Nuguru — Wed, 06 Sep 2023 06:16:04 GMT

[quote user="FedericoDeSario"]but it seems that che frame 0x00CC is not sended to the board B, because on that side i received always 0x0000[/quote]

Do you receive 0x0000 in Board B when BoardA sends 0X00CC? or you receive nothing on BoardB?

When you send 0X00CC from BoardA and receive 0x0000 on BoardB, then it looks like the SPI pins configuration issue and NOT an issue with priorities.
When you send 0x00CC from BoardA and receive nothing on BoardB (you should confirm with pins connected to logic analyzer that BoardA actually sends this data over SPI lines to BoardB), then we can focus on BoardB only.

RE: BLE and GPIOTE interrupt problem

FedericoDeSario — Tue, 05 Sep 2023 13:48:55 GMT

An important thing that I forgot is that i started from ble_app_uart example, and i added the SPI module (following the SPI example) and the interrupt irq_pin_handler.

[quote userid="6207" url="~/f/nordic-q-a/103442/ble-and-gpiote-interrupt-problem/444455"]I assume that the STOP command from dongle to Board A when through.[/quote]

The code snippet processing the STOP command is the same of the STARTcommand. It is done in the nus_data_handler that i posted as last snippet. I will repost it here:

static void nus_data_handler(ble_nus_evt_t * p_evt)
{

    if (p_evt->type == BLE_NUS_EVT_RX_DATA)
    {
        ret_code_t err_code;

        char dongle_command[BLE_NUS_MAX_DATA_LEN];
        memset (dongle_command,0,BLE_NUS_MAX_DATA_LEN);
        memcpy (dongle_command, p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);
        
        uint16_t cmd;

        NRF_LOG_DEBUG("Received data from BLE NUS. Writing data on UART.");
        NRF_LOG_HEXDUMP_DEBUG(p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);

        /*Processing of BLE command*/
        if(strcmp(dongle_command,"START\n") == 0 )
            {
                cmd = 0x00AA;
                err_code = spiTx_fifo_push(&cmd);
                APP_ERROR_CHECK(err_code);
            }
            else if(strcmp(dongle_command,"STOP\n") == 0 )
            {
                cmd = 0x00CC;
                err_code = spiTx_fifo_push(&cmd);
                APP_ERROR_CHECK(err_code);
            }
            else
            {
              //niente per ora
            }
    }

    //attivo e disattivo led 2 se attivo le notifiche da pc"
    if (p_evt->type == BLE_NUS_EVT_COMM_STARTED)
    {
    	nrf_gpio_pin_clear(LED_2);
    }

    if (p_evt->type == BLE_NUS_EVT_COMM_STOPPED)
    {
    	nrf_gpio_pin_set(LED_2);
    }
}

Due to the fact that the function is the same for START and STOP command, i can't realize why the START command works but the STOPcommand not.

To be precise, if i send firstly the STOP command, it is correctly received by the board A and correctly received by board B.

The problem is after I send the start command, in the board B fsm goes to 1 and board B start to execute the if part relative to fsm == 1.

Trying a lot, i can see over the log of board A that the STOP command is received by the board A (also when is in the IRQ routine) but it seems that che frame 0x00CC is not sended to the board B, because on that side i received always 0x0000. It seems that the IRQ interrupt (so the gpiote interrupt) "wins" over the SPI communication. And this is really strange becouse as we can see, I don't send immediatly the frames (and so also the STOP frame) over SPI but i put them in a fifo and when the board ends all the interrupts it sends in order the data over SPI.

Here the code that manage the SPI sending of data:

static void spi_fifo_process()
{
    uint16_t element;
    uint16_t queue_elements;
    ret_code_t err_code;

    /*Gestione del dato ricevuto via BLE e salvato in m_spiTx_fifo*/

    queue_elements = spiTx_fifo_utilization_get();  //vedo quanti elementi sono nel fifo di trasmissione

    for (int i=0; i<queue_elements; i++)  //invio tutti gli elementi nel fifo via SPI all'FPGA
    {
        err_code = spiTx_fifo_pop(&element); //tolgo un dato dal fifo di trasmissione SPI (verso FPGA) e lo salvo in data
        APP_ERROR_CHECK(err_code);
        spi_tx_buf[0] = element >> 8;        //Ogni elemento del fifo e' da 2 byte ma la trasmissione SPI e' a 1 byte quindi devo spezzare l'elemento in due
        spi_tx_buf[1] = (uint8_t)element;

        spi_xfer_done = false;    //indica che parte la trasmissione (torna true quando alla fine della trasmissione SPI parte l'SPI handler)
        err_code = nrf_drv_spi_transfer(&m_spi, spi_tx_buf, spi_tx_buf_lenght, spi_rx_buf, spi_rx_buf_lenght); //trasmissione SPI (nel frattempo ricevo anche un dato in spi_rx_buf)
        APP_ERROR_CHECK(err_code);

        while(!spi_xfer_done) __WFE();
    }

    /*Gestione del dato rivevuto via FPGA da salvare in m_spiRx_fifo e mandare via BLE*/
    
    if (!ble_tx_active)   //se sto giï¿½ trasmettendo via BLE salto questo blocco
    {
        queue_elements = spiRx_fifo_utilization_get();
        for (int i=0; i<queue_elements; i++) 
        {
            err_code = spiRx_fifo_pop(&element); //tolgo un dato dal fifo di ricezione SPI (da FPGA) e lo salvo in data
            nusTx[i*2] = element >> 8;
            nusTx[i*2+1] = (uint8_t)element;  //ogni due elementi consecutivi di nusTx sono un elemento di data (ovvero un dato da 2 byte ricevuto via SPI dall'FPGA)
        }

        if (queue_elements > 0)  //se effettivamente sono stati ricevuti elementi dall'FPGA
        {
            NRF_LOG_DEBUG("Ready to send data over BLE NUS");

            ble_tx_active = true;        //una volta Ricevuti i dati, setto ble_tx_active su true  che vuol dire che sto mandando dati via BLE (durante la trasmissione BLE ignoro i dati ricevuti dall'FPGA)
            txSize = 2*queue_elements; //la dimensione del buffer che viene inviato via ble (nusTx) e' pari al doppio di quella spiRx (come detto prima)
            txRdPtr = 0;            //Questo dice da dove partire a mandare i dati in ble_data_send (ovviamente parte da zero essendo l'inizio della trasmissione BLE)      
            ble_data_send();    //Si occupa della trasmissione BLE del dato ricevuto via SPI, gestendolo come una notifica che viene mandata via BLE (al controller o dongle) sfruttando il NUS
        }
    }

}

Then this function is called here:

static void idle_state_handle(void)
{   
    spi_fifo_process();
    UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
    nrf_pwr_mgmt_run();

}

(idle_state_handle is the only function in the main loop).

Sorry for the comments in italian.

[quote userid="6207" url="~/f/nordic-q-a/103442/ble-and-gpiote-interrupt-problem/444455"] You need to make sure that the SPI interrupt handler in the Board A is higher in priority than the loop that is toggling the pin.[/quote]

The IRQ prio of the gpiote is set to 7 while the IRQ prio of SPI is set to 5.

RE: BLE and GPIOTE interrupt problem

Susheel Nuguru — Tue, 05 Sep 2023 10:12:52 GMT

[quote user=""]The problem is that when I send the STOP command from dongle to Board A, this seems to be ignored.[/quote]

I assume that the STOP command from dongle to Board A went through. Then it is the matter of finding out if the code in Board A has processed the incoming STOP command. I do not see the code snippet of Board A processing the STOP command. Also I do not see the context in which all these functions are called. You need to make sure that the SPI interrupt handler in the Board A is higher in priority than the loop that is toggling the pin.