QN9020 : Internal flash write steps

[tonymakkiel]

Hi,

      I have some questions on the internal flash write am hoping someone could help with, please. 

1) On bootup, the power to the flash is enabled by default. But as soon as "plf_init" is called the power is disabled. So is it safe to assume QBlue stack, will enable the power to the flash whenever it needs to access the flash? 

2) Should the application enable the power to flash before it makes any NVDS api calls (nvds.h)? Or is it taken care of internally?

3) Section 5 of  UM10995, mentions using SRAM location (passed using plf_init) to read the flash location and then writing the data. Is the whole 4k byte read and written back with the updated data?

4) If it reads the 4k flash, how much time would be a typical write cycle take? I am thinking of how much time I need to set for the watchdog timer.

5) The document talks about using 4k area at the end of flash as backup information. When is this updated and read back?

6) Are the values on the NVDS updated immediately when a new value becomes available [ on the same handler/task ]? Or is it updated on the SRAM and updated later on a different handler?

7) According to 6.3.3.2, of  UM10995,  the SRAM location nvds_tmp_buf, can be NULL. How is the write operation handled in this case? Is this when it uses the 4k area at the end of flash?

Many Thanks,

Tony

[mario_castaneda]

Hi Tony,

1) On bootup, the power to the flash is enabled by default. But as soon as "plf_init" is called the power is disabled. So is it safe to assume QBlue stack, will enable the power to the flash whenever it needs to access the flash? 

The plf_init is called to initialize BLE hardware platform, and read out the NVDS values for the configuration that was saved.

2) Should the application enable the power to flash before it makes any NVDS api calls (nvds.h)? Or is it taken care of internally?

The stack reads out the NVDS information thought the NVDS APIs, you are enabling the power flash because you are using a different source.

3) Section 5 of  UM10995, mentions using SRAM location (passed using plf_init) to read the flash location and then writing the data. Is the whole 4k byte read and written back with the updated data?

No, it is reading only the TAGs available and needed for the BLE Stack.

4) If it reads the 4k flash, how much time would be a typical write cycle take? I am thinking of how much time I need to set for the watchdog timer.

The NVDS time is taking care of this time, so it will depend if you have invalid tags or not. However, time will not require a big time.

5) The document talks about using 4k area at the end of flash as backup information. When is this updated and read back? It is updated when the NVDS is full and the application needs to write new information, the backup saved all the NVDS and erase the invalid tags.

6) Are the values on the NVDS updated immediately when a new value becomes available [ on the same handler/task ]? Or is it updated on the SRAM and updated later on a different handler?

It will be available if you use the nvds_put APIs and if the return value is a success.

7) According to 6.3.3.2, of  UM10995,  the SRAM location nvds_tmp_buf, can be NULL. How is the write operation handled in this case? Is this when it uses the 4k area at the end of flash?

If you are passing a length, the driver will save the bytes with the value 0xFF, creating a parsing.

Regards,

Mario

[tonymakkiel]

Some follow up queries on the questions (using same numbering).

1) Once the NVDS values are read out during "plf_init", the "FLASH_VCC_EN" bit is set to 0 in PGCR1 register. So am guessing the power to the flash is disabled. So if the stack needs to update one of the NVDS data [example:  say updated IRK], does the stack internally re-enable power to the flash?

2) Does NVDS APIs check whether power to flash is disabled , and re-enable power if it is disabled for some reason [In this case disabled after plf_init]?

3) If only the tag is read, what is the 4096 bytes passed as an argument to plf_init [nvds_tmp_buf_len section 6.3.3.2, Table 38 of UM10996] used for?

4) Can you please share any details on the flash? What is the read write cycle duration? Section 5 says "Due to the physical characteristics of the FLASH, erasing must be done before writing." What is the minimum amount of data which needs to be erased to update a byte?

6) How does this work when the stack is updating any of the NVDS fields [Say if there is a TK update. Is this updated in the RAM and then updated in the NVDS from another task/thread within the stack]?

7) Sorry, I do not understand. If no temporary memory is passed [nvds_tmp_buf= NULL, nvds_tmp_buf_len = 0], what bytes are set as 0xFF ?

[mario_castaneda]

Hi Tony,

As you are reding out the NVDS memory using a JLink, it must enabled the Flash, however, the NVDS APIs initialize all this process, also the get, put and del.

3) If only the tag is read, what are the 4096 bytes passed as an argument to plf_init [nvds_tmp_buf_len section 6.3.3.2, Table 38 of UM10996] used for?

You are passing the reference for the NVDS that you could get the values that you are reading/writing.

4) Can you please share any details on the flash? What is the read-write cycle duration? Section 5 says "Due to the physical characteristics of the FLASH, erasing must be done before writing." What is the minimum amount of data which needs to be erased to update a byte? 1 Byt, but you need to care for the padding that will implement if you are not using all the 16 bytes.

6) How does this work when the stack is updating any of the NVDS fields [Say if there is a TK update. Is this updated in the RAM and then updated in the NVDS from another task/thread within the stack]?

Depending on the API that you are using, the nvds_put will save the information with a valid tag, and the previous one will change the status to invalid tag,

7) Sorry, I do not understand. If no temporary memory is passed [nvds_tmp_buf= NULL, nvds_tmp_buf_len = 0], what bytes are set as 0xFF ? I am not sure if I got your question, the buff is pointing to a NULL position.

Regards,

Mario