Mbed-os: Fault Occuring in mbed::CAN constructor in Debug profile, but not in Develop profile

[ssnover]

Description

• Type: Bug
• Priority: Blocker

---

Bug

Target
NUCLEO_F302R8

Toolchain:
GCC_ARM

Toolchain version:
6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]

mbed-cli version:
1.2.2

mbed-os sha:
caeaa49

DAPLink version:
N/A

Expected behavior
An instance of mbed::CAN is constructed and the program runs using Debug profile.

Actual behavior
If object is constructed using profile debug.json the program goes to a fault mode (LD2 on ST-NUCLEO 64 blinks S.O.S.). This behavior is not present when using profile develop.json.

I have however found that running the same code under both profiles on a NUCLEO_F446RE did not yield the fault. Executables built with both profiles ran just fine.

I noted that with NUCLEO_F302R8 it is not set to be built under mbed OS 5 (I had to modify the targets.json to get it to build), however this is the first instance where I've run into an issue with using the NUCLEO_F302R8.

Steps to reproduce
A minimal example showing the error is here: https://gist.github.com/ssnover95/b94058a0edb987f5e65c4ad2d100ad33

Is there documentation available regarding what changes need to be made for a target that is not supported by mbed OS 5, but was in a previous version? If the list isn't too long I'd be happy to investigate making those changes.

[0xc0170]

@ARMmbed/team-st-mcd Please review

Is there documentation available regarding what changes need to be made for a target that is not supported by mbed OS 5, but was in a previous version? If the list isn't too long I'd be happy to investigate making those changes.

there's porting guide here https://os.mbed.com/docs/latest/reference/contributing-target.html . This is for adding a new target. In your case, adding mbed OS 5 to already existing target for mbed 2: It should work in theory just to enable release version 5 and run tests using (mbed test) and be certain that a target supports all 3 toolchains. Note to check how much RAM does your target has, if it has enough for rtos and application space

[bcostm]

I noted that with NUCLEO_F302R8 it is not set to be built under mbed OS 5

This is normal. We have enabled mbedOS 5 only on boards with more than 64KB of flash.

I don't know the relation between this and the debug/release profiles, but it looks that there is one...

[ssnover]

I've created a brand new mbed-cli project on my machine and made only one edit: enabling release version 5 in targets.json. Here's a gist containing the end of the build output: https://gist.github.com/ssnover95/b800a6bc018e4a4c41ed6554754e96aa

Two things stuck out to me:

• The error at the end of course. Should I have the target board plugged into my machine while I run mbed test? I see it's looking for a device at /dev/serial/. My development boards normally enumerate under /dev/ttyACM*.
• A number of tests were skipped. What drives the decision behind which tests are skipped?

I've done some further digging through the source and can see that the CAN constructor has a route down to an error call which is called under two conditionals in can_registers_init in mbed-os/targets/TARGET_STM/can_api.c. When I get to a Windows machine later I can export the gist program I linked in the original post to Keil and check if these conditions are the culprit.

[0xc0170]

The error at the end of course. Should I have the target board plugged into my machine while I run mbed test

yes, at the beginning of the test, there's sync between host and a target, so a test wont start until the sync happens.

A number of tests were skipped. What drives the decision behind which tests are skipped?

If a target does not support a feature for instance. The test shows an error unsupported and that leads to a test to be skipped

[jeromecoutant]

Hi

If object is constructed using profile debug.json the program goes to a fault mode (LD2 on ST-NUCLEO 64 blinks S.O.S.). This behavior is not present when using profile develop.json.

Using debug profile is increasing a lot the flash memory need.
That's why your application can be OK in default profile but not in debug.

I have however found that running the same code under both profiles on a NUCLEO_F446RE did not yield the fault

Yes, flash memory is much more important for this NUCLEO.

So, keep NUCLEO_F302R8 in OS2.

[0xc0170]

@jeromecoutant @bcostm Is there any action needed for this issue ?

[jeromecoutant]

Hi

I don't think there is any action on our side..
We should close the issue ?

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-245

[jeromecoutant]

@0xc0170 could you close it ? Thx

[0xc0170]

@0xc0170 could you close it ? Thx

I am not certain. The issue seems to be still valid. @ssnover95 Is that correct? Have you resolved this?

[ssnover]

@0xc0170 I ended up writing my own driver, have not tried to replicate this recently.

[0xc0170]

Thanks for the update.

I don't think there is any action on our side..

@jeromecoutant The hard fault however has not yet been addressed ? The target runs mbed 2 , CAN is in drivers, so not any issue there with CAN as reported above? I just want to be sure we close the issue that is either fixed or won't fix with a reason.

[jeromecoutant]

Hi

As I said, using debug profile is increasing a lot the flash memory need.
NUCLEO_F302R8 is a very small target.

[0xc0170]

Understood as the bug might be because low on memory ? (however even if it is small target, debug profile should be considered as it can uncover potential problems that might arise also in other profiles - not ignoring it), from the above report was not clear what fault is it causing (don't see any logs, call stack or anything closer to what is causing it to fail - when/how).

@ssnover95 If you moved to your own driver, consider closing this issue as it looks like won't fix issue.