Questions about factory Data

[SunHuang]

1.After I burn AP CODE, executing "nrfjprog -f nrf53 --program factory_data.hex –sectorerase" instruction will cause the following error.
This issue wasn't happened in prior 2.4.1 version, but occured after updated 2.6.1.

2.Was factory data stored in TrustZone? If not how to get factory data stored in TrustZone?

[Edvin]

Hello, and sorry for the late reply!

I am sure this is obvious, because you follow some guide/documentation, but can you please show me the link to that guide? And how/where is factory_data.hex generated?

I assume that there is something in between these versions that has changed it's default position in flash. You can typically override this using a static partition file (pm_static.yml), but I guess this needs to be forwarded to the tool that generates factory_data.hex.

With some more context, I can dig a little deeper, or ask our Matter team.

Best regards,

Edvin

[SunHuang]

Hi,

Edvin said:

I am sure this is obvious, because you follow some guide/documentation, but can you please show me the link to that guide? And how/where is factory_data.hex generated?

docs.nordicsemi.com/.../nrfconnect_factory_data_configuration.html

----------------------------------------------------------------------------------------------

I noticed that this version has the following configuration.

If I configure it like this, I can burn the AP CODE first and then update the factory data.

# Enable Factory Data feature

CONFIG_CHIP_FACTORY_DATA=y

CONFIG_CHIP_FACTORY_DATA_BUILD=n

But the factory data can only be updated once.

If I update the factory data again (different factory data), it will become the original problem again.

[Edvin]

SunHuang said:

But the factory data can only be updated once.

If I update the factory data again (different factory data), it will become the original problem again.

I don't think I understand what you mean here. 

So how do you generate your factory data? Is it the same method in both v2.4.1 and v2.6.1? Can you please share the command that you use in both v2.4.1 and v2.6.1? I assume you are using CONFIG_CHIP_FACTORY_DATA_BUILD=n in both v2.4.1 and v2.6.1?

Also, please read through the Matter related changes in the v2.6.0 migration guide. 

[SunHuang]

python scripts\tools\nrfconnect\generate_nrfconnect_chip_factory_data.py --sn "11223344556677889902" --vendor_id 65521 --product_id 32776 --vendor_name "POC" --product_name "matter lock" --date "2023-11-01" --hw_ver 1 --hw_ver_str "prerelase" --dac_cert "credentials\development\attestation\Matter-Development-DAC-FFF1-8008-Cert.der" --dac_key "credentials\development\attestation\Matter-Development-DAC-FFF1-8008-Key.der" --pai_cert "credentials\development\attestation\Matter-Development-PAI-FFF1-noPID-Cert.der" --spake2_it 1000 --spake2_salt "U1BBS0UyUCBLZXkgU2FsdA==" --discriminator 0xF00 --generate_rd_uid --passcode 20202021 --product_finish "matte" --product_color "black" --out "factory\build.json" --schema "scripts\tools\nrfconnect\nrfconnect_factory_data.schema" --generate_onboarding

[SunHuang]

Edvin said:

I don't think I understand what you mean here. 

Hi Edvin

It means that I can't flash the factory data again.

[Edvin]

SunHuang said:

If I configure it like this, I can burn the AP CODE first and then update the factory data.

# Enable Factory Data feature

CONFIG_CHIP_FACTORY_DATA=y

CONFIG_CHIP_FACTORY_DATA_BUILD=n

Then why do you want to flash the factory data again? I assume that if you erase the entire flash, and re-flash the application and factory data, then it works?

Best regards,

Edvin

[SunHuang]

Hi Edvin

When I use prj_release.conf, a factory data is automatically generated and then written to the device.

So I want to flash the factory data again, although I think it doesn't make sense.

Using the same configuration, the results of prj.conf and prj_release.conf are different. Why is this?

[Edvin]

SunHuang said:

prj.conf and prj_release.conf are different. Why is this?

You can compare the prj.conf and prj_release.conf files. I don't know what sample you based your application on, but looking at the light_bulb sample, the difference is that the prj_release.conf has disabled debugging, disabled the shell feature, and enabled the watchdog. That is pretty much the only difference. Both CONFIG_CHIP_FACTORY_DATA and CONFIG_CHIP_FACTORY_DATA_BUILD are set to "y" in prj.conf and prj_release.conf in the light bulb sample (and all the other samples, as far as I can tell). 

My guess is that if you program the sample with a set of factory data, and reset the device, then the application will start processing this, and start using it and storing something in it's settings. When it later starts up with a new set of factory data, that doesn't match what it believes it had, it asserts. 

When you re-flash the factory data. Do you use nrfjprog? Do you use the argument --sectorerase? Do you use the argument --verify? If not, can you please try to use those? Does it change anything?

Best regards,

Edvin