Skip to content
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

CYESKIT_064B0S2_4343W Test Fails w/ Arm Compiler #13058

Closed
maclobdell opened this issue Jun 3, 2020 · 6 comments · Fixed by #13100
Closed

CYESKIT_064B0S2_4343W Test Fails w/ Arm Compiler #13058

maclobdell opened this issue Jun 3, 2020 · 6 comments · Fixed by #13100

Comments

@maclobdell
Copy link
Contributor

maclobdell commented Jun 3, 2020

Description of defect

When compiled with Arm Compiler, every Mbed OS test results in SYNC_FAILED.

The cause is that the application start address is incorrect.

Actual
By default, with no configuration changes, the post-build signing script produces an output file with a bootloader header at 0x0FFFFC00 and application at 0x10000000.

Desired
The bootloader header should start at 0x10000000 and the application should start at 0x10000400.

With GCC compiler, it works fine. I suspect a problem with the Arm linker file for this target.

Target(s) affected by this defect ?

CYESKIT_064B0S2_4343W

Toolchain(s) (name and version) displaying this defect ?

Arm compiler 6

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.0.0-beta-1

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed cli 1.10.1

How is this defect reproduced ?

get a board, provision it
import mbed os
run tests
mbed test -m CYESKIT_064B0S2_4343w -t ARM
view the output hex files

@maclobdell
Copy link
Contributor Author

maclobdell commented Jun 3, 2020

@sreeharshaangara @kyle-cypress can you check this? Please confirm test results on your side with the arm compiler.

@maclobdell
Copy link
Contributor Author

maclobdell commented Jun 3, 2020

I was able to workaround this bug by making the following modifications to the linker script.

#define FLASH_START             MBED_APP_START+BOOT_HEADER_SIZE
LR_IROM1 FLASH_START FLASH_SIZE
{
    ER_FLASH_VECTORS +0
    {
        * (RESET, +FIRST)
    }

@ciarmcom
Copy link
Member

ciarmcom commented Jun 3, 2020

@maclobdell thank you for raising this issue.Please take a look at the following comments:

We cannot automatically identify a release based on the version of Mbed OS that you have provided.
Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de
or a single valid release tag of the form mbed-os-x.y.z .
E.g. 'mbed-os-6.0.0-beta-1' has not been matched as a valid tag or sha.
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

@ciarmcom
Copy link
Member

ciarmcom commented Jun 3, 2020

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2696

@vmedcy
Copy link
Contributor

vmedcy commented Jun 11, 2020

Hi @maclobdell - thanks for reporting this bug. I investigated the behavior of ARM linker, fromelf tool and confirm the linker script tweak should address the issue (LR_IROM1 should start from 0x10000400 not 0x10000000 to produce the correct unsigned HEX).

I pushed #13100 PR.

@maclobdell
Copy link
Contributor Author

@vmedcy Thanks!

0xc0170 added a commit that referenced this issue Jun 16, 2020
Fix BOOT_HEADER_SIZE allocation in ARM scatter files (#13058)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants