[OOB 5.6 r2] DISCO_F429ZI does not run by Makefile exported binary

[toyowata]

Description

• Type: Bug
• Priority: Major

---

Bug

Target
DISCO_F429ZI

Toolchain:
GCC_ARM

Toolchain version:
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors 6-2017-q1-update) 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

mbed-cli version:
1.2.0

mbed-os sha:
mbed-os-example-uvisor (a091592)
`- mbed-os (6e087488e101)

DAPLink version:
0221

Expected behavior
The example run on the target without error.

Actual behavior
There is no log output at runtime. It looks not startup correctly.

Steps to reproduce

$ mbed import mbed-os-example-uvisor
$ cd mbed-os-example-uvisor
$ mbed update mbed-os-5.6-oob2
$ mbed export -m DISCO_F429ZI -i make_gcc_arm
$ make

Flash the binary from BUILD/mbed-os-example-uvisor.bin to the target drive.

Note that the binary created by mbed compile -m DISCO_F429ZI -t GCC_ARM -f works fine. And also, binary file size is slightly different between GCC_ARM build and make_gcc_arm build (see below).

Toolchain	binary file size
GCC_ARM	63KB
make_gcc_arm	112KB

Misc. info

Build log file
Makefile

The mbed-os-example-uvisor-thread has also same problem (I did not raise a new issue, since the root cause may be same).

[ciarmcom]

ARM Internal Ref: IOTSEC-455

[theotherjimmy]

The difference in binary size is probably due to export defaulting to the debug profile, and compile the develop profile.

[theotherjimmy]

That probably also explains the not booting thing too.

[Patater]

If the exporter is building with debug profile, then yes, that's the problem. A debugger must be connected in order to run debug builds. We changed this in uVisor recently, but Mbed OS 5.6 will only ship with uVisor v0.30.0 which doesn't have this change.

[theotherjimmy]

If the exporter is building with debug profile, then yes, that's the problem.

Unless you specified otherwise, that's the behavior of exporters.

$ mbed export -m DISCO_F429ZI -i make_gcc_arm

Looks like you got the debug profile.

Try an export with:

$ mbed export -m DISCO_F429ZI -i make_gcc_arm --profile develop

That should get you somewhere.

[Patater]

What a surprising design!

Thanks for teaching us how to use the exporters.

[theotherjimmy]

What a surprising design!

Generally, surprising == bad. I suppose the default profile is what's surprising to you here, As it's not the same as the default profile for mbed compile. This is intentional: We expect that many user will export for the sake of debugging, so the debug profile makes that use case "Just Work" (tm).

Thanks for teaching us how to use the exporters.

If you can't use the debug profile, or find is surprising, I recommend adding a note about exporting in your documentation.

[Patater]

Yeah, you are right about what surprises me. It's surprising (at least to me) that mbed compile defaults to a different profile than mbed export.

It'd be interesting to get some real data from users on how they use mbed export (e.g. with or without --profile) and how users expect mbed export to work. Your hunch may be correct and the current design might be the right thing to do (despite my personal surprise), but how would you know unless you measure?

[theotherjimmy]

but how would you know unless you measure?

Too true.

I can tell you from watching Core mbed OS developers use the mbed export command, they all seem to expect to immediately start debugging. There might be some confirmation bias there though :D.

[theotherjimmy]

It'd be interesting to get some real data from users on how they use mbed export (e.g. with or without --profile)

Well, I think that most users don't know about the --profile parameter, and use the online exporters, which have no way to specify that parameter.

[Patater]

@toyowata Please try using the --profile develop option with the exporter.

The exporter defaults to using a different profile that mbed compile, so you'll get different results from mbed compile unless you specify the --profile.

[toyowata]

@theotherjimmy @Patater

Thank you very much for your comment.

Please try using the --profile develop option with the exporter.

Unfortunatly, it still doesn't work.

The size of binary has now been similar than GCC_ARM build by develop profile export (see Makefile), but runtime behavior is same as default debug profile. I also tried to use ---profile release and got same result.

Toolchain	binary file size
GCC_ARM	63KB
make_gcc_arm (default)	112KB
make_gcc_arm (--profile develop)	63KB

I used K64F for this test and it does not work either. Didn't you reproduce the problem?

Other example such as mbed-os-example-blinky works fine as expected.

$ mbed import mbed-os-exapmle-blinky
$ cd mbed-os-example-blinky
$ mbed update mbed-os-5.6-oob2
$ mbed export -m DISCO_F429ZI -i make_gcc_arm --profile develop
$ make

[theotherjimmy]

@toyowata Did you run make clean after exporting to a different profile? Unlike mbed compile the make files do not try to make C/C++ files depend on the profile.

[toyowata]

@theotherjimmy Yes I did. What I did is:

$rm -r .\BUILD
$rm .\Makefile
$mbed export -m DISCO_F429ZI -i make_gcc_arm --profile develop
$make clean
$make

[theotherjimmy]

Odd. that should work...