hi, Dialog,
i wonder what will happen when i write too many times into VES. For example, assuming VESpartition_entry_size / AD_NVMS_VES_MULTIPLIER = 128 / 8 = 16 kBytes. All space will be taken after write 16kB data into it for 8 times. What if i write more than 8 times? shall i erase whole VES 128kB flash before writing the 9th 16kB?
谢谢你！
Device:
Hi andoridfm2013,
Please see section 2.4.2. VES in theFlash Adapter Concepttutorial. According to he tutorial :
VES drivers provide access to a partition entry with power failure and wearing protection. To achieve this, VES drivers write data to random locations within the flash without needing to erase a whole sector when the same location is modified. This is accomplished by writing to different flash locations for the same user provided address. The VES driver provides virtual addressing, that is, the user specified address is translated to a real flash location before a read or write operation. For this to work, the flash size must be bigger than the addressing space visible to the user. A common rule of thumb is 8x the virtual EEPROM size needed.
This rule is employed in SDK using the AD_NVMS_VES_MULTIPLIER macro, found in the ad_nvms_ves.h header file. In particular, for the 1 MByte flash model the generic partition is 128 kBytes (0x20000) hence the virtual address space is around:
partition_entry_size / AD_NVMS_VES_MULTIPLIER = 128 / 8 = 16 kBytes.
In addition, the flash sectors are divided into a number of containers, where each container holds the data for a range of virtual EEPROM addresses. The size of a container is compile time configurable in 2n bytes and by default has been configured to 64 Bytes using the AD_NVMS_VES_CONTAINER_SIZE macro in ad_nvms_ves.h.
A Container Allocation Table (CAT) stored in RAM, is used for tracking where valid containers are located and a Sector Allocation Table (SAT) holds the status (%dirty, free) of each sector. The selected size for a container is a trade-off between the amount of RAM needed for the CAT and the potential number of erase cycles per sector. The smaller the size of a container, the more RAM is occupied. In particular, each entry in the CAT consists of 2 bytes. Hence, in our case for the 12 kBytes of virtual EEPROM, the formula for calculating the occupied RAM is: 12288 / (64- 4) = 205 CAT entries = 205 * 2 = 410 bytes.
Note : The VES feature should only be used when a small chunk of data is written/modified frequently in flash. As mentioned earlier, the only area marked as VES is the NVMS_GENERIC_PART partition entry. The BLE persistent storage mechanism provided by Dialog uses this partition entry and thus, the VES feature must be enabled. Otherwise, all the related operations will fail.
Could you please indicate what is your requirement and what you want to accomplish with the VES?
Thanks, PM_Dialog
hi PM_Dialog,
Thank your prompt response. i've read theFlash Adapter Concept.
I want to save error print log into flash so that android app can read it later to check why error happened.
Our android app sometimes has BLE connection broken and reconnecting also failed and as it is hard to reproduce the issue easily (it happend once every 1~2 week) so we cannot test it with RS232 print in lab but rather to try to collect error context after it happened. the partion LOG_PART is used for other prupose so i have to use NVMS_GENERIC_PART。 Since we don't know when the issue happens, there could be a lot of print log saved before the issue happens and the flash will be overwriten from time to time.
i understand the VES mechanism is to write to different location of flash to avoid erasing flash frequently, but each flash sector will ,whatever, have chance to be written once after long time of running. what happens when CAT cannot find any place that has never written?
for example: there are 128kB/8 = 16kB VES.
1.当写16 kb, 1日16 kbbe written,
2.当覆盖16 kb, 1日16 kb将marked as 'dirty' and the 2nd 16kB will be used.
3. so on.... when overwrite the 16kB for 8 times, all 128kB will be dirty.
4. what if overwriting the 16kB for the 9 time? all flash were dirty. who will responsible to erase the previously dirty 8 16kB? shall i erase whole VES flash or SDK take care of it?
if SDK take care of all erase. does that mean i can overwrite 16kB for as many times as it is within flash erase limitation? if that's the case, i will write a ring-buffer on that 16kB VES flash to keep writing print log into it.
hopefully that explains clearly.
谢谢你！
Hi There,
For logging data we strongly recommend the usage of LOG partition – you should not use the VES. The NVMS_GENERIC_PART entry is used for storing generic data such as bonding data. It should not be used for logging data. Why don’t increase the LOG partition in order to store the logging data?
Thanks, PM_Dialog
Hi PM_Dialog,
Thank your reply. our product had already delivered to customers. Increasing LOG partition cannot be done by Suota, can it? so we have to manipulate on current(default) flash partition.
I searched keyword "NVMS_GENERIC_PART" in project and it is not used at all. If the VES driver will handle the erase task after all available space in generic part had written. i think it shall be ok to store log, shall it?
谢谢你！
hi PM_Dialog,
BTW, what is "bonding data" that you've mentioned above please? is it somewhere in source code that i can refer to please?
谢谢你！
Hi andoridfm2013,
Generally, modifying the partitioning during SUOTA is something that we strongly NOT recommend especially if it is a product.
Increasing ONLY the LOG partition it MIGHT be possible if any other partitions are NOT changed (same address and same length) and if the is not any overlap. With other words, if there was an empty flash gap at the end of LOG partition, it might be possible to increase it by doing SUOTA. However, in that case you must write your own code during start up in order to erase the previous partition. It’s not straight forward implementation and it is not recommended.
In case of GENERIC part, this is marked as VES and should be used for small chunk of date. This partition is accessed by the BLE manager and includes all the BLE related information. If it is used for logging, then accessing data it will be very slow.
Regarding your last question, please see section 7 in the following user guide:
//www.xmece.com/sites/default/files/um-b-044-da1468x_software_platform_reference_6v0.pdf
Thanks, PM_Dialog