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]

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.

[haakonsh]

According to FPU instruction set table, a float division takes 14 cycles.

From Table of processor instructions a signed/unsigned division takes 2-12 cycles. 
"Division operations terminate when the divide calculation completes, with the number of cycles required dependent on the values of the input operands. Division operations are interruptible, meaning that an operation can be abandoned when an interrupt occurs, with worst-case latency of one cycle, and restarted when the interrupt completes".

A modulo operation uses a divide operation to determine the remainder of a division. If you use the modulo operation with integers as the base of your timing you will have a very very bad day. 
In general, if you're using calculations where the operands are known at compile-time the compiler can, depending on its optimization settings and abilities, run the calculation at compile time and store the output as constants. There are other ways to optimize too. 

Again, if you rely on SW execution to time HW operations you will have a very very bad day. 

There are 4 TIMER's and 2 RTC's available to the application, I suggest you use one of them to time your HW operations. The examples we use often includes the Timer library. You can create another app_timer to control your serial communications.