Reduce flash page size from 512 to 32 bytes in PSOC6 based boards #9940

davidsaada · 2019-03-05T13:51:44Z

Description

Page size in all PSOC6 boards is 512 bytes. This is very problematic in all storage applications. This change reduces the page size (in flash_api's flash_program_page API) to 32 by reading the original page, modifying it with programmed data and programming it back. The number 32 for page size conforms to the number of times (16) this action can be done.

Tests:
FUTURE_SEQUANA_PSA - FlashIAP driver, all PSA ITS compliance tests.
CY8CKIT_062_BLE (with added FLASHIAP component) - FlashIAP driver, KVStore static tests, NVStore.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[x] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Release Notes

Reduce flash page size from 512 to 32 bytes in PSOC6 based boards

ciarmcom · 2019-03-05T14:00:32Z

@davidsaada, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

NirSonnenschein · 2019-03-05T14:23:12Z

@maclobdell could you please notify the relevant people from the cypress team

lrusinowicz · 2019-03-05T15:31:31Z

What about the number of flash sector erases? This change will reduce the usefull lifetime of flash about 16 times, won't it?
It will also slow down the write 16 times making it dramatically slow.

davidsaada · 2019-03-05T15:57:16Z

What about the number of flash sector erases? This change will reduce the usefull lifetime of flash about 16 times, won't it?

On the contrary, it will reduce the flash wearing by 16 times. Let me try and explain it using a numerical example:
Let's say we have a 16KB flash component, to which we wish to save circular data of 32 bytes items.
Now, without this change, we have a 512 page size. This means that we can only write each of these items on a single page. This means that we'll exhaust our flash after 32 writes and will need to start erasing sectors after that time.
With this change, we will write those items on the erased portion of the 512 pages. This means that we can use each physical page to store 16 items. In this case, we will exhaust the flash after 512 (32*16) times. Sector erase rate will be 16 times slower.

hennadiykytsun · 2019-03-05T16:22:15Z

You can't change page (row) size, because write API does write of the whole row = 512 bytes.

davidsaada · 2019-03-05T16:36:01Z

You can't change page (row) size, because write API does write of the whole row = 512 bytes.

This PR doesn't change the physical page size, but the one reflected to the user of this driver. The user will now be able to write pages of 32 bytes, while the driver read the 512 byte physical page, modify the 32 bytes portion in the read data and write the 512 page again.

lrusinowicz · 2019-03-05T16:38:26Z

OK, I haven't noticed you are now making page size != sector size.
So this should work and it should slow the flash writes only a bit and the overall performance should be much better - it's erase operation that is slow.
The only thing that might be required is to flush flash cache after each write.

hennadiykytsun · 2019-03-05T16:41:24Z

Each Flash sector has 512 row. The current flash driver implementation does not have APIs to erase whole sector (512 rows) and subsector (8 rows).

davidsaada · 2019-03-05T16:44:51Z

OK, I haven't noticed you are now making page size != sector size.
So this should work and it should slow the flash writes only a bit and the overall performance should be much better - it's erase operation that is slow.
The only thing that might be required is to flush flash cache after each write.

Exactly. Was going to answer your added question above, but you figured it out before that.
I'm not sure I understand what you said about flushing. I use the same Cy_Flash_ProgramRow API when programming the rows. Why should it differ from the previous state?

davidsaada · 2019-03-05T16:52:20Z

Each Flash sector has 512 row. The current flash driver implementation does not have APIs to erase whole sector (512 rows) and subsector (8 rows).

Not sure I understand what you're saying here. Erase API wasn't changed (still erases 512 byte sectors). Only change was in flash_program_page, which physically keeps programming with pages of 512 bytes, with the difference allowing the user to program 32 bytes.

hennadiykytsun · 2019-03-05T17:50:34Z

The FLASH page should be in erased state prior to calling ProgramRow API.
We are going to develop the EraseSector and EraseSubSector APIs, it will do the Flash erase operation easiest.
You did not change the page size, you just do the modification of the data that is going to be written into the Flash. If it is make sense for you it will work, because you do read->modify->write of the whole row. Just you need to care about item Build USB libs with GCC_ARM #1.

lrusinowicz · 2019-03-05T18:24:12Z

@hennadiykytsun
We are not talking about the same sectors.
Mbed flash sector is PSOC6 flash row (so it has nothing to do with PSOC6 flash sector). Sorry for the confusion.

@davidsaada

I'm not sure I understand what you said about flushing. I use the same Cy_Flash_ProgramRow API when programming the rows. Why should it differ from the previous state?

Cypress API states, that flash cache should be invalidated with Cy_SysLib_ClearFlashCacheAndBuffer() before reading flash row after it has been erased/programmed. I have missed this previously and the whole thing might be working just by chance. And now, with effectively read-modify-write operation it may not.

davidsaada · 2019-03-05T19:56:56Z

1. The FLASH page should be in erased state prior to calling ProgramRow API.

2. We are going to develop the EraseSector and EraseSubSector APIs, it will do the Flash erase operation easiest.

3. You did not change the page size, you just do the modification of the data that is going to be written into the Flash. If it is make sense for you it will work, because you do read->modify->write of the whole row. Just you need to care about item #1.

Maybe the headline is deceiving, but again - I indeed didn't change the page size, just the program size as reflected to the user. What I do there is indeed read-modify-write, which makes the user think that the page size is 32.
Regarding the row being in erase state before programming the row - true. However, it's the user's responsibility. I didn't change anything here - calling program without erasing would have failed before my change and will fail the same way after it.

davidsaada · 2019-03-05T20:08:18Z

@hennadiykytsun
We are not talking about the same sectors.
Mbed flash sector is PSOC6 flash row (so it has nothing to do with PSOC6 flash sector). Sorry for the confusion.

@davidsaada

I'm not sure I understand what you said about flushing. I use the same Cy_Flash_ProgramRow API when programming the rows. Why should it differ from the previous state?

Cypress API states, that flash cache should be invalidated with Cy_SysLib_ClearFlashCacheAndBuffer() before reading flash row after it has been erased/programmed. I have missed this previously and the whole thing might be working just by chance. And now, with effectively read-modify-write operation it may not.

I don't mind calling Cy_SysLib_ClearFlashCacheAndBuffer after each program, but again, unless I'm missing big time here, I don't understand the difference between current code and the previous one, as far as the flash is concerned, As I see it, the only difference from the flash point of view is the fact that I'm reading from the flash prior to the program. Is this what makes the difference?

lrusinowicz · 2019-03-05T20:47:20Z

As I see it, the only difference from the flash point of view is the fact that I'm reading from the flash prior to the program. Is this what makes the difference?

First, based on the description of Cypress Flash API:

\note Before reading data from previously programmed/erased flash rows, the

user must clear the flash cache with the Cy_SysLib_ClearFlashCacheAndBuffer()

function.

I know think, that original flash_program_page() should have called this clearing function in the first place. This cache (and function) is not well documented. Original implementation may be working just because read accesses to the written data (e.g. for verification) has been typically separated from the write operation with multiple instruction reads (same flash), that happened to expel previous row data from the cache. But again, I don't know the internal details of Cypress flash operations.
Now, if you happen to write consecutive pages, you will be reading and writing the same flash row without much separation, and the bug may manifest itself.

davidsaada · 2019-03-05T20:52:15Z

As I see it, the only difference from the flash point of view is the fact that I'm reading from the flash prior to the program. Is this what makes the difference?

First, based on the description of Cypress Flash API:

\note Before reading data from previously programmed/erased flash rows, the

user must clear the flash cache with the Cy_SysLib_ClearFlashCacheAndBuffer()

function.

I know think, that original flash_program_page() should have called this clearing function in the first place. This cache (and function) is not well documented. Original implementation may be working just because read accesses to the written data (e.g. for verification) has been typically separated from the write operation with multiple instruction reads (same flash), that happened to expel previous row data from the cache. But again, I don't know the internal details of Cypress flash operations.
Now, if you happen to write consecutive pages, you will be reading and writing the same flash row without much separation, and the bug may manifest itself.

Thanks, it's clearer now. So will use this PR to fix current logic.

davidsaada · 2019-03-06T08:16:06Z

Added call to Cy_SysLib_ClearFlashCacheAndBuffer at the end of flash program.
@lrusinowicz please re-review.

davidsaada · 2019-03-06T09:13:35Z

@dannybenor

hennadiykytsun

I am OK with this update, but Erase row was not done before Program row. It is possible place for bugs.

davidsaada · 2019-03-06T11:29:54Z

@ARMmbed/mbed-os-maintainers Travis failures seem unrelated to the PR (tried couple of restarts).

Page size in all PSOC6 boards is 512 bytes. This is very problematic in all storage applications. This change reduces the page size (in flash_api's flash_program_page API) to 32 by reading the original page, modifying it with programmed data and programming it back. The number 32 for page size conforms to the number of times (16) this action can be done.

davidsaada · 2019-03-06T12:02:40Z

Just pushed a small modification to the program logic, as it could get a size bigger than page size.
(verified with SEQUANA & CY8CKIT_062_BLE boards)

dannybenor

Please check line 53 in flash_api.c

davidsaada · 2019-03-06T12:23:16Z

Please check line 53 in flash_api.c

Are you sure? It's a variable declaration (maybe you need to refresh).

ghost

Meets PM criteria. Approved.

0xc0170 · 2019-03-06T15:14:49Z

CI started

mbed-ci · 2019-03-06T18:14:40Z

Test run: SUCCESS

Summary: 13 of 13 test jobs passed
Build number : 1
Build artifacts

ciarmcom requested a review from a team March 5, 2019 14:00

ciarmcom added the needs: review label Mar 5, 2019

NirSonnenschein requested a review from maclobdell March 5, 2019 14:22

0xc0170 requested a review from a team March 5, 2019 15:38

davidsaada force-pushed the david_psoc6_reduce_prog_size branch from 1f50a1b to 81c5e2f Compare March 6, 2019 08:14

lrusinowicz approved these changes Mar 6, 2019

View reviewed changes

hennadiykytsun approved these changes Mar 6, 2019

View reviewed changes

0xc0170 requested a review from a user March 6, 2019 11:47

0xc0170 added the release-version: 5.12.0-rc2 label Mar 6, 2019

davidsaada force-pushed the david_psoc6_reduce_prog_size branch from 81c5e2f to 9cacd02 Compare March 6, 2019 12:00

0xc0170 approved these changes Mar 6, 2019

View reviewed changes

dannybenor suggested changes Mar 6, 2019

View reviewed changes

dannybenor approved these changes Mar 6, 2019

View reviewed changes

ghost added the PM_ACCEPTED label Mar 6, 2019

ghost approved these changes Mar 6, 2019

View reviewed changes

0xc0170 added needs: CI and removed needs: review labels Mar 6, 2019

cmonr added ready for merge and removed needs: CI labels Mar 6, 2019

cmonr merged commit f3ecc0b into ARMmbed:master Mar 6, 2019

cmonr removed the ready for merge label Mar 6, 2019

davidsaada deleted the david_psoc6_reduce_prog_size branch March 16, 2019 08:18

Reduce flash page size from 512 to 32 bytes in PSOC6 based boards #9940

Reduce flash page size from 512 to 32 bytes in PSOC6 based boards #9940

Uh oh!

Conversation

davidsaada commented Mar 5, 2019

Description

Pull request type

Release Notes

Uh oh!

ciarmcom commented Mar 5, 2019

Uh oh!

NirSonnenschein commented Mar 5, 2019

Uh oh!

lrusinowicz commented Mar 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidsaada commented Mar 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hennadiykytsun commented Mar 5, 2019

Uh oh!

davidsaada commented Mar 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lrusinowicz commented Mar 5, 2019

Uh oh!

hennadiykytsun commented Mar 5, 2019

Uh oh!

davidsaada commented Mar 5, 2019

Uh oh!

davidsaada commented Mar 5, 2019

Uh oh!

hennadiykytsun commented Mar 5, 2019

Uh oh!

lrusinowicz commented Mar 5, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidsaada commented Mar 5, 2019

Uh oh!

davidsaada commented Mar 5, 2019

Uh oh!

lrusinowicz commented Mar 5, 2019

Uh oh!

davidsaada commented Mar 5, 2019

Uh oh!

davidsaada commented Mar 6, 2019

Uh oh!

davidsaada commented Mar 6, 2019

Uh oh!

hennadiykytsun left a comment

Choose a reason for hiding this comment

Uh oh!

davidsaada commented Mar 6, 2019

Uh oh!

davidsaada commented Mar 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dannybenor left a comment

Choose a reason for hiding this comment

Uh oh!

davidsaada commented Mar 6, 2019

Uh oh!

ghost left a comment

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Mar 6, 2019

Uh oh!

mbed-ci commented Mar 6, 2019

Test run: SUCCESS

Uh oh!

Uh oh!

lrusinowicz commented Mar 5, 2019 •

edited

Loading

davidsaada commented Mar 5, 2019 •

edited

Loading

davidsaada commented Mar 5, 2019 •

edited

Loading

lrusinowicz commented Mar 5, 2019 •

edited

Loading

davidsaada commented Mar 6, 2019 •

edited

Loading