search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.98k forks source link

Mbed Cloud Client Example with Mbed OS6 hardfaults #13017

Closed esajaa closed 4 years ago

esajaa commented 4 years ago

Description of defect

When using the RC1 for the Mbed OS 6.0.0 for the Mbed Cloud Client Example, the device hardfaults. This does seem to happen when the device starts to connect with ethernet.

Target(s) affected by this defect ?

K64F

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

GCC_ARM 7.3.1

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

9a8c9e2c297f64c805698d72cd541ff3cd7fe538

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 ?

Change the Mbed OS version of the Mbed Cloud Client Example to point to the first release candidate of Mbed OS 6.0.0. Link to Mbed Cloud Client Example https://github.com/ARMmbed/mbed-cloud-client-example

yogpan01 commented 4 years ago

@adbridge @0xc0170 FYI.

evedon commented 4 years ago

@hugueskamba could you investigate

ciarmcom commented 4 years ago

@esajaa 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 .

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.

esajaa commented 4 years ago

Seems like this configuration change causes the issues: https://github.com/ARMmbed/mbed-os/pull/12761/files

When reverting it, the example works with the 6.0.0 RC1

ithinuel commented 4 years ago

Hello. I am unable to reproduce the crash. using :

git clone https://github.com/ARMmbed/mbed-cloud-client-example.git
cd mbed-cloud-client-example
mbed deploy
cd mbed-os
git checkout mbed-os-6.0.0-rc1
cd ..
mbed dm init -d arm.com --model-name oob
mbed compile -t GCC_ARM -m K64F -f

using gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (GNU Tools for Arm Embedded Processors 9-2019-q4-major)

confirmed with gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)

tracked it down to :

#0  0x0004614a in mstd::impl::INVOKE<Kinetis_EMAC, void (), Kinetis_EMAC* const&>(void (Kinetis_EMAC::*)(), Kinetis_EMAC* const&) (
    target=<optimized out>, fn=<optimized out>) at ./mbed-os/platform/cxxsupport/mstd_type_traits:350
adbridge commented 4 years ago

@esajaa what version of GCC are you using ?

esajaa commented 4 years ago

GCC_ARM 7.3.1. I tried it with the newer one, 9.2.1, and the example works fine with that one. Thank you for the quick support.

kjbracey commented 4 years ago

Duplicate of #12910? Need a release note that we're serious about needing GCC 9.

ciarmcom commented 4 years ago

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-2682

adbridge commented 4 years ago

Duplicate of #12910? Need a release note that we're serious about needing GCC 9.

We can add it as a requirement for mbed-os-6.0 that both GCC 9 and ARMC 6 are required...

adbridge commented 4 years ago

GCC_ARM 7.3.1. I tried it with the newer one, 9.2.1, and the example works fine with that one. Thank you for the quick support.

@esajaa can we close this now then ?

kjbracey commented 4 years ago

We can add it as a requirement for mbed-os-6.0 that both GCC 9 and ARMC 6 are required...

It is already there in the usual "supported toolchain" section, the difference is just that it's not just that we haven't tested it (but it may well work) as in the past, we know for a fact that GCC 7 will fail this time.

Anything we can do to try to pre-empt people hitting this and wasting time figuring it out would be good.

Don't think compiler version has ever really mattered that much in the past, particularly for GCC. Failures due to old versions have been rare. I reckon people are out of the habit of looking at "supported toolchains" on updates.

adbridge commented 4 years ago

I'll get Bartek to make sure that is brought front and centre...

0xc0170 commented 4 years ago

I am closing this as resolved.

ithinuel commented 4 years ago

@kjbracey-arm @adbridge there used to be a warning message when using an unsupported toolchain (version bigger than the supported one).

Maybe we could re-use that machinery to notify that change or even error to prevent any surprise ?

teetak01 commented 4 years ago

I would vote for error with known incompatible versions. I recently hit issues due to having old ARMC6.11. So better error out, than try and fail with potentially cryptic runtime issues or linker failures.

cmonr commented 4 years ago

So better error out, than try and fail with potentially cryptic runtime issues or linker failures.

Please use git blame to find relevant PRs around the warning text. I recall us having discussions around making version checks a warning vs an error.

Iirc, the rationale for making it a warning instead of an error was to inform the user and let them decide when to upgrade/change their compiler instead of being forced to update when they update Mbed OS.

adbridge commented 4 years ago

@kjbracey-arm @adbridge there used to be a warning message when using an unsupported toolchain (version bigger than the supported one).

Maybe we could re-use that machinery to notify that change or even error to prevent any surprise ?

Sounds like a good idea to me, does anyone know where that lived? Something in mbed-cli maybe ?

kjbracey commented 4 years ago

I last updated it here: https://github.com/ARMmbed/mbed-os/pull/10618

kjbracey commented 4 years ago

let them decide when to upgrade/change their compiler instead of being forced to update when they update Mbed OS.

In this particular case I think there is a workaround, which is to set platform.callback-nontrivial back to true. All the known failures are older GCC optimisation problems when that's false. A hard tool error would make it harder to use that workaround if you really didn't want to update tools, for some reason.

We could do the equivalent of #13015, and force the option true for old GCC. Would make sense, if we're going to do it for IAR (for slightly different reasons).

adbridge commented 4 years ago

@kjbracey-arm worth just double checking with @bulislaw but makes sense to me