Skip to content

Fix: Allow target size restriction for LPC55S69 #10792

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 19, 2019

Conversation

hugueskamba
Copy link
Collaborator

Description

The build tool uses the sector size found in the CMSIS Pack to determine if
the size that can be specified by target.restrict_size is enough to fit
all the parts of a given binary. See target.restrict_size documentation
in the Mbed OS manual for more information.

The sector size found in the CMSIS Pack is overriden to allow the build
tool to accurately make the decision.

The target's sectors in the CMSIS Pack are defined in 32KB pages.
However, you can erase pages at the 512 byte level.

This commit changes defined sector erase size to 512 bytes instead of
32 kilobytes.

Pull request type

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

Reviewers

@bridadan @theotherjimmy

Fixes internal issue IOTCORE-1149

The build tool uses the sector size found in the CMSIS Pack to determine if
the size that can be specified by `target.restrict_size` is enough to fit
all the parts of a given binary. See `target.restrict_size` documentation
in the Mbed OS manual for more information.

The sector size found in the CMSIS Pack is overriden to allow the build
tool to accurately make the decision.

The target's sectors in the CMSIS Pack are defined in 32KB pages.
However, you can erase pages at the 512 byte level.

This commit changes defined sector erase size to 512 bytes instead of
32 Kilobytes.
@ciarmcom ciarmcom requested review from bridadan, theotherjimmy and a team June 7, 2019 17:00
@ciarmcom
Copy link
Member

ciarmcom commented Jun 7, 2019

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

@@ -2058,7 +2058,8 @@
"detect_code": ["0236"],
"device_name": "LPC55S69JBD100",
"release_versions": ["5"],
"program_cycle_s": 10
"program_cycle_s": 10,
"sectors": [[0,512]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Page erase is defined at 256 byte in
https://www.nxp.com/docs/en/user-guide/UM11126.pdf (page 3)
So 512 will work but we could optimise further.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with you. However, @offirko left the following comment on the internal ticket:

Jimmy Brisson - please note that while LPC55S69 has 32KB sector size, it supports 512-bytes Page Erase command (subsectors).

When target's erase sector size is queried it returns Page Erase size of 512-bytes. (this is the value eventually used by FlashIAP block device,..etc)

uint32_t flash_get_sector_size(const flash_t *obj, uint32_t address)

Could we change the sector size defined at index.json to 512-bytes ?

I would prefer to leave it as 512 bytes to avoid introducing potential bugs. This is unless we also want to change the define for the flash page size. @evedon Please advise.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not do this change now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Page erase is defined at 256 byte in
https://www.nxp.com/docs/en/user-guide/UM11126.pdf (page 3)
So 512 will work but we could optimise further.

This is a documentation error. Program and erase size is 512, thank you for finding this. We have raised an issue with the documentation team to correct this.

@0xc0170 0xc0170 requested a review from mmahadevan108 June 11, 2019 08:05
Copy link
Contributor

@bridadan bridadan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looks fine to me, nice work!

@adbridge adbridge removed the request for review from theotherjimmy June 18, 2019 17:28
@adbridge
Copy link
Contributor

CI started.

@mbed-ci
Copy link

mbed-ci commented Jun 19, 2019

Test run: SUCCESS

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

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 4, 2019

Postponing this fix to 5.13.2 as it is causing 5.13.1 RC not building for client. This fix needs further investigation - implications are bigger than it seems ( as I understood there's connection to bootloader in the internal ticket IOTSTOR-880 and we cant' get anyone from storage to help us this week).

@hugueskamba
Copy link
Collaborator Author

hugueskamba commented Jul 4, 2019

Postponing this fix to 5.13.2 as it is causing 5.13.1 RC not building for client. This fix needs further investigation - implications are bigger than it seems ( as I understood there's connection to bootloader in the internal ticket IOTSTOR-880 and we cant' get anyone from storage to help us this week).

Can you share the error(s)/warning(s) displayed when it fails to build? Is there a ticket?

@evedon
Copy link
Contributor

evedon commented Jul 4, 2019

@hugueskamba will investigate why this is causing build error for client
See following PRs:
https://github.com/ARMmbed/mbed-cloud-client-example-internal/pull/918
https://github.com/ARMmbed/mbed-client-testapp/pull/1363

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 5, 2019

As we were told, this has dependency on bootloader + client update, moving to 5.14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants