Using ble_template example to transfer data

RE: Using ble_template example to transfer data

Edvin — Mon, 18 Mar 2019 08:11:30 GMT

Oh. So DRDY is the same as MISO? I base this assumption on e.g. this:
http://www.tij.co.jp/document-viewer/jp/ADS1018-Q1/datasheet/application_and_implementation

[quote user="noob_with_ucontrollers"]The only problem is with the MISO pin (Pin 9) that seems to have a DC of 3.3V[/quote]

Have you defined the MISO pin as an output? I don't understand exactly what you mean. Or do you mean that the sensor is keeping it high? Can you try to measure the voltage between GND and MISO on the nRF (pin 9), and between GND and the data out (MISO? DRDY?) on the sensor?

BR,

Edvin

RE: Using ble_template example to transfer data

noob_with_ucontrollers — Mon, 18 Mar 2019 05:50:14 GMT

My nrf52 is connected to an ADC (ads1220) on a custom made PCB, the NRF is the master. They communicate via SPI. I don't use or initialize DRDY. It does not exist anywhere in the software. From my experience running spi with the adc before, using DRDY is not necessary.

Yes I get proper pulses on the MOSI line (Pin 8), and Clock (pin 7). I checked my DRDY and the ADS seems to be giving out a proper DRDY signal. The only problem is with the MISO pin (Pin 9) that seems to have a DC of 3.3V.... I use MODE_1 because my ADS1220 is compatible with that.

RE: Using ble_template example to transfer data

Edvin — Thu, 14 Mar 2019 10:34:45 GMT

What is your SPI connected to actually? What is DRDY? The nRF is the SPI master, right? Are you seeing any data on the MOSI line? There are 4 SPI modes, usually defined in spi_init(). What mode are you trying? Can you try the other modes as well?

BR,

Edvin

RE: Using ble_template example to transfer data

noob_with_ucontrollers — Wed, 13 Mar 2019 16:19:36 GMT

I put my_data_call() in a loop in the main function like this :

int main(void)
{
   bool erase_bonds;

    // Initialize.
    
//    log_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();
    spi_init(); 
     nrf_gpio_cfg_input(SPI_MISO_PIN, NRF_GPIO_PIN_NOPULL); 
    

    // Start execution.
//    printf("\r\nUART started.\r\n");
//    NRF_LOG_INFO("Debug logging for UART over RTT started.");
    advertising_start();
spi_xfer_done = false;
 


     data_array [0] = 0x78; 
     data_array [1] = 0x79; 
     data_array [2] = 0x86; 
     data_array [3] = 0x65; 
     data_array [4] = 0x76;

//     NRF_LOG_DEBUG("Hi there");
    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
        my_data_call(); 
    }
}


/**
 * @}
 */

I put my_data_call() in a for(;;) loop at the end of the Main right after ide_state(). When I did this to send a random character string , I would get proper data. This is why I kept it in the same place for SPI....

I checked that my SPI_EVENT_HANDLER is called and spi_xfer_done is true...

I cannot use LOG or RTT because calling their functions stops my SPI from working entirely (I stop getting a clock signal on Pin 7 SPI_CSK_PIN). Is there another way I can check my m_rx_buf?

My clock (pin 7 has a clock of 125 kHz), DRDY (pin 10), chip select (pin 6) pins work normally as I see in the oscilloscope. The MISO pin (pin 9) is fixed at a DC HIGH value, 3.3V (not pulsed but DC), and I think that is why I see a fixed "FFFF.."..
I though that maybe pin 9 is being somewhere else, so I configure NFCT_PINS_AS_GPIOS in preprocessor settings, I tried a NOPULL config on MISO as described in this new ticket I started (devzone.nordicsemi.com/.../miso-pin-acting-weird) but these things didn't work.

RE: Using ble_template example to transfer data

Edvin — Wed, 13 Mar 2019 08:28:45 GMT

From where do you call my_data_call()? I suspect that you are seeing some interrupt blocking. Are you getting past while (!spi_xfer_done)? If it moves past, are you getting anything in the m_rx_buf? And if m_rx_buf is not empty, are you getting NRF_SUCCESS on ble_nus_data_send?

RE: Using ble_template example to transfer data

noob_with_ucontrollers — Wed, 13 Mar 2019 02:14:11 GMT

Yes I meant ble_nus_data_send().

I am posting here again as a follow up to my project. I call ble_nus_data_send() in my own custom function which I call in the main loop and it's working great. I started off with the ble_uart example (SDK 15.2). I can initialize random data arrays and the ble_nus_data_send() will send them to the nrf toolbox when I call it.

When I could do that successfully, I added SPI initialization and functions to the example to call data via SPI from an ADC. However, my SPI does not work in this project (I see nothing on the CLK pin ((pin #7), no clock signal) and all I see on my NRF Toolbox app is "0xFFFFF...." no matter what the input to my adc..

Why would the bluetooth project not allow normal SPI functionality? Where does the "0xFFF" come from? My code does build and flash without errors.

void my_data_call () {

// Initialize variables 
        
   uint32_t err_code;
   uint16_t length = (uint16_t)m_rx_length;

   // Call to SPI transfer 
                        
memset(m_rx_buf, 0, m_rx_length);
memset(m_tx_buf, 0, m_tx_length);
spi_xfer_done = false;
m_tx_buf [0] = 0x08;   // Start Conversion command 
nrf_gpio_pin_clear (SPI_CS_PIN);
        APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, m_tx_length, m_rx_buf, m_rx_length));

        while (!spi_xfer_done)
        {
            __WFE();
        }




 //   Call to BLE SPI  !!

 if(m_conn_handle != BLE_CONN_HANDLE_INVALID) {

                        err_code = ble_nus_data_send(&m_nus, m_rx_buf, &length, m_conn_handle);
                        if ((err_code != NRF_ERROR_INVALID_STATE) &&
                            (err_code != NRF_ERROR_RESOURCES) &&
                            (err_code != NRF_ERROR_NOT_FOUND))
                        {
                            APP_ERROR_CHECK(err_code);
                        }

                        }

RE: Using ble_template example to transfer data

Edvin — Tue, 12 Feb 2019 09:34:15 GMT

nus_data_transfer() isn't a function from our SDK? Do you mean ble_nus_data_send()?

I see. Well. You need somewhere to call ble_nus_data_send() from, that is correct. It can either be a button press (GPIO interrupt), a UART message interrupt, a timer timeout interrupt, or whatever you like. When do you want to send data?

RE: Using ble_template example to transfer data

noob_with_ucontrollers — Mon, 11 Feb 2019 15:56:51 GMT

I see. Thank you Edvin.
I think what I meant to ask was that does the nus_data_transfer function work with event interrupts only?
I am getting data from my sensor via SPI module continuously and I am not using an interrupt, I am just requesting data using a sensor read function..., however, I get the feel that since the main () program of the ble_uart example enters idle_state once it starts advertising , you always need an interrupt driven event to prompt a ble_transfer (i.e. the ble_data_send() function).

If I am using the ble_nus_data_send () in the main () program I feel like it won't be called because the main remains stuck in the idle_state loop and the program is advertising continuously. I think I need an interrupt or an event (UART, GPIO or NUS) to call the nus_data_send().... Am I wrong about this?

RE: Using ble_template example to transfer data

Edvin — Mon, 11 Feb 2019 14:41:04 GMT

[quote user="noob_with_ucontrollers"]I also had another question, the uart_evt_handle () function is called in case a uart event occurs and the nus_data_handler is called when data is received via BLE right? [/quote]

That is correct.

[quote user="noob_with_ucontrollers"]Can we send data via ble using the nus_data_handler? [/quote]

Yes you may. Just add ble_nus_data_send(...) in your event handler, or wherever you want to send data from.

RE: Using ble_template example to transfer data

Edvin — Mon, 11 Feb 2019 14:40:01 GMT

Hello,

It seems that you are trying to send 0x01, 0x02, 0x03, while text strings are using ascii characters.

Check out this table:

http://www.asciitable.com/

The ascii value for '1' is 0x31, '2' is 0x32 and '3' is 0x33. Try to send these values, and you should see that it says: '123' received.

For good measure you can add 0x0D0A at the end (carriage return and linefeed, which is typically added on the end of these lines. This is equivalent to pressing "enter").

I also see that you use &length which is the size of the array. You may of course do this, but there is no point in sending the entire array if you actually only send 3 characters. Try setting it to 3 (or 5 if you add 0x0D0A at the end).

Best regards,

Edvin

RE: Using ble_template example to transfer data

noob_with_ucontrollers — Mon, 11 Feb 2019 02:01:15 GMT

I also had another question, the uart_evt_handle () function is called in case a uart event occurs and the nus_data_handler is called when data is received via BLE right?
Can we send data via ble using the nus_data_handler?

RE: Using ble_template example to transfer data

noob_with_ucontrollers — Sun, 10 Feb 2019 18:38:56 GMT

Hi Edvin, thank you very much. Your diagnosis about the problem being with uart pins and the uart data send failing and causing a crash is correct. I tried commenting out //uart_init() from main and then changing the HCI_UART_RX_PIN_NUM and HCI_UART_TX_PIN_NUM in the sdk_config.h (there were no other uart_pin definitiions in the sdk_config.h file) but when these two things didn't work I commented out the APP_ERROR_HANDLER(p_event->data.error_communication); from the APP_UART_COMMUNICATION_ERROR event. This last thing worked and my PCB device started advertising!! So I guess the program was stuck in an error handler event..

I am now trying to use the uart_evt_handle () function to send a random string/number via BLE to the mobile app instead of getting data from the uart. This is how my edited function looks like.

I do not get the string/random number on the App though.

This is what I get on the RTT log:

And this is what I see on the NRFToolbox Nordic Uart android phone app I am using:

It connects to the device but don't think it's sending the int array ""123" correctly. If you have any suggestions please let me know!

Finally, I wanted to ask you where I could read more about APP_ERROR_HANDLER and _DEBUG use?
Again, thank you very much Edvin for being helpful!

RE: Using ble_template example to transfer data

Edvin — Fri, 08 Feb 2019 15:37:55 GMT

Hello,

Ok, so from the other thread that you posted on, you mention that you use Segger Embedded Studio, so the IDE will flash the softdevice for you. This is not the problem, then.

Since the ble_template example runs and advertises, then it seems like your pcb has an external LFXTAL. (I am just mentioning this because many PCBs don't, and that is a possible cause of the issue when the BLE examples doesn't advertise).

So, that leaves it to be related to the NUS service or the UART.

I suggest that you get familiar with our debugging system, or error_handler.

My bet is that one place in your code you have an APP_ERROR_CHECK(err_code) with an err_code != 0 (==NRF_SUCCESS).

Is it possible for you on your PCB to monitor the logging? In the ble_app_uart example that would be the RTT log, which you can monitor in Segger Embedded Studio.

It probably just writes "Fatal error" at the end of the log, but if you define DEBUG in your preprocessor defines, it should give you the file name, line number and err_code that caused the error.

My guess, if you are running the ble_app_uart example, is that you get a communication error on the physical uart:

        case APP_UART_COMMUNICATION_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_communication);
            break;

You need to either set the UART RX pin to a pin that isn't floating (not connected to anything). This can cause this error. Alternatively, if you don't use the UART, just comment out uart_init() in your main() function.

Or the last option is to comment out APP_ERROR_HANDLER(p_event->data.error_communication); from the APP_UART_COMMUNICATION_ERROR event.

If this is not the problem, then you need to check your log for info on where the error comes from.

Best regards,

Edvin