• State Accepted Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 23 subscribers
  • Views 3540 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

fwrite of "cnt < 4-byte" data results in ARM_Flash_ProgramData (cnt = 4-byte)

ao.h

Problem Code:

/* main.c */
uint8_t  testBuf[] = {1, 2, 3, 4, 5},

FILE * fwr = fopen("tst1.txt", "w");
fwrite(testBuf, sizeof(uint8_t), sizeof(testBuf), fwr);
fflush(fwr);
fclose(fwr);

/* flash_cmsis_driver.c */
int32_t ARM_Flash_ProgramData(uint32_t addr, const void *data, uint32_t cnt)
{
    /* Problem: cnt is 8 while it should be 5 */
    /* cnt is next nearest multiple of 4 */
}


Line 5, in this case, I am writing 5 (sizeof(testBuf)) 1-byte sized items in "tst.txt" file.

The problem I get is when the code reaches Line 10, where fwrite tries to write the testBuf data in the file. I receive the value of cnt as 8 which is not correct.
This problem is uniform: If testBuf size is 1-byte the cnt received is 4, if testBuf size is 10-byte the cnt received it 12. Hence the cnt is next nearest multple of 4.

These are some of the related configurations to support 1-byte write
/* Driver Capabilities */
static const ARM_FLASH_CAPABILITIES DriverCapabilities = {
    1,  /* Supports event ready status */
    0,  /* data_width = 0:8-bit, 1:16-bit, 2:32-bit */
    0,  /* Don't support chip erase */
    0U  /* Reserved */
};

/* Flash Information */
static ARM_FLASH_INFO FlashInfo = 
{
    FLASH_SECTOR_INFO,
    FLASH_SECTOR_COUNT,
    FLASH_SECTOR_SIZE,
    8, /* FLASH_PAGE_SIZE */
    1, /*FLASH_PROGRAM_UNIT */
    0xFF, /* FLASH_ERASED_VALUE */
    { 0U, 0U, 0U }      /* Reserved */
};


I am using Embedded File System (EFS) for my NOR Flash.


I used the Event Recorder to look at the Debug Events. Interesting things is that FsEFS: FileWrite shows the len as 5.

Additionally, another observation was this:
From the previous mentioned testBuf = {1, 2, 3, 4, 5}. If I issue fwrite only for 2-bytes i.e 1,2. The data written in Flash is 1,2,0,0.
The File system copies the data that needs to be written in the stack and analysing the data copied it was only 1,2 contrary to 1,2,3,4 for this scenario.
This means it does understand that 2-bytes needs to be written. But because the Flash_ProgramData cnt as 4 Flash drivers write the data 1,2 and next available data 0,0.

What could be the reason for getting cnt value as multiple of 4?
If I have forgotten to present some important information, do let me know!

Thank you!!

Parents
  • 0 in reply to Vladimir Umek

    It makes sense what you are saying. Could you also point out to a resource,  if possible that mentions EFS program is 4-byte aligned?
    It is integrated Flash on ADSP-CM419F (if that's what you are asking)

    "The memory cell size depends on the device architecture and is 8- (byte), 16- (half word) or 32-bit wide (word). The memory cell architecture also defines smallest programmable unit, which must be maximum 32-bit for use with the Embedded File System."

    Referred from: Line 7, Link: https://www.keil.com/pack/doc/mw/FileSystem/html/emb_fs.html

    I     assumed looking at this, that it might be possible. Hence, I tried to change the configuration so that the EFS's smallest program unit is 8-bit wide (or 1-byte).


Reply
  • 0 in reply to Vladimir Umek

    It makes sense what you are saying. Could you also point out to a resource,  if possible that mentions EFS program is 4-byte aligned?
    It is integrated Flash on ADSP-CM419F (if that's what you are asking)

    "The memory cell size depends on the device architecture and is 8- (byte), 16- (half word) or 32-bit wide (word). The memory cell architecture also defines smallest programmable unit, which must be maximum 32-bit for use with the Embedded File System."

    Referred from: Line 7, Link: https://www.keil.com/pack/doc/mw/FileSystem/html/emb_fs.html

    I     assumed looking at this, that it might be possible. Hence, I tried to change the configuration so that the EFS's smallest program unit is 8-bit wide (or 1-byte).


Children
  • 0 Arm Employee Badge in reply to ao.h

    Yes, I was interested in the type of device used, just to check the properties of flash array.

    During mount operation EFS only checks if smallest programmable unit is 4-byte or less and is happy if this is true. There is no actual handling of this setting (except extending data to 4-bytes as you noticed).

    Just keep in mind that every open/write/close sequence also appends "allocation information" which is 8-bytes. Writing only one byte actually requires 12 bytes of memory. It is obvious then why it is recommended that data is written in large chunks. But sure, there are many situations where writing one or few bytes is how we want to get things done.

  • 0 in reply to Vladimir Umek

    Thanks for the answers Vladimir, I will accept your answer after reply to the following.

    As you said, I do acknowledge that it is preferable to write in large chunks considering the overhead of 8-bytes/allocation record.

    To summarise and confirm the answer:

    • The program unit configuration is just a check
    • The smallest program unit possible in EFS is 4-byte


    Is that right?

  • 0 Arm Employee Badge in reply to ao.h

    Yes, this is correct for EFS.

    And just to clarify to avoid potential confusion for future readers: "Smallest programmable unit" configuration is part of CMSIS-Driver Flash (see ARM_FLASH_INFO) and should therefore be correctly handled in the Flash driver.