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

NRF_LOG issues

Hi,



I have two strange problems regarding the NRF_LOG.

1.
In a for loop, char string that has changed is not printed out as what it contains now, it is printed out as what is contained at the first cycle of the for loop.

2.
I cannot for some reason print %04X hex values with four digits.
For some reason the log output prints some hex values eight digits long and some four digits long. This happens randomly based on the hex value itself.
I just need to print float values from the log to serial port, however it did not work directly by just with %f and other ways to get it working did not want to work well also, so I decided to go around the problem and convert the float values into strings and display the string instead.

I have this code assigned to a button, it works ok everytime I press the button:

Fullscreen
1
2
3
memset(ConvertFloat,0,sizeof(ConvertFloat));
sprintf(ConvertFloat, "%g", FloatValue);
NRF_LOG_INFO("Value : %s", ConvertFloat);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


The FloatValue in this code is updated all the time by another function and all is fine.

The code is for an accelerometer.
The accelerometer produces 16bit signed hex values which are put in a buffer and I want to print the buffer contents in original hex and converted float values.
The problem is that the hex values get printed ok (but changing length), and the float values get printed once and in the loop where I print out the whole buffer, the float values get stuck in one value and do not change.
When I look how the variable contents work in the debugger, I can SEE that all the float values indeed change when they are calculated from the hex values.
The code works ok and does the calculation and char conversion as expected.
The changed values ARE converted to strings ok, and the strings always change between the loop runs - but for some reason I get the wrong float value from the log output, which is not the actual value the conversion buffers really contain.

This should be impossible in my opinion.
How can a value that is confirmed changed up until log output command, be printed something else in the log?

The loop in question is:

char ConvertFloat_X[20];
char ConvertFloat_Y[20];
char ConvertFloat_Z[20];
uint16_t ValueIndex;

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
char ConvertFloat_X[20];
char ConvertFloat_Y[20];
char ConvertFloat_Z[20];
uint16_t ValueIndex;
for (ValueIndex = 0; ValueIndex < 468; ValueIndex = ValueIndex + 1)
{
Accelerometer_XYZword[0] = Data_Current[ValueIndex];
ValueIndex++;
Accelerometer_XYZword[1] = Data_Current[ValueIndex];
ValueIndex++;
Accelerometer_XYZword[2] = Data_Current[ValueIndex];
// Impact X, Y and Z 16bit word values are now read from buffer, convert to float values
// and output to serial port log.
Accelerometer_X = (float)Accelerometer_XYZword[0]*Accelerometer_Scale;
Accelerometer_Y = (float)Accelerometer_XYZword[1]*Accelerometer_Scale;
Accelerometer_Z = (float)Accelerometer_XYZword[2]*Accelerometer_Scale;
Accelerometer_X = Accelerometer_X - AccelBias[0];
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


Here the Data_Current buffer contains accelerometer data points in signed 16bit values in the order of X, Y, Z, X, Y, Z....

I read those values to a small array of three (Accelerometer_XYZword[]) and convert each value to their corresponding float variable Accelerometer_X/Y/Z.

Then I convert the float values to ConvertFloat_X/Y/Z char buffers.

Then I need to print the hex values and float strings in the log.
What happens is:

All hex values are randomly printed either 8 digits or 4 digits long, regardless of specifically asking only four digits long output.
I get 8 digits long output when the hex value starts with FF and four digits when it starts with zero.
The float values are printed identical in every output run, when they should change according to the corresponding hex value from which the floats are calculated and indeed do contain changed values.

Regardless of actually seeing the real values and their conversion buffers get cleared and changed before every log output - still for some reason I get only one and the same float values, when the corresponding hex value below keeps changing normally.

Can someone see an obvious problem here why this would happen?

Thanks!

Parents
  • Hi,

    It is difficult to make sense of this. If specify to print the hex value as "%08X" (as you do), then you should definitely always get 8 hex characters (zero padded if needed).

    I do not see anything in your code which would explain why you get the same float value printed every time. Can you make a minimal example that demonstrate this and upload the full source code to this case so that we can try to reproduce it? Which toolchain and SDK version do you use?

  • Hi,

    The problem is that if I use %04X, I do not get all four digits long.
    I get values starting with FF eight digits long and others four digits long as asked.

  • What data type is Accelerometer_XYZword? I suspect that is more than 2 bytes long (if so, how would you expect it to work?)

  • It is:

    int16_t     Accelerometer_XYZword[3];

Reply Children
  • Strange... Please let us know which toolchain you use. Can you also print the address of the variables (in case alignment plays a role in this issue)?

  • Hi,

    It seems this is expected behavior. The Logger module documentation has the following statement (which is not easy to spot):

    All arguments are treated as uint32_t.

    The result is that you cannot pass your two-byte variable reliably, as you may get alignment issues. The fix is to either use sprintf or to copy the variable to a uint32_t and pass that to NRF_LOG.