Sample Apps not working.

[Monkeytronics]

Environment

• nRF9151DK.
• Using nRF tools and SDK v3.1.1 & also v3.2.3.
• Based in New Zealand and currently on Spark network. 

Issue

Trying to run the sample app -> nrf_cloud_coap_fota but failing out of the box. If I understand the code correctly, it appears to be using `CONFIG_NET_NATIVE` which doesn't make any sense to me. I was under impression that the nrf approach to networking was to use the nrf_modem library? What's going on with this? 

Also, I tried building the asset tracker sample as an alternative approach. But this doesn't seem to be supported at current versions - it's years out of date?!? I could go through and start hacking away at all the incompatibilities, but a) that's nordic's job, and b) I don't know what I'm doing. 

Nordic - what is the plan here? Can you provide me with some working sample apps for nrf9151 for recent SDK versions. If you could verify them on the nrf9151DK, that would be ideal. 

 

[Menon]

Hello,

Yes, it’s true that the two samples are configured differently, but both are correct . You can use the Academy sample to get a basic understanding of how CoAP works. Then, the zephyr_coap client sample can serve as a good starting point for building your own CoAP client, while the nRF Cloud CoAP sample shows how to communicate specifically with the nRF Cloud service.

From the logs you shared, it doesn’t seem like a CoAP or library-related issue. It looks more like a network rejection. Since the sample works and only your custom application is failing, it is likely related to how the application is implemented.

Kind Regards,

Abhijith

[Monkeytronics]

Thank you for the response. I respectfully disagree that this is solely an implementation issue on my end.

I've encountered several undocumented behaviors and dependency conflicts in NCS v3.2.3 that suggest systemic documentation gaps:

1. Kconfig dependency conflicts: CONFIG_SETTINGS silently fails to enable when loaded after CONFIG_LOG_MODE_MINIMAL due to undocumented dependencies, causing Partition Manager to not generate PM_settings_storage_ID. This is only resolved by placing Settings configs in prj.conf before other configs - a requirement not documented anywhere in the nRF Cloud provisioning documentation.

2. Initialization order requirements: conn_mgr_all_if_up() crashes with fatal errors when called after enabling nRF provisioning configs, despite no documentation indicating the required call sequence or dependency initialization. This goes against zephyr's separation of concerns principles.

3. Sample divergence: The nRF Device Provisioning sample uses a simple single-file configuration that masks these ordering issues. Real-world applications using modular config files (as recommended by Zephyr best practices) encounter failures not present in the samples.

These are architectural issues in how the SDK handles config dependencies and initialization sequencing, not application logic errors. The samples work because they avoid the edge cases that modular configurations expose.

Could Nordic provide documentation on:

• Kconfig symbol dependency ordering requirements
• Required initialization sequences for conn_mgr + provisioning
• Why Partition Manager's partition detection depends on config load order

This would help developers avoid these traps

[Menon]

Hello,

Monkeytronics said:

Kconfig symbol dependency ordering requirements

So, the build system can override the changes you make if the dependencies are not satisfied. When you build the application, you will probably see a warning about this. Please refer to the Kconfig override warnings.

I think the issue you are facing could be because PM_settings_storage_ID is not generated simply by enabling CONFIG_SETTINGS. You also need a supported persistent settings backend, such as CONFIG_SETTINGS_NVS or CONFIG_SETTINGS_FCB, with all required dependencies satisfied, see this mentioned under partition manager. 

Monkeytronics said:

Initialization order requirements: conn_mgr_all_if_up() crashes with fatal errors when called after enabling nRF provisioning configs, despite no documentation indicating the required call sequence or dependency initialization. This goes against zephyr's separation of concerns principles.

I think you can refer to the nRF Provisioning Config documentation, which provides some ideas about provisioning library configurations.

Monkeytronics said:

Why Partition Manager's partition detection depends on config load order

I also think that what you are seeing might be a missing dependency issue. When you build the application, could you check whether it throws any warnings? The prj.conf file is evaluated as a whole based on dependencies.

Kind Regards,

Abhijith