NCS v1.2.0 does not work using sscanf and printf for uint64_t

[Giannis Anastasopoulos]

Dear All,

i am using NCS v1.2.0 and the GNU ARM Embedded toolchain: 8-2019-update. I am able to compile and run programs successfully from the command line and SES, but I am dealing with a weid problem. Previously, on NCS v1.1.0 I could use sscanf("%llu", value) to parse a uint64 variable.

Now, I am trying to use sscanf in order to do the same but it fails.

The way I do it is like this:

uint64_t value = 0;
sscanf(string, "UINT64: %llu\n", &value);
printk("%llu\n", value);

The output that I get is lu.

In the prk.conf, I have added the following line:
CONFIG_NEWLIB_LIBC=y

Is there anything that I am perhaps missing?

[Didrik Rokhaug]

Hi.

When you used NCS v1.1.0, I assume you also used an older toolchain?

In the output from West, there should be a line saying which compiler it uses, could you send me that line?

E.g. "-- The C compiler identification is GNU 8.3.1"

To test, I have been using the following program (a modified version of Zephyr's hello_world sample:

#include <zephyr.h>
#include <sys/printk.h>
#include <stdio.h>

void main(void)
{
	printk("Hello World! %s\n", CONFIG_BOARD);
	uint64_t foo = 4294967296; // 2^32
	printk("GCC: %d.%d.%d\n", __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__);
	printk("foo printk hex: %llx\n", foo);
	printk("foo printk dec: %llu\n", foo);
	printf("foo printf hex: %llx\n", foo);
	printf("foo printf dec: %llu\n", foo);

}

CONFIG_NEWLIB_LIBC=y is added to the otherwise empty prj.conf.

I get the following output:

Fullscreen 64bit_print.txt Download

*** Booting Zephyr OS build v2.1.99-ncs1  ***
Flash region		Domain		Permissions
00 0x00000 0x08000 	Secure		rwxl
01 0x08000 0x10000 	Non-Secure	rwxl
02 0x10000 0x18000 	Non-Secure	rwxl
03 0x18000 0x20000 	Non-Secure	rwxl
04 0x20000 0x28000 	Non-Secure	rwxl
05 0x28000 0x30000 	Non-Secure	rwxl
06 0x30000 0x38000 	Non-Secure	rwxl
07 0x38000 0x40000 	Non-Secure	rwxl
08 0x40000 0x48000 	Non-Secure	rwxl
09 0x48000 0x50000 	Non-Secure	rwxl
10 0x50000 0x58000 	Non-Secure	rwxl
11 0x58000 0x60000 	Non-Secure	rwxl
12 0x60000 0x68000 	Non-Secure	rwxl
13 0x68000 0x70000 	Non-Secure	rwxl
14 0x70000 0x78000 	Non-Secure	rwxl
15 0x78000 0x80000 	Non-Secure	rwxl
16 0x80000 0x88000 	Non-Secure	rwxl
17 0x88000 0x90000 	Non-Secure	rwxl
18 0x90000 0x98000 	Non-Secure	rwxl
19 0x98000 0xa0000 	Non-Secure	rwxl
20 0xa0000 0xa8000 	Non-Secure	rwxl
21 0xa8000 0xb0000 	Non-Secure	rwxl
22 0xb0000 0xb8000 	Non-Secure	rwxl
23 0xb8000 0xc0000 	Non-Secure	rwxl
24 0xc0000 0xc8000 	Non-Secure	rwxl
25 0xc8000 0xd0000 	Non-Secure	rwxl
26 0xd0000 0xd8000 	Non-Secure	rwxl
27 0xd8000 0xe0000 	Non-Secure	rwxl
28 0xe0000 0xe8000 	Non-Secure	rwxl
29 0xe8000 0xf0000 	Non-Secure	rwxl
30 0xf0000 0xf8000 	Non-Secure	rwxl
31 0xf8000 0x100000 	Non-Secure	rwxl
Non-secure callable region 0 placed in flash region 0 with size 32.


SRAM region		Domain		Permissions
00 0x00000 0x02000	Secure		rwxl
01 0x02000 0x04000	Secure		rwxl
02 0x04000 0x06000	Secure		rwxl
03 0x06000 0x08000	Secure		rwxl
04 0x08000 0x0a000	Secure		rwxl
05 0x0a000 0x0c000	Secure		rwxl
06 0x0c000 0x0e000	Secure		rwxl
07 0x0e000 0x10000	Secure		rwxl
08 0x10000 0x12000	Non-Secure	rwxl
09 0x12000 0x14000	Non-Secure	rwxl
10 0x14000 0x16000	Non-Secure	rwxl
11 0x16000 0x18000	Non-Secure	rwxl
12 0x18000 0x1a000	Non-Secure	rwxl
13 0x1a000 0x1c000	Non-Secure	rwxl
14 0x1c000 0x1e000	Non-Secure	rwxl
15 0x1e000 0x20000	Non-Secure	rwxl
16 0x20000 0x22000	Non-Secure	rwxl
17 0x22000 0x24000	Non-Secure	rwxl
18 0x24000 0x26000	Non-Secure	rwxl
19 0x26000 0x28000	Non-Secure	rwxl
20 0x28000 0x2a000	Non-Secure	rwxl
21 0x2a000 0x2c000	Non-Secure	rwxl
22 0x2c000 0x2e000	Non-Secure	rwxl
23 0x2e000 0x30000	Non-Secure	rwxl
24 0x30000 0x32000	Non-Secure	rwxl
25 0x32000 0x34000	Non-Secure	rwxl
26 0x34000 0x36000	Non-Secure	rwxl
27 0x36000 0x38000	Non-Secure	rwxl
28 0x38000 0x3a000	Non-Secure	rwxl
29 0x3a000 0x3c000	Non-Secure	rwxl
30 0x3c000 0x3e000	Non-Secure	rwxl
31 0x3e000 0x40000	Non-Secure	rwxl

Peripheral		Domain		Status
00 NRF_P0               Non-Secure	OK
01 NRF_CLOCK            Non-Secure	OK
02 NRF_RTC0             Non-Secure	OK
03 NRF_RTC1             Non-Secure	OK
04 NRF_NVMC             Non-Secure	OK
05 NRF_UARTE1           Non-Secure	OK
06 NRF_UARTE2           Secure		SKIP
07 NRF_TWIM2            Non-Secure	OK
08 NRF_SPIM3            Non-Secure	OK
09 NRF_TIMER0           Non-Secure	OK
10 NRF_TIMER1           Non-Secure	OK
11 NRF_TIMER2           Non-Secure	OK
12 NRF_SAADC            Non-Secure	OK
13 NRF_PWM0             Non-Secure	OK
14 NRF_PWM1             Non-Secure	OK
15 NRF_PWM2             Non-Secure	OK
16 NRF_PWM3             Non-Secure	OK
17 NRF_WDT              Non-Secure	OK
18 NRF_IPC              Non-Secure	OK
19 NRF_VMC              Non-Secure	OK
20 NRF_FPU              Non-Secure	OK
21 NRF_EGU1             Non-Secure	OK
22 NRF_EGU2             Non-Secure	OK
23 NRF_DPPIC            Non-Secure	OK
24 NRF_GPIOTE1          Non-Secure	OK
25 NRF_REGULATORS       Non-Secure	OK

SPM: NS image at 0xc000
SPM: NS MSP at 0x20020598
SPM: NS reset vector at 0xcc35
SPM: prepare to jump to Non-Secure image.
*** Booting Zephyr OS build v2.1.99-ncs1  ***
Hello World! nrf9160_pca10090
GCC: 8.3.1
foo printk hex: 100000000
foo printk dec: ERR
foo printf hex: lx

foo printf dec: lu

As you can see, I can print the number in hex format, but not in decimal format using printk. That is the intended behavior and works the same if I don't use Newlib: https://github.com/zephyrproject-rtos/zephyr/pull/12552

However, if I use printf instead, it does not work. It does "work" if I only use one "l", but then, of course, I only get a 32-bit output which causes overflow.

Best regards,

Didrik

[Nguyen Hoan Hoang]

to print 64 bits int standard C, use PRIu64.

printf("64 bit val =%" PRIu64 "\n", val64bits);

PRIx64 = hex version

PRId64 = %d version

require include <inttypes.h>

not sure if newlb nano supports it or not but newlib standard supports it.

[Giannis Anastasopoulos]

Didrik Rokhaug Nguyen Hoan Hoang,

thank you very much for your response and assistance.

The issue with the sscanf and printf comes from the fact that CONFIG_NEWLIB_LIBC_NANO became by default 'y', while in the previous version of Zephyr it was by default set to 'n'.

This was done in order to reduce the size of the built application and make Zephyr friendlier to devices with limited resources.

[J Mapstone]

Giannis Anastasopoulos your solution worked for me too.

I switched CONFIG_NEWLIB_LIBC_NANO=n and now 64 bit formatting with printf() and printk() works.