Simple BLE example crash when using floats

[danielco68]

Hi Nordic Devzone,

I am using the simple BLE blink peripheral example that simply advertises and blinks an LED. I am using the ble_app_blinky_pca10040_s132 example found in the SDK

I have added the following lines of code in the infinite loop in main

float a = 1.0f;
float b = 2.0f;

float c = a / b;
NRF_LOG_INFO("c = %f", c); 

When I run the code, I get c = ----blank----- printing out over and over very fast.

Why does this issue occur?

Any help would be appreciated.

[Turbo J]

Did you bother reading the documentation for NRF_LOG module at all?

"Due to certain limitations, logging a float requires you to use the following dedicated macros: "

NRF_LOG_INFO("float value:" NRF_LOG_FLOAT_MARKER "\r\n", NRF_LOG_FLOAT(val))

Note to NRF: The html in the infocenter (at least for SDK16.0.0) uses „fancy” string formatting - which is not valid C syntax.

[danielco68]

OK, but this test was to try and figure out another problem.

In my infinite loop, a float number is calculated  if a certain condition holds, and prints out the contents of a list whenever the counter is a multiple of 500 (used to slow down the volume of serial output)

The code runs fine before ranging is true. The list prints out at a consistent speed in the serial output. However, once ranging becomes true, and the float value is calculated, the serial output is filled exponentially more quickly, as if the loop is somehow running "faster". The float value itself can be seen properly, but something seems to have gone wrong.

I have isolated the issue to solely the line that calculated the float. If that line is commented out, the program continues to print out at a consistent rate.

HOWEVER, this issue persists if the calculation is literally anything with floats, such as 1.0f/1.0f.

The calculation is the following, 

tof = ((rtd_init - rtd_resp * (1.0f - clockOffsetRatio)) / 2.0f) * DWT_TIME_UNITS;

where tof is a double, and the rest are ints and floats.

I have the following code in my infinite while loop:

if(ranging){
    //Calculation of float occurs up here
    
}

if(count % 500 == 0){

    print_neighbour_list();

}

count++;

[haakonsh]

Turbo J said:

Note to NRF: The html in the infocenter (at least for SDK16.0.0) uses „fancy” string formatting - which is not valid C syntax.

Can you show us an example? 

[haakonsh]

Well first off you really need to use either an RTC or TIMER to control anything timing related. If you rely on SW execution as a timer you're gonna have so many issues trying to keep the timing stable whenever anything changes with regards to code or build environment. And why do you need to time the uart transmissions at all? 

For your specific issue, What don't you show us more of the code? What determines the frequency of the "timer"?

[danielco68]

Our real issue is why the serial printout seemingly ignores the %500 after ranging becomes true, and the amount of serial output grows much faster. We commented out everything but a 1.0f/1.0f calculation inside the if(ranging), and that results in the same issue. However, when we do a normal int division, the issue doesn't arise.