MCUXpresso: Update LPC Flash driver program page function

[mmahadevan108]

Description

Handle the case where the number of bytes to write is not aligned to page size.
The mbed-os flash tests do not check this use-case, maybe some additional tests are required for the scenarios where the write size is less than page size and greater than page size.

Pull request type

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

[mmahadevan108]

cc @0xc0170 @cmonr @maclobdell

[maclobdell]

Hi Mahesh - thanks for this PR! Just to confirm, this does not seem to support writes where the address is not aligned to 256 bytes, right? So this will be an important consideration to the calling functions - they will need to ensure they are writing to addresses on 256 byte boundaries. I will speak with the cloud client team about this.

[mmahadevan108]

Non-page aligned addresses is not supported by the flash controller.

[cmonr]

@maclobdell Will you let is know when you've heard back from the cloud client team (or better yet, invite them into this PR conversation)?

[0xc0170]

The mbed-os flash tests do not check this use-case, maybe some additional tests are required for the scenarios where the write size is less than page size and greater than page size.

FlashIAP::program checks alignment to the page size here https://github.com/ARMmbed/mbed-os/blob/master/drivers/FlashIAP.cpp#L100

[mmahadevan108]

@0xc0170 Based on the checks implemented inside FlashIAP driver do we need to add this code inside the HAL layer?

@maclobdell Is Pelion not using the FlashIAP driver?

[0xc0170]

@0xc0170 Based on the checks implemented inside FlashIAP driver do we need to add this code inside the HAL layer?

Is it possible that someone was not using the program method correctly (assumed that HAL should support it) ?
Also error can come from wrong sized get_program_size() return value (much bigger than the flash controller can do?)

[mmahadevan108]

@0xc0170 . Based on the checks available inside the FlashIAP driver do you think I can get rid of support for non-page aligned sizes for the program function.

[cmonr]

@ARMmbed/mbed-os-storage

Handle the case where the number of bytes to write is not aligned to page size.
The mbed-os flash tests do not check this use-case, maybe some additional tests are required for the scenarios where the write size is less than page size and greater than page size.

[maclobdell]

@mmahadevan108 - I don't know if this PR is necessary. There is a separate issue with the cloud client trying to write to non-page aligned addresses. This is discussed in PelionIoT/mbed-cloud-client#18, with @adamelhakham having a fix and potentially making a PR soon. That should address the problem in the cloud client code without a need to modify the flash driver.

[adamelhakham]

@maclobdell @mmahadevan108 My fix is a fix only in the SOTP feature of mbed-cloud-client which is equivalent to the mbed-os nvstore feature (that stores items in the internal flash). my fix makes sure that the writes (using the sotp feature) are aligned to the flash write unit. Using the mbed-os nvstore feature will do the same, so you may use it if you wish.
If you wish to use the driver API directly than you must make sure that the address is aligned.. I am not changing any mbed-os code

[offirko]

The comment for FLASHIAP_CopyRamToFlash() says it can handle num_of_bytes:
"The addresses should be a 256 byte boundary and the number of bytes should be 256 | 512 | 1024 | 4096."
Here num_of_bytes can be any number aligned to 256. Its worth double checking whether 256|512|1024|4096 also includes other multiplies of 256... e.g. 768

[mmahadevan108]

I modified the test to set the test_size to be page_size * 3, the tests passed.

[offirko]

I appreciate it - thanks!

[offirko]

@maclobdell - I believe this fix is required for the driver... others than cloud client may use the driver

[mmahadevan108]

Anything more needed for this PR?

[0xc0170]

@offirko Can you finilize the review? Needs approval/request changes if there's anything left.

[offirko]

LGTM

[cmonr]

Note: This PR is now a part of a rollup PR (#8686).

No further work is needed here, as once that PR is merged, this PR will also be closed and marked as merged.

If any more commits are made in this PR, this PR will remain open and have to go through CI on its own.