Serial broken with Nucleo F303K8 on GCC-ARM

[ducky64]

Deploying code exported to GCC-ARM from the mbed online compiler using Serial causes the microcontroller to freeze and end up in WWDG_IRQHandler().

If compiled against the mbed library (at tag mbed_lib_rev116) from scratch (as opposed to the pre-compiled .a supplied from the online compiler export), stepping through has it failing in
_file = std::fopen(buf, "w+"); (mbed/common/Stream.cpp:24)

The instruction call stack looks like (inside the std::fopen call):
Serial uart(SERIAL_TX, SERIAL_RX);
mbed::Stream::Stream()
_fopen_r()
__sfp()
__sinit()
std.isra.0
where the last instruction executed is:
08005376: str r3, [r0, #0]
(where register r0 = 0, presumably what causes the hardfault)

Note that manually invoking the serial API functions seems to work:

serial_t obj;
serial_init(&obj, SERIAL_TX, SERIAL_RX);
serial_putc(&obj, 'x');

so the root cause of the problem doesn't appear to be the serial HAL, but rather the interaction of the system libraries with ... something ...

I'm using gcc version 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848] (GNU Tools for ARM Embedded Processors).

Possibly related to this issue:
https://developer.mbed.org/forum/bugs-suggestions/topic/25983
which is 24 days old without a resolution.

[0xc0170]

@ducky64 I recommend using v4.x for now, however as noted in the link referenced it still valid for gcc v4.x.

cc @bcostm @adustm

[ducky64]

I attempted to do some debugging (with GCC 5.2, but hopefully results are still applicable), and found:

• std::fopen fails because malloc fails
• malloc fails because the static heap pointer (in mbed/common/retarget.cpp: _sbrk) is past the stack (well, actually past the range of valid SRAM addresses)
• This is also the case with the initial invocation of _sbrk, but presumably whatever called it had more graceful error handling.
• The static heap pointer in _sbrk is getting clobbered in SystemInit. In particular, NVIC_SetVector in TARGET_NUCLEO_F303K8 thinks there are 101 interrupt vectors (from cmsis_nvic.h), but the linker script only allocated space for 98. This causes the first few bytes of the .data segment to be overwritten.
• Changing the NVIC number of vectors to 98 solves the problem.

[0xc0170]

Thanks for the write-up ! We will have a look at the fix

[adustm]

Hello, @ducky64 is right. The define in cmsis_nvic.h is not correct
#define NVIC_NUM_VECTORS 101
should be 98 (checked in datasheet and reference manual for the STM32F303K8)
As it is not aligned with the size defined in linker scripts, it leads to memory overwrite.
Thanks for the investigation. I'll fix this.

[0xc0170]

@adustm look at the referenced pull request (2 comments above) with the fix

[adustm]

Hello,
This issue has been fixed in PR #1633. Could you close it, please ?
Cheers
Adu

[bcostm]

To be closed