preload files to 9160?

[Loren Rogers]

Hello,

I'm working on an application that will use the nrf9160/nrf52.  I will need to make https REST calls where I will populate the http header with username/password credentials.  It's a huge security hole for me to hardcode those credentials AND we want to make it per-device specific (there will be many devices manufactured using the nrf91/nrf52 SoC.  So it would be ideal to preload some configuration file or something of the like which will represent the credentials to be accessed by the application that will be flashed after.  Also the production device will have no outside USB connection and the flash will be programmed using "pads".  Is there a way to send down something in some format to somewhere PRIOR to flashing the application?

Thanks

/Loren

[ovrebekk]

Hi Loren

If you have a debugger connected you could write a script that flashes some configuration data into a fixed location in flash. 

As long as you make sure that the application and other modules don't use this area of the flash for storing anything (code or data), you can then read out this information from the application at a later time. 

To access the flash through the debugger you can use the nrfjprog command line utility (or the pynrfjprog version, for Python). 

Best regards
Torbjørn

[Loren Rogers]

Hi Torbjorn!

Thank you for the quick response!  The plan is to create a custom board using the nrf9160 chip (not using DK board).  There will be no USB connectors on this board. Is there a way to attach a debugger with no USB connector?

/Loren

[ovrebekk]

Hi Loren

Yes, the programming interface is based on the SWD protocol, not USB, and you just need access to the SWDIO and SWDCLK pins from the nRF9160 (pin 33 and 34 in the pinout). 

Typically you will also need to connect ground and VDD to the debugger, so keep this in mind if you want to put test points or pads for a connector on your board.

On the nRF9160DK the interface chip handles the USB to SWD conversion, so you don't need a separate debugger connected. 

Best regards
Torbjørn

[Loren Rogers]

Wonderful, Torbjorn!

I'm assuming I would have to specify the area in flash to put both the configuration data AND the application code?  I've always just let either west or SES decide where to flash my application.  Are there any examples that contain steps on how to specify where in flash to put "configuration data" and my application?

Thanks!

/Loren

[ovrebekk]

Hi Loren

You can use the partition manger for this. Please start by reading through the documentation, here, and let me know afterwards if anything is unclear. 

The partition manager is a bit complex, so I would expect you to have some more questions after reading the documentation ;)

Best regards
Torbjørn

[Loren Rogers]

Yeah I found this yesterday.  It is very complex, lol.  Another thing I was hoping there would be samples for is writing data to flash.  Do I use UICR?  FDS?  I've been looking at nrfjprog command line arguments.  Would I want to use something like this: https://github-wiki-see.page/m/cristianoborgescardoso/nrf52/wiki/Write-and-read-data-at-UICR?  Is there something else I could use?  I've been reading the documentation and looking here on the forums, but I can't seem to find anything that is suited to what I am trying to achieve.  

Thank you Torbjorn!

/Loren

[ovrebekk]

Hi Loren

You mean in order to write to the flash from the debugger, right?

Looking at the documentation it appears there are no user variables available in the UICR for the nRF9160, which means you will need to write your data into the normal application flash instead (address range 0x0-0x100000). 

You need to find a free area of the flash that is not used for anything else, normally this would be at the top of the memory range, allowing room for the application at the bottom. 

In order to write to the flash using the debugger you can use commands similar to the ones shared in the link you sent:

nrfjprog -f NRF91 --memwr 0x000XXXXX --val 0x1234abcd

To read from the flash internally from the MCU all you have to do is refer to the same memory address, something like this:

const uint32_t * flash_ptr = (uint32_t*)0x00001234;

uint32_t flash_data = *flash_ptr;

Best regards
Torbjørn

[Loren Rogers]

Hi Torbjorn!

So my application is using TFM. If I look at my zephr.dts file I see:

flash0: flash@0 {
					compatible = "soc-nv-flash";
					label = "NRF_FLASH";
					erase-block-size = < 0x1000 >;
					write-block-size = < 0x4 >;
					reg = < 0x0 0x100000 >;
					partitions {
						compatible = "fixed-partitions";
						#address-cells = < 0x1 >;
						#size-cells = < 0x1 >;
						boot_partition: partition@0 {
							label = "mcuboot";
							reg = < 0x0 0x10000 >;
						};
						slot0_partition: partition@10000 {
							label = "image-0";
							reg = < 0x10000 0x40000 >;
						};
						slot0_ns_partition: partition@50000 {
							label = "image-0-nonsecure";
							reg = < 0x50000 0x30000 >;
						};
						slot1_partition: partition@80000 {
							label = "image-1";
							reg = < 0x80000 0x40000 >;
						};
						slot1_ns_partition: partition@c0000 {
							label = "image-1-nonsecure";
							reg = < 0xc0000 0x30000 >;
						};
						scratch_partition: partition@f0000 {
							label = "image-scratch";
							reg = < 0xf0000 0xa000 >;
						};
						storage_partition: partition@fa000 {
							label = "storage";
							reg = < 0xfa000 0x6000 >;
						};
					};

And from what I can understand from the documentation If I do a pm.yml that will make the partitions in the zephyr.dts ignored.  In the zephyr.dts I see 6 partitions.  The last one being storage_partition.  With a size of 0x6000 starting at 0xfa000.  Can I use this "storage_partition" to write my data?

If I cannot do that, then do I make a pm.yml for "settings"?  Kinda like pm.yml.settings?

Another question I have is will this entity I'm creating (single application) require multi-image?  Whether or not I need multi-image or single-image is confusing me.  I am using TFM and I do have a subfolder called "child_image" and there is just the mcuboot.conf.

Thanks!

/Loren