frdm_k64f: testcase samples/subsys/canbus/canopen/ failed to be ran

[Zhaoningx]

To Reproduce
Steps to reproduce the behavior:
sanitycheck -p frdm_k64f --device-testing --device-serial /dev/ttyACM0 -T samples/subsys/canbus/canopen/
see error

condition 1: sample.subsys.canbus.canopen
*** Booting Zephyr OS build zephyr-v2.4.0-2085-gd9666ff4d091 ***
[00:00:00.005,000] ^[[1;31m app: failed to initialize settings subsystem (err = -33)^[[0m

condition 2: sample.subsys.canbus.canopen.program_download
^A*** Booting Zephyr OS build zephyr-v2.4.0-2085-gd9666ff4d091 ***
[00:00:00.005,000] ^[[1;31m app: failed to initialize settings subsystem (err = -33)^[[0m

Environment (please complete the following information):

OS: Fedora33
Toolchain: zephyr-sdk-0.11.4
Commit ID: d9666ff

[alexanderwachter]

@henrikbrixandersen do we need to modify the sample.yaml and add the frdm platform allow to the no stage sample only?

[alexanderwachter]

-33 looks like it comes from settings_nvs.c

if (nvs_sector_size > UINT16_MAX) {
	return -EDOM;
}

[nashif]

didnt we have this issue before?

[henrikbrixandersen]

@Zhaoningx Than you for reporting this. I am unable to reproduce the error you are seeing:

$ ./scripts/twister -p frdm_k64f --device-testing --device-serial /dev/ttyACM0 -T samples/subsys/canbus/canopen/
INFO    - Zephyr version: zephyr-v2.4.0-2328-g4cfd2a1943
INFO    - JOBS: 2
INFO    - Building initial testcase list...
INFO    - 3 test suites (3 configurations) selected, 0 configurations discarded due to filters.

Device testing on:

| Platform   | ID   | Serial device   |
|------------|------|-----------------|
| frdm_k64f  |      | /dev/ttyACM0    |

INFO    - Adding tasks to the queue...
INFO    - Added initial list of jobs to queue
INFO    - Total complete:    3/   3  100%  skipped:    0, failed:    0
INFO    - 3 of 3 test configurations passed (100.00%), 0 failed, 0 skipped with 0 warnings in 64.35 seconds
INFO    - In total 3 test cases were executed, 0 skipped on 1 out of total 313 platforms (0.32%)
INFO    - 3 test configurations executed on platforms, 0 test configurations were only built.

Hardware distribution summary:

| Board     | ID   |   Counter |
|-----------|------|-----------|
| frdm_k64f |      |         3 |
INFO    - Saving reports...
INFO    - Writing xunit report /home/brix/Projects/zephyrproject/zephyr/twister-out/twister.xml...
INFO    - Writing xunit report /home/brix/Projects/zephyrproject/zephyr/twister-out/twister_report.xml...
INFO    - Writing JSON report /home/brix/Projects/zephyrproject/zephyr/twister-out/twister.json
INFO    - Run completed

Example console output:

*** Booting Zephyr OS build zephyr-v2.4.0-2328-g4cfd2a19439b  ***
[00:00:00.007,000] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.007,000] <inf> fs_nvs: alloc wra: 0, fd0
[00:00:00.007,000] <inf> fs_nvs: data wra: 0, 38
[00:00:00.007,000] <dbg> canopen_storage.canopen_settings_set: restored object dictionary EEPROM entries
[00:00:00.007,000] <dbg> canopen_driver.CO_CANmodule_init: rxSize = 13, txSize = 9
[00:00:00.007,000] <inf> app: CANopen stack initialized

Could you please confirm if you are still seeing the issue on a more recent revision of Zephyr?

[henrikbrixandersen]

didnt we have this issue before?

@nashif Yes, see #28152.

[Zhaoningx]

@henrikbrixandersen Hi, I re-tested this by using twister -p frdm_k64f --device-testing --device-serial /dev/ttyACM0 -T samples/subsys/canbus/canopen/, and it still showed me:

*** Booting Zephyr OS build zephyr-v2.4.0-2317-gb517b1fc6086 ***
[00:00:00.005,000] ^[[1;31m app: failed to initialize settings subsystem (err = -33)^[[0m

[henrikbrixandersen]

@Zhaoningx Thank you for retesting. Perhaps this has something to do with the state of your storage partition in flash.

@dleach02 Could this somehow be related to #27203 although it is on K64?

[henrikbrixandersen]

@Zhaoningx My guess is that you will have success if you flash it with west flash --erase - but that will also clear the state of the flash and make it more difficult to find the root cause.

[dleach02]

@henrikbrixandersen, not sure. I don't remember ever seeing this type of error on the K64 like I was able to reproduce (occasionally) in #27203. Is there a way to get a dump of the flash before doing an erase (@MaureenHelm)?