Testing Flash and RAM

RE: Testing Flash and RAM

Charan — Tue, 02 Mar 2021 05:41:41 GMT

Inside the nrf_dfu_bank0_start_addr, it uses the MBR_SIZE parameter. I am not having any bootloader and hence, I don't want to use MBR as well. What should to SD_SIZE_GET()?

RE: Testing Flash and RAM

Edvin — Mon, 01 Mar 2021 14:01:24 GMT

I can't see anything in the crc_compute() that is DFU related, no. Give it a go, and let me know if it doesn't work.

BR,

Edvin

RE: Testing Flash and RAM

Charan — Mon, 01 Mar 2021 09:59:35 GMT

[quote userid="26071" url="~/f/nordic-q-a/71882/testing-flash-and-ram/296774#296774"]Where bank0_start_addr() is the start address of the applictaion (after the softdevice), and image_size is the size of the application.[/quote]

Ok. Great. Thanks!!

This is irrespective of whether I have bootloader or not right?
I had seen this previously but since it had DFU in it, I thought a bootloader is necessary to implement it.

RE: Testing Flash and RAM

Edvin — Mon, 01 Mar 2021 09:26:00 GMT

Hello,

I believe that you can choose whether to do it block by block, or as a whole image. Look at how it is used in app_activate() in nrf_bootloader_fw_activation.c in the bootloader project found in SDK\examples\dfu\secure_bootloader\pca10040_s132_ble.

It looks like this example uses the image's (application's) start address:

crc = crc32_compute((uint8_t*)nrf_dfu_bank0_start_addr(), image_size, NULL);

Where bank0_start_addr() is the start address of the applictaion (after the softdevice), and image_size is the size of the application.

If you look at the declaration of the crc32_compute():

/**@brief Function for calculating CRC-32 in blocks.
 *
 * Feed each consecutive data block into this function, along with the current value of p_crc as
 * returned by the previous call of this function. The first call of this function should pass NULL
 * as the initial value of the crc in p_crc.
 *
 * @param[in] p_data The input data block for computation.
 * @param[in] size   The size of the input data block in bytes.
 * @param[in] p_crc  The previous calculated CRC-32 value or NULL if first call.
 *
 * @return The updated CRC-32 value, based on the input supplied.
 */
uint32_t crc32_compute(uint8_t const * p_data, uint32_t size, uint32_t const * p_crc);

You see that you can do this in blocks as well. If so, you would calculate the CRC of a block of a given size, using NULL as the starting CRC. Then when you want to calculate the next crc, you would use the previous CRC, and it will continue to use that CRC for the second block.

Best regards,

Edvin

RE: Testing Flash and RAM

Charan — Mon, 01 Mar 2021 06:25:19 GMT

Hello,

I was looking into the crc32_compute all along and I am able to find the start and end address of flash memory and hence, the size as well. It seems that we have to feed the function as a data block which is where I am struggling. How would I feed the entire flash memory or at least the program memory (.text) as a block? Or is it fine if I just feed the starting address and the size of the block?

RE: Testing Flash and RAM

Edvin — Thu, 25 Feb 2021 12:39:44 GMT

[quote user="Havig"]What do you mean by outside the application[/quote]

Sorry. I meant "outside the bootloader". That is, not using the bootloader.

RE: Testing Flash and RAM

Charan — Thu, 25 Feb 2021 12:05:24 GMT

[quote userid="26071" url="~/f/nordic-q-a/71882/testing-flash-and-ram/295876#295876"]You would of course need to calculate it from outside the application[/quote]

What do you mean by outside the application. I don't think we will be using the bootloader, so I will be using the crc32_compute only.

RE: Testing Flash and RAM

Edvin — Tue, 23 Feb 2021 14:58:48 GMT

Ok. Either you need to either apply a bootloader, or you need to look at how the bootloader does the CRC calculations.

I guess the function crc32_compute() from crc32.c in the SDK could be a way to go in your case. You would of course need to calculate it from outside the application, to know what the crc32_compute() will return, in order to check that it is still the same.

Best regards,

Edvin

RE: Testing Flash and RAM

Charan — Tue, 23 Feb 2021 10:10:43 GMT

[quote userid="26071" url="~/f/nordic-q-a/71882/testing-flash-and-ram/295770#295770"]Or is it to prevent someone from injecting faulty software to your chip?[/quote]

No I am using read back protection for the same.

As per standards in the compliance, I need to check for codes in flash and RAM.

RE: Testing Flash and RAM

Edvin — Tue, 23 Feb 2021 09:55:09 GMT

So did you plan to have a bootloader before delivering the project? Either way, I think you should read through and follow this guide:

Getting started with Nordic's Secure Bootloader.

A couple of hints:

1: Make sure that you are able to build Makefile projects from the command line (the guide briefly explains how to set it up)

2: In order to run an application while you have a bootloader programmed, you either have to have transferred the application via DFU, or you need to generate bootloader settings and program it.

Your initial request is a bit unusual. What will you do in case there is a CRC error in the application flash? What makes you think it will happen? Are you sending it into space (cosmic radiation)? Or is it to prevent someone from injecting faulty software to your chip?

RE: Testing Flash and RAM

Charan — Tue, 23 Feb 2021 04:46:04 GMT

Hmm, thanks a lot

I will look into the bootloader description and check if it's possible. Right now, I dont have a bootloader and we are so close to delivering our project. How long will it take to add a bootloader to the application without any errors and is there any measures I might have to follow in doing the same?

Second question is how do I access RAM address via software and read and write data to it.

RE: Testing Flash and RAM

Edvin — Mon, 22 Feb 2021 15:03:39 GMT

Hello,

It is not really a typical thing to do this on the nRFs (at least that is my impression). That being said, there is nothing preventing you from doing so.

If you are going to do this, I would split it into two parts:

1. CRC check of the application. We do have a bootloader that can do this. Actually, if you plan to use a bootloader at all, I would recommend that you just use the option to check the CRC on every reboot, instead of only when a new image is received, which is the default behavior. What you would to is to set these settings from the bootloader's sdk_config.h to 0:

#ifndef NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2
#define NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 1
#endif

// <q> NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET  - Skip integrity check of the application when waking up from the System Off state.
 

// <i> Only CRC checks can be skipped. For other boot validation types, the reset state is ignored.

#ifndef NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET
#define NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET 1
#endif

However, if you have not used the bootloader before, I suggest you get that up and running with the default settings before you start to adjust it.

If you don't want to do this using the bootloader, I think you should look at how the bootloader checks the CRC of the application, and somehow try to replicate this from your application.

2: You said that you want to check the CRC of your peer manager. The peer manager uses FDS (Flash Data Storage) to store it's data. The FDS actually has an option to check CRC of the records that are stored, so you would just need to make sure that this is enabled in your application's FDS settings in sdk_config.h. Set:

FDS_CRC_CHECK_ON_READ to 1

and alternatively:

FDS_CRC_CHECK_ON_WRITE to 1 as well.

Best regards,

Edvin