Enabling Provisioning

[rtphilipson]

I'm attempting to enable provisioning using attestation tokens in my project.  As soon as I add the config;

CONFIG_NRF_PROVISIONING=y

The build starts failing with;

C:\Users\RANDAL~1.PHI\AppData\Local\Temp\ccKWl0nJ.s: Assembler messages:
C:\Users\RANDAL~1.PHI\AppData\Local\Temp\ccKWl0nJ.s:1406: Error: missing expression

I'm building for a custom board, that has the nrf9151 on it.  Using SDK 3.1.1

now when I build the nrf_cloud_multi_service sample, targeting the nrf9151dk it builds fine, which I think means that I have some sort of CONFIG conflict.  

7271.prj.conf

[rtphilipson]

I guess we can delete this.  By jiggling around CONFIG settings I was able to get it to work.  Not sure what really did it, but getting rid of the following;

#CONFIG_FLASH_PAGE_LAYOUT=y

#CONFIG_FLASH_MAP=y

#CONFIG_STREAM_FLASH=y

#CONFIG_NRF_CLOUD_ALERT=y

#CONFIG_SETTINGS=y

#CONFIG_FCB=y

#CONFIG_SETTINGS_FCB=y

seemed to get it to work. I don't know what the conflict was there.  Usually the build system does a good job showing me when I have conflicts, but not in this case.

[rtphilipson]

Spoke too soon.  Disabling CONFIG_SETTINGS disabled provisioning.  Now the error is back.

[rtphilipson]

OK, I simply got rid of all the provisioning items from my prj.conf file.  Then I copied the overlay-coap_nrf_provisioning.conf from the nrf_cloud_multi_service sample and it built.  I then used the "nrf_provisioning init" CLI command and the damn thing provisioned.  I actually expected to have to follow it with the "now" command

So, that was nice.  I had already claimed the device on my NRF_CLOUD account and it just worked.  The problem now is that I store information in NVS and the provisioning process seemed to overwrite it.  So I think I have an NVS conflict in the information that the provision uses and the information I'm storing on NVS.  I'm trying to fiigure out how to avoid the conflict.  The main thing deleted was my AWS Client ID and I'm concerned that if I set the Client ID again that it's going to overwrite provisioning information.

[Syed Maysum Abbas Zaidi]

Hi,

Good to hear that provisioning itself is now working correctly after reusing the overlay-coap_nrf_provisioning.conf. The remaining issue you’re seeing is due to a storage conflict. The nRF Provisioning library stores its state and credentials using Zephyr’s settings subsystem, which is typically backed by an NVS flash partition. If your application is also using NVS and both end up pointing to the same flash area, provisioning can overwrite application data. This is expected behavior when multiple users share the same NVS region. 

To avoid this, we recommend separating the storage used by provisioning and your application. On custom boards, the most robust approach is to define two non-overlapping flash partitions using Partition Manager, by adding a pm_static.yml file:

1. One used by the provisioning/settings system.
2. One used by your own application data.

You can do it by placing a file named pm_static.yml in your application root (same level as prj.conf), build once and then copy build/partitions.yml into pm_static.yml in your app folder after which you can edit it to add your own partitions. You can refer to this devzone case and documentation regarding separations of partitions.

Best Regards,
Syed Maysum

[rtphilipson]

I created my own pm_static.yml file a while back to accommodate the bootloader.  I've tried to be very careful about modifying since I don't really understand it. my nvs_storage partiion;

nvs_storage:

  address: 0xE4000

  end_address: 0xfe000

  inside:

  - nonsecure_storage

  placement:

    align:

      start: 0x8000

    before:

    - end

  region: flash_primary

  size: 0x1A000

One thing messed up about this, which will be made even worse if I start splitting it up, is alignment on a 32K boundary.  Do you know if I can change align: start: 0x8000 to start: 0x1000?  Seems like with data storage that alignment on a sector boundary should be fine.

 

[rtphilipson]

Perhaps you can tell me what I'm doing wrong;

nonsecure_storage:
address: 0xE4000
end_address: 0xfe000
orig_span: &id001
- nvs_storage
- user_storage
region: flash_primary
size: 0x1A000
span: *id001

nvs_storage:
address: 0xE4000
end_address: 0xF1000
inside:
- nonsecure_storage
placement:
align:
start: 0x1000
before:
- end
region: flash_primary
size: 0xD000

user_storage:
address: 0xF1000
end_address: 0xfe000
inside:
- nonsecure_storage
placement:
align:
start: 0x1000
before:
- end
region: flash_primary
size: 0xD000

I changed my pm_static to this, but when I try to use user_storage in my program it appears to be placing the memory at 0x100000 and only 4K of memory at that.  

[Syed Maysum Abbas Zaidi]

Hi,

Thanks for sharing the updated layout. The partition split itself looks fine.

If your data is ending up at 0x100000 with only 4 KB, that usually means the application is still writing to a default storage area, rather than the user_storage partition you defined. In other words, the partition exists, but the code isn’t actually using it yet.

Have you tried doing a pristine rebuild and checked build/partitions.yml to confirm if the user_storage is present at 0xF1000 with size 0xD000?

Best Regards,
Syed Maysum

[rtphilipson]

My bad, I was trying to create a nvs file system with more sectors than was available.  Instead of using 

FIXED_PARTITION_SIZE() to calculate, I was using a hardcoded value in my code .

So I appear to be all good now.