UART printing a lower float value than the debugger is showing.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
user_3678521
Level 3
Level 3
5 likes given First like given

Hello,

I'm printing my TempResult with a snprint(...) function, but it's printing the wrong value. When im debugging i get around 24 degrees, but when i print i Realterm with UART it's printing the value 18. What can be the issue here? I'm printing a float value, and before i could do that i changed the heap to 0x200 and changed newlib-nano float formating to 'True' in build settings.

b1.PNG

b2.png

Thank you.

0 Likes
1 Solution

mads,

Have you had a chance to try if the volatile keyword fixes the discrepancy between the snprintf() output and the debugger value?

The volatile keyword forces the compiler not to store the data in any of the CPU registers.  It is forced to store the result in RAM.

Len

PS:  Bob (user_1377889) informed me of an issue of mine that needed a volatile keyword to solve it.  I was using the same global variable with my main() and a specific ISR.

An issue showed up that I didn't always get the ISR to 'pass' the correct data to main().

Since the variable was shared and the code was optimized, Bob pointed out that the variable was probably stored in a register and never got assigned to RAM.  I took a look at the listing file for main().  He was correct.  He recommended adding the volatile keyword where the variable is defined.  Doing so,  the code then began to work reliably.

Len

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

0 Likes
8 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

mads,

You code looks correct.  I have code that is extremely similar to yours with no float issue.

To verify that the snprintf() and the %f is good, are you using the debugger to breakpoint on line 73?

If you are reading TempResult "live" in your debug session and TempResult is used for immediate calculations, it might reflect different information.  Using the Debugger to break at line 73 allows you to compare the value of TempResult after it gets pushed through snprintf() and before buffer is pushed through UART_1_PutString().

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I think that Len-san's answer is correct.

But in case if you see different values for  TempReult in debugger and printed value,

could you test following formatting?

> snprintf(buffer, sizeof(buffer), "  Temp = %f \n\r", TempReult) ;

< sprintf(buffer, "  Temp = %d.%03d \n\r", (int)TempResult, (int)(TempResult * 1000) % 1000) ;

moto

0 Likes
user_3678521
Level 3
Level 3
5 likes given First like given

This is the full code. Me and my teachers cant find the problem...

b3.PNG

0 Likes

You did not show the complete code. Can you please post your complete project so that we all can have a look at all of your settings. To do so, use

Creator->File->Create Workspace Bundle (minimal)

and attach the resulting file.

Bob

I've uploaded the whole code as you said: https://ufile.io/0gzgs8v7

0 Likes
lock attach
Attachments are accessible only for community members.
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I downloaded your project.

And I disabled the I2C part, since I don't have the I2C device for this project.

Then I connected an external POT to pretend the temp sensor.

I adjusted the value somewhat close to what you were seeing.

IDE debug screen (Debugger says it's 25.4319611)

aaa.JPG

Then the TeraTerm log, it also syas 25.431961, not exact but close enough?

TeraTerm-log.JPG

So I think that your project/program is working correctly, if I2C is not involved.

Meantime, there could be a chance that you are using some old components.

To make sure that components are up to date, I suggest you to update component

from menu Project > Update Components

update_component.JPG

Attached is my modified project, please test it if it still show you a different value(s).

If the values are same, then change

#define USE_I2C 0

to

#define USE_I2C 1

Then try it again.

If the values are not same, probably something with I2C is affecting the result.

moto

0 Likes

mads,

Did moto's recommendation do the trick?

If not, try changing line 26  in main.c  from:

float32 ADC_mVolt, R, R1, V, Vr, SumTemp, TempResult;

to

volatile float32 ADC_mVolt, R, R1, V, Vr, SumTemp, TempResult;


I noticed that sometimes due to code optimizations that a temporary variable gets stored and operated on in a CPU register and never gets place in RAM.  Therefore, it might be possible that TempResult might be located in a register and the value reported in the debugger may not match the snprintf()  output.

Len

Len
"Engineering is an Art. The Art of Compromise."

mads,

Have you had a chance to try if the volatile keyword fixes the discrepancy between the snprintf() output and the debugger value?

The volatile keyword forces the compiler not to store the data in any of the CPU registers.  It is forced to store the result in RAM.

Len

PS:  Bob (user_1377889) informed me of an issue of mine that needed a volatile keyword to solve it.  I was using the same global variable with my main() and a specific ISR.

An issue showed up that I didn't always get the ISR to 'pass' the correct data to main().

Since the variable was shared and the code was optimized, Bob pointed out that the variable was probably stored in a register and never got assigned to RAM.  I took a look at the listing file for main().  He was correct.  He recommended adding the volatile keyword where the variable is defined.  Doing so,  the code then began to work reliably.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes