- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- FF ... About 1% of the whole, it is thought that several bytes to several tens of bytes are continuous, and not written.
- 00 ... About 0.1% of the whole, it is thought that 3 bytes are continuous and not erased.
- 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.
Solved! Go to Solution.
- Labels:
-
DCT
-
Memory
-
WICED Studio
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.