Testing Flash and RAM

[Charan]

Hello,

I want to run a memory test whenever my device nrf52832 starts up to check for various faults like stuck at, transition and other faults in both flash and RAM. Does the CRC in flash check all the flash blocks including the .txt one or does it only use CRC for reading and writing to the flash? Or is there any other way to check the credibility of the flash and RAM

I read that you can create a checksum of the entire flash. My question is how can I create a checksum for the entire flash region or at least the region where the code and the peer manager is stored? As far as RAM is considered, it looks like I have to do any of the March tests. How do I access the RAM region via software?

Also, last question, suppose I am doing march test. Will doing this in main before initializing the modules affect the global variables assigned?

[Edvin]

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

[Charan]

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.

[Edvin]

Charan said:

What do you mean by outside the application

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

[Charan]

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?

[Edvin]

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

[Charan]

Edvin said:

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

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.

[Edvin]

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

[Charan]

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()?