About bad writing of sflash on WICED framework.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
HiIw_4620611
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

Hello

While downloading on the air, my app is writing to external sflash with wiced_framework_app_write_chunk() function.

MPU:STM32F412

SRAM:MX25L3233

After writing all data, do checking of CRC32 from external flash by wiced_framework_app read_chunk() function.

When comparing the written data with the read data, about 1.1% of the data errors were found in 1MB.

The contents of the error are the following 3 patterns.

  1. FF ... About 1% of the whole, it is thought that several bytes to several tens of bytes are continuous, and not written.
  2. 00 ... About 0.1% of the whole, it is thought that 3 bytes are continuous and not erased.
  3. Others ... Since it is 2 bytes and the position is continuous with 2., it is considered that it is not completely erased.

Of these, 1. was resolved by <https://community.cypress.com/message/29678> as a result of a search for community.

This was two years ago, but has not yet been corrected in the libraries included in WICED studio 6.4.0.61.

From this, it is considered that other unfixed defects are included in WICED.

Items related to the above are given priority.

If there is an errata, please expand the information.

Is the operation of the WICED library guaranteed? (is it sample?)

Thank you.

0 Likes
1 Solution

Hello.

Although there were some implementation mistakes, measures were taken by setting the chunk size to a power of 2.

By the way, it seems that there is no problem with max_write_size=256 in MX25L3233.

Also, the calculation of write_size in sflash_write() is obviously a bug, so I think it should be fixed officially.

write_size = MIN( size, max_write_size );
#if 1   // correcting write_size to properly write page block.
#define PAGE_SIZE 256
{
    unsigned int     page_remaining = PAGE_SIZE - ( device_address % PAGE_SIZE )
    if (write_size > page_remaining)
    {
        write_size = page_remaining;
    }
}
#endif  // see <https://community.cypress.com/message/29678>

If have problems, I ask again.

Thanks.

Also, the calculation of write_size of sflash_write is obviously a bug, so I think it should be fixed officially.

View solution in original post

3 Replies
HiIw_4620611
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

Hello, It is a follow-up report.

Analysis showed that patterns 2 and 3 did not fail to erase.

If the final write is completed in the middle of a page by a split write (x-bytes-at-a-time write) using sflash_write(),

the last 1-3 bytes appear to have failed.

The operation log is attached below...

*** After writing 1MB, extract only error locations. ***

0000063F: 00 0B 08 ... (A)

00000A38: 00 0B 08 ... (B)

00000E31: 00 0B 08 ... (C)

0000122A: 00 0B 08

00001623: 00 0B 08

00001A1C: 00 0B 08

00001E15: 00 0B 08

0000220E: 00 0B 08

00002607: 00 0B 08

00002A00: 00 0B 08

00002DF9: 00 0B 08

00002E3B: 00

00002E4D: 00

00002EE0: 00

000032D9: 00 0B 08

000036D2: 00 0B 08

00003ACB: 00 0B 08

00003EC4: 00 0B 08

000042BD: 00 0B 08

000046B6: 00 0B 08

00004AAF: 00 0B 08

00004EA8: 00 0B 08

000052A1: 00 0B 08

0000569A: 00 0B 08

00005A93: 00 0B 08

00005E8C: 00 0B 08

00005ECE: 00

00005EE0: 00

000062D9: 00 0B 08

000066D2: 00 0B 08

00006ACB: 00 0B 08

00006EC4: 00 0B 08

000072BD: 00 0B 08

000076B6: 00 0B 08

00007AAF: 00 0B 08

00007B3C: 00

00007F35: 00 0B 08

0000832E: 00 0B 08

00008727: 00 0B 08

00008B20: 00 0B 08

00008F10: 00 00 00

*** sflash_write() log of the above error location(A-C). ***

@@@ download chunk: 780(+2)-> 585, total:  585( 0%)

size=585, write_size=128, address=06C000, data_ptr=0x2002f654

size=457, write_size=128, address=06C080, data_ptr=0x2002f6d4

size=329, write_size=128, address=06C100, data_ptr=0x2002f754

size=201, write_size=128, address=06C180, data_ptr=0x2002f7d4

size=73, write_size=73, address=06C200, data_ptr=0x2002f854

===> No error

@@@ download chunk:1352(+2)->1017, total:  1602( 0%)

size=1017, write_size=128, address=06C249, data_ptr=0x2002f657

size=889, write_size=55, address=06C2C9, data_ptr=0x2002f6d7

size=834, write_size=128, address=06C300, data_ptr=0x2002f70e

size=706, write_size=128, address=06C380, data_ptr=0x2002f78e

size=578, write_size=128, address=06C400, data_ptr=0x2002f80e

size=450, write_size=128, address=06C480, data_ptr=0x2002f88e

size=322, write_size=128, address=06C500, data_ptr=0x2002f90e

size=194, write_size=128, address=06C580, data_ptr=0x2002f98e

size=66, write_size=66, address=06C600, data_ptr=0x2002fa0e

===> Error in 06C63F: 00 0B 08 ... (A)

@@@ download chunk:1352(+2)->1017, total:  2619( 0%)

size=1017, write_size=128, address=06C642, data_ptr=0x2002f657

size=889, write_size=62, address=06C6C2, data_ptr=0x2002f6d7

size=827, write_size=128, address=06C700, data_ptr=0x2002f715

size=699, write_size=128, address=06C780, data_ptr=0x2002f795

size=571, write_size=128, address=06C800, data_ptr=0x2002f815

size=443, write_size=128, address=06C880, data_ptr=0x2002f895

size=315, write_size=128, address=06C900, data_ptr=0x2002f915

size=187, write_size=128, address=06C980, data_ptr=0x2002f995

size=59, write_size=59, address=06CA00, data_ptr=0x2002fa15

===> Error in 06CA38: 00 0B 08 ... (B)

@@@ download chunk:1352(+2)->1017, total:  3636( 0%)

size=1017, write_size=128, address=06CA3B, data_ptr=0x2002f657

size=889, write_size=69, address=06CABB, data_ptr=0x2002f6d7

size=820, write_size=128, address=06CB00, data_ptr=0x2002f71c

size=692, write_size=128, address=06CB80, data_ptr=0x2002f79c

size=564, write_size=128, address=06CC00, data_ptr=0x2002f81c

size=436, write_size=128, address=06CC80, data_ptr=0x2002f89c

size=308, write_size=128, address=06CD00, data_ptr=0x2002f91c

size=180, write_size=128, address=06CD80, data_ptr=0x2002f99c

size=52, write_size=52, address=06CE00, data_ptr=0x2002fa1c

===> Error in 06CE31: 00 0B 08 ... (C)

... continued ...

As far as I see this、A bug of generic_sflash_command() or sflash_platform_send_recv() of lower layer function.

Do you have any information on this subject?

For the time being, It is conceivable to set sflash_write() so that the chunk size is a multiple of 128 or 256 and no fractions appear.

Do you agree with this perception?

Also, what is the comment ("TODO: this should be 256, but that causes write errors") in max_write_size defined in the compile SW:SFLASH_SUPPORT_MACRONIX_PARTS?

The MX25L3233 has a page size of 256, and it is considered that no error occurs even if max_write_size=256.

Thank you.

0 Likes
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

Hello

Can you please provide the application along with the test procedure that was followed by you which resulted in the observation of these errors. It would be very helpful for me to reproduce the issue and figure out what may be going wrong.

Thanks

Hello.

Although there were some implementation mistakes, measures were taken by setting the chunk size to a power of 2.

By the way, it seems that there is no problem with max_write_size=256 in MX25L3233.

Also, the calculation of write_size in sflash_write() is obviously a bug, so I think it should be fixed officially.

write_size = MIN( size, max_write_size );
#if 1   // correcting write_size to properly write page block.
#define PAGE_SIZE 256
{
    unsigned int     page_remaining = PAGE_SIZE - ( device_address % PAGE_SIZE )
    if (write_size > page_remaining)
    {
        write_size = page_remaining;
    }
}
#endif  // see <https://community.cypress.com/message/29678>

If have problems, I ask again.

Thanks.

Also, the calculation of write_size of sflash_write is obviously a bug, so I think it should be fixed officially.