libraries.libc.sprintf_new: fails on lpcxpresso55s16_ns and lpcxpresso55s69_ns

[hakehuang]

Describe the bug
ASSERTION FAI wehn run test_EOF

To Reproduce
Steps to reproduce the behavior:

1. cd tests/lib/sprintf;mkdir build; cd build
2. cmake -DBOARD=lpcxpresso55s16_ns -DCONF_FILE=prj_new.conf ..
3. make; make flash
4. See error

lpcxpresso55s69_ns has the same problem

Expected behavior
test pass

Impact
sprint new conf setting features

Logs and console output

    *** Booting Zephyr OS build zephyr-v2.5.0-3761-g730acbd6ed85  ***
    Running test suite test_sprintf
    ===================================================================
    START - test_EOF
    ASSERTION FAIL [esf != ((void *)0)] @ WEST_TOPDIR/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:993
    	ESF could not be retrieved successfully. Shall never occur.
    ASSERTION FAIL [esf != ((void *)0)] @ WEST_TOPDIR/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:993
    	ESF could not be retrieved successfully. Shall never occur.

and for cmake -DBOARD=lpcxpresso55s16_ns build we see below failure

    *** Booting Zephyr OS build zephyr-v2.5.0-3761-g730acbd6ed85  ***

    Running test suite test_sprintf

    ===================================================================

    START - test_sprintf_double

    ASSERTION FAIL [esf != ((void *)0)] @ WEST_TOPDIR/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:993

    	ESF could not be retrieved successfully. Shall never occur.

    ASSERTION FAIL [esf != ((void *)0)] @ WEST_TOPDIR/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:993

    	ESF could not be retrieved successfully. Shall never occur.

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows)
• Toolchain (e.g Zephyr SDK, ...)
• Commit SHA or Version used: v2.6.0-rc1

[hakehuang]

@MaureenHelm , @dleach02 , @mmahadevan108

[microbuilder]

I'm not able to reproduce this.

Performing a build with:

$ cd tests/lib/sprintf
$ mkdir build && cd build
$ cmake -DBOARD=lpcxpresso55s69_ns -DCONF_FILE=prj_new.conf ..
$ make
$ JLinkExe -device lpc55s69 -if swd -speed 2000 -autoconnect 1
J-Link>erase
J-Link>loadfile zephyr/zephr.hex
J-Link>quit

Then physically reset the board ... there is no serial output, which is expected since lpcxpresso55s69_ns assumes we are using TF-M, and so places the application code at an offset of 0x40000 to leave room for MCUBoot and the secure TF-M image.

$ arm-none-eabi-readelf --sections --wide zephyr/zephyr.elf 
There are 27 section headers, starting at offset 0xba3ec:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] rom_start         PROGBITS        00040000 0000b4 000130 00 WAX  0   0  4
  [ 2] text              PROGBITS        00040130 0001e4 004daa 00  AX  0   0  4

Are you enabling TF-M here by hand, since you shouldn't be using the _ns target outside TF-M.

When I build with lpcxpresso55s69_cpu0 this works fine:

*** Booting Zephyr OS build zephyr-v2.5.0-3862-g253350c6e721  ***
Running test suite test_sprintf
===================================================================
START - test_EOF
 PASS - test_EOF in 0.1 seconds
===================================================================
Test suite test_sprintf succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

Perhaps you are flashing the _ns .bin file, but at address 0, which will lead to unexpected behavior since lpcxpresso55s69_ns assumes images start at 0x40000?

[hakehuang]

I'm not able to reproduce this.

Performing a build with:

$ cd tests/lib/sprintf
$ mkdir build && cd build
$ cmake -DBOARD=lpcxpresso55s69_ns -DCONF_FILE=prj_new.conf ..
$ make
$ JLinkExe -device lpc55s69 -if swd -speed 2000 -autoconnect 1
J-Link>erase
J-Link>loadfile zephyr/zephr.hex
J-Link>quit

Then physically reset the board ... there is no serial output, which is expected since lpcxpresso55s69_ns assumes we are using TF-M, and so places the application code at an offset of 0x40000 to leave room for MCUBoot and the secure TF-M image.

$ arm-none-eabi-readelf --sections --wide zephyr/zephyr.elf 
There are 27 section headers, starting at offset 0xba3ec:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] rom_start         PROGBITS        00040000 0000b4 000130 00 WAX  0   0  4
  [ 2] text              PROGBITS        00040130 0001e4 004daa 00  AX  0   0  4

Are you enabling TF-M here by hand, since you shouldn't be using the _ns target outside TF-M.

When I build with lpcxpresso55s69_cpu0 this works fine:

*** Booting Zephyr OS build zephyr-v2.5.0-3862-g253350c6e721  ***
Running test suite test_sprintf
===================================================================
START - test_EOF
 PASS - test_EOF in 0.1 seconds
===================================================================
Test suite test_sprintf succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

Perhaps you are flashing the _ns .bin file, but at address 0, which will lead to unexpected behavior since lpcxpresso55s69_ns assumes images start at 0x40000?

so basically all _ns platfrom need use a differrent link file?

[microbuilder]

@hakehuang At present, yes, all _ns or _nonsecure platforms are setup to use an offset in flash memory that leaves space for the S image and optionally a secure bootloader. Armv8-m devices will always start up in 'secure mode', and will need some software configuration to be switched to a 'non-secure mode', so there is no benefit to building a NS image on it's own, since this will effectively turn it into an S image if it's the default firmware coming out of reset.

Can I ask what the use case here is, and what your specific build command was that allowed you to get the specific error? I haven't been able to reproduce it myself on the lpc55s69.

[hakehuang]

@hakehuang At present, yes, all _ns or _nonsecure platforms are setup to use an offset in flash memory that leaves space for the S image and optionally a secure bootloader. Armv8-m devices will always start up in 'secure mode', and will need some software configuration to be switched to a 'non-secure mode', so there is no benefit to building a NS image on it's own, since this will effectively turn it into an S image if it's the default firmware coming out of reset.

Can I ask what the use case here is, and what your specific build command was that allowed you to get the specific error? I haven't been able to reproduce it myself on the lpc55s69.

@microbuilder , I just run twist cases for these _ns boards and find above issues. And in this case, I remember we used to be able to merge two core image into one and wrap the complex steps into build setting. do we still plan to keep them sepatated? if so, can we provide a default TFM image there?

[microbuilder]

We need to add -DCONFIG_BUILD_WITH_TFM=y to the cmake command to cause this test case to be built with TF-M for the S image.

I just tested with the following:

$ cmake -DBOARD=lpcxpresso55s69_ns -DCONF_FILE=prj_new.conf -DCONFIG_BUILD_WITH_TFM=y ..
$ make
$ JLinkExe -device lpc55s69 -if swd -speed 2000 -autoconnect 1

The with the J-Link:

J-Link>erase
Without any give address range, Erase Chip will be executed
Erasing device...
J-Link: Flash download: Total time needed: 0.239s (Prepare: 0.032s, Compare: 0.000s, Erase: 0.201s, Program: 0.000s, Verify: 0.000s, Restore: 0.005s)
J-Link: Flash download: Total time needed: 0.222s (Prepare: 0.029s, Compare: 0.000s, Erase: 0.187s, Program: 0.000s, Verify: 0.000s, Restore: 0.006s)
Erasing done.

J-Link>loadfile tfm_merged.hex 
Downloading file [tfm_merged.hex]...
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (32768 bytes)
J-Link: Flash download: Total: 0.408s (Prepare: 0.052s, Erase: 0.016s, Program & Verify: 0.309s, Restore: 0.030s)
J-Link: Flash download: Program & Verify speed: 104 KB/s
J-Link: Flash download: Bank 1 @ 0x10000000: 1 range affected (196608 bytes)
J-Link: Flash download: Total: 1.624s (Prepare: 0.091s, Erase: 0.036s, Program & Verify: 1.426s, Restore: 0.069s)
J-Link: Flash download: Program & Verify speed: 134 KB/s
O.K.

J-Link>quit

This passes the tests since there is now a valid S image at the start from TF-M:

*** Booting Zephyr OS build zephyr-v2.5.0-3862-g253350c6e721  ***
Running test suite test_sprintf
===================================================================
START - test_EOF
 PASS - test_EOF in 0.1 seconds
===================================================================
Test suite test_sprintf succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

[microbuilder]

@ioannisg @galak Should running tests on the _ns targets without forcing a TF-M build be considered a bug? I think twister should probably only be used with TF-M tests and samples with NS boards targets in general, or this will lead to extremely costly build times. Any non-secure image will fail in any non-TFM context since there is always an offset for the starting flash address.

[ioannisg]

I would put it in a bit more abstract level: we cannot run tests in CI for Non-Secure platforms, unless there is an in-tree and default-set solution for the co-existing Secure binary. If there's not, we exclude these platforms from any tests.

So, since TF-M is the only in-tree Secure FW solution, the above reduces to: "run tests in CI for Non-Secure platforms, if BUILD_WITH_TFM is selected by default"

[ioannisg]

Should running tests on the _ns targets without forcing a TF-M build be considered a bug?

So, yes, this is a bug. Unless there's an available pre-built, pre-flashed Secure FW component on the board. I don't think we have such boards now.

[microbuilder]

@ioannisg I agree, and we should exclude anything where BUILD_WITH_TFM is not being set since it will fail.