Fault When Reading Magic From Image Header

[uhrm]

Hi,

I am trying to send some information from the application image (e.g. header, TLVs, etc.) through a SPI channel. 

The problem is that whenever I try to copy the header information of the application from Flash to a buffer in RAM I always get a fault, and I don't understand why. My pointers are correct, I have tried memcpy, a for loop, direct byte by byte copy, and always get the same result. Are there any restrictions to copy Flash to RAM?

As an example, the code below is just trying to copy the magic value (4 bytes) from the application's header to a buffer in RAM. As mentioned, using memcpy, a for loop, direct copy, will cause a fault. I know my destination buffer is fine, because I can just write a value to it and it works without generating the fault.

Thoughts?

const uint8_t *image_header = (const uint8_t *)0x10000;
uint8_t magic_nr_length = sizeof(uint32_t);

#define OPT 0   // This is to select the example code to copy the magic to the RAM buffer.

#if OPT == 0
    memcpy(tx_data.buffer, image_header, magic_nr_length);  // This causes a fault.
#elif OPT == 1
    for (uint16_t i = 0; i < magic_nr_length; i++)    // This causes a fault.
    {
        tx_data.buffer[i] = image_header[i];
    }
#elif OPT == 2    // This causes a fault
    tx_data.buffer[0] = image_header[0];
    tx_data.buffer[1] = image_header[1];
    tx_data.buffer[2] = image_header[2];
    tx_data.buffer[3] = image_header[3];
#else

    // This does not cause a fault.

    tx_data.buffer[0] = 0x96;
    tx_data.buffer[1] = 0xf3;
    tx_data.buffer[2] = 0xf8;
    tx_data.buffer[3] = 0x3d;
#endif

Thanks in advance.

[Vidar Berg]

Hi Peter,

Sorry, I didn't notice the discrepancy between DTS and what was printed by the partition manager, I just assumed they would be the same. Could you check if you have anything at 0x20000? Based on the partition manager and *.map output, the NS app is starting 0x20200.

I will find out why the DTS and Partition manager don't operate with the same addresses in the meantime.

[uhrm]

Hi Vidar,

Per your question, looking at the MAP files and memory of the device, here is what I have:

1. Image header @ 0x10000 (512 bytes total: 32 header bytes + padding bytes)

2. SPM code @ 0x10200

3. Application 'code @ 0x20200

Thoughts?

Regards

Peter

[uhrm]

Hi Vidar,

As a test I disabled mcuboot, and the resulting layout is below. 

Everything got shifted to lower memory addresses due not having the mcuboot, but the application is still located in the secure partition starting at 0x10000 even though (as mentioned in an earlier post) it is specified to go to the non secure partition.

I am able to read the flash at 0x10000 without getting the fault, but now I don't have the mcuboot to handle the firmware updates.

So my question is, what is the dependency between having the mcuboot enabled and reading out of flash from the secure area? In both cases the SPM is enabled.

Regards

Peter

[Vidar Berg]

Hi Peter,

I've discussed this case with a colleague now. Turns out you need to use the SPMs secure services to get read access to the MCUBoot pad area when SPM is enabled. I quickly verified that it worked here with this code:

#include "secure_services.h"

void main(void)	
{
	uint32_t mcuboot_magic;

	int err = spm_request_read(&mcuboot_magic, 0x10000, sizeof(mcuboot_magic));
	if (err) {
		printk("Failed to read from MCUBoot pad area at 0x10000 (err %d)\n", err);
	} else {
		printk("MCUBoot magic word %x\n", mcuboot_magic);
	}

Regards,

Vidar

[uhrm]

Hey Vidar,

That did the trick, I confirm that I can now read the header of the image when I have both the mcuboot and spm enabled.

Thanks for the help!

Best regards

Peter