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

Using ble_template example to transfer data

I am using nrf52832, SDK 15.2, Softdevice 6.1, Embedded Studio to program a custom PCB device. My aim is to eventually send data I have from a peripheral device (through SPI) via ble to any mobile app. As of now, for starters, I am trying the send the nrf_gpio_pin_read () data or just random values/strings. I started with the BLE_TEMPLATE example. 

The ble_template example runs (i.e it advertises) on my PCB custom device when I flash it. But when I edit it to incorporate the nus service to send data using nus_data_send() function, the device does not advertise anymore. My code builds and flashes just fine, but there is no data coming from it and it's stops advertising, I am not sure why (I didn't edit the ble_template example much just added a couple NUS things  here and there and add a data_send() function of my own)  

1. I don't get what I am doing wrong in my use of NUS functions that it stops advertising and doesn't send the sample string the way it's supposed to?

2. Is there another way I could go about to transfer a simple string/ int array wirelessly? Without using the NUS service or ble_data_send() function.

I do not use the nus_data_handler() or initialize it in the code because according to my understanding the handler is for data send TO the nrf via ble. 

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/**
* Copyright (c) 2014 - 2018, Nordic Semiconductor ASA
*
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modification,
* are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form, except as embedded into a Nordic
* Semiconductor ASA integrated circuit in a product or a software update for
* such product, must reproduce the above copyright notice, this list of
* conditions and the following disclaimer in the documentation and/or other
* materials provided with the distribution.
*
* 3. Neither the name of Nordic Semiconductor ASA nor the names of its
* contributors may be used to endorse or promote products derived from this
* software without specific prior written permission.
*
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I do not start with the BLE_UART example because the example does not run on my PCB (PCB does not advertise with it) for some reason (I am guessing the uart pins are connected to other things on the custom board). 

Thanks.  

Parents
  • 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:

    Fullscreen
    1
    2
    3
    case APP_UART_COMMUNICATION_ERROR:
    APP_ERROR_HANDLER(p_event->data.error_communication);
    break;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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

  • 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?  

  • 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. 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    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();
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 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?

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

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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. 

  • 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

  • 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. 


Reply
  • 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. 


Children