Using the S132 soft device on an nRF52 DK and calling the sd_flash_write function always produces the NRF_ERROR_FORBIDDEN code.

[Matthew Johnson]

Using the S132 soft device on an nRF52 DK and calling the sd_flash_write function always produces the NRF_ERROR_FORBIDDEN code. The following is the line believe is causing the problem...

err_code = (sd_flash_write((uint32_t*)cur_addr, value, 1));

The cur_addr pointer is calculated using the following line of code...

cur_addr = (uint32_t*)(512 * cur_block);

The variable 'value' is a uint32_t type and I can read what I believe is the value stored at that address. I have written several loops to cycle and check through the flash storage to see if a block is available (or is all ones, like it's been erased). It would appear that my addresses are correct as I am no longer getting the NRF_INVALID_ADDR. I am able to find 256 blocks and read the data. This makes sense to me with the flash storage size on the DK. Is there another setting or function I need to use in order to write to these addresses? Is it possible that the whole flash is getting write protected?

[bjorn-spockeli]

Which addresses are you trying to write to? The sd_flash_write documentation clearly states that NRF_ERROR_FORBIDDEN error code is returned when you're  trying to write to or read from protected location.

Also could you state which SDK and SoftDevice version you're using?

Best regards

Bjørn 

[Matthew Johnson]

I am using version 14.2.0 of the SDK and S132 v5.0.0. My understanding of the documentation is that the portions of flash occupied by the program code would be protected, but I cannot seem to write to any address. I am able to read all blocks within the flash memory according to the datasheet's memory map.

Thank you,

Matt

[bjorn-spockeli]

Writing to addresses between 0x00000000 and 0x00080000 should work fine. This region will be unprotected unless you explicitly protect it using the BPROT peripheral.

I do not have any issues writting to this region when using the following code and altering the address in one of the ble_peripheral examples.

uint32_t err_code = sd_flash_write((uint32_t *)0x00036000,&test_word, sizeof(uint32_t));
APP_ERROR_CHECK(err_code);

[Matthew Johnson]

After further inspection and testing, all four of the BPROT registers have a value of 0 and it appears that there is information written in all of the flash address locations. Is there a function that would do this in the SDK when using the S132? Did you try your code in the ble_app_template program? That is where I'm trying to use my code. I also have code accessing the the GPIO pins for output to the LEDs as well as entering sleep mode. The sleep mode I'm using is activated using the following line of code...

err_code = sd_power_mode_set(NRF_POWER_MODE_LOWPWR);

[bjorn-spockeli]

Hi Matthew, 

I apologize for the late reply. 

You wrote: After further inspection and testing, all four of the BPROT registers have a value of 0 and it appears that there is information written in all of the flash address locations.

You mean that the entire flash, not just the region containg the application, is written to something else than 0xFFFFFFFF? Unless the hex file you flashed sets it to something else then there should not be any function in the SDK that does this. 

I have tested using the sd_flash_ -api in the ble_app_template example and I am always getting NRF_SUCCESS when writing/erasing to flash. 

Could you share the ble_app_template project you're using? If it is confidential, we'll make the case private prior to sharing it. 

Best regards

Bjørn 

[Matthew Johnson]

Hello Bjorn,

I appreciate your efforts in trying to help me. I have been working with my lead on the project and asked about sending the code to you. I'll let you know what we decide. Also, you are correct when you asked if the entire flash had something other than 0xFFFFFFFF written there. It may be something in my code, so I want to see if my lead has any suggestions before we open it up to you. Some of the addresses at the end seem to have a 'dead code' value stored as well.

Thanks again,

Matt

[bjorn-spockeli]

Happy to help. Having the actual code would make debugging this issue a lot easier. 

As for the "deadcode" value,  it's a magic word used by the FDS library to tag the flash pages it uses. 

Best regards

Bjørn