Application crash when target default build is "small"

[pan-]

If the target default_build option is set to small then if the program is compiled with the instructions provided in the readme and run, it will crash at the instantiation of the thread.

A small build will force the use of nanolib and restrict the number of threads to one, the main thread. In that configuration, instantiating a thread will crash the application.

One easy fix would be to update the compilation instruction to:

mbed compile -m <target_name> -t GCC_ARM -o big-build

Or provide and errata indicating the list of targets concerned by this issue and that -o big-build should be added to the command line.

The list of the targets using nano lib is:

CM4_UARM
CM4_ARM
CM4F_UARM
CM4F_ARM
LPC1114
LPC11U24
OC_MBUINO
LPC11U34_421
MICRONFCBOARD
LPC11U35_401
LPC11U35_501
LPC11U35_501_IBDAP
XADOW_M0
LPC11U35_Y5_MBUG
LPC11U37_501
LPCCAPPUCCINO
ARCH_GPRS
LPC11U68
LPC1549
LPC810
LPC812
LPC824
SSCI824
LPC11U37H_401
ELEKTOR_COCORICO
KL05Z
NUCLEO_F030R8
NUCLEO_F031K6
NUCLEO_F042K6
NUCLEO_F070RB
NUCLEO_F072RB
NUCLEO_F091RC
NUCLEO_F103RB
NUCLEO_F302R8
NUCLEO_F303K8
NUCLEO_F303RE
NUCLEO_F334R8
NUCLEO_F401RE
NUCLEO_F410RB
NUCLEO_F411RE
ELMO_F411RE
NUCLEO_F446RE
B96B_F446VE
NUCLEO_L031K6
NUCLEO_L053R8
NUCLEO_L073RZ
NUCLEO_L152RE
NUCLEO_L476RG
STM32F3XX
DISCO_F051R8
DISCO_F100RB
DISCO_F303VC
DISCO_F334C8
DISCO_F429ZI
DISCO_F469NI
DISCO_L053C8
DISCO_L476VG
MOTE_L152RC
UBLOX_C029
NZ32_SC151
MCU_NRF51
MCU_NRF51_16K_BASE
MCU_NRF51_16K_BOOT_BASE
MCU_NRF51_16K_OTA_BASE
MCU_NRF51_16K
MCU_NRF51_S110
MCU_NRF51_16K_S110
MCU_NRF51_16K_BOOT
MCU_NRF51_16K_BOOT_S110
MCU_NRF51_16K_OTA
MCU_NRF51_16K_OTA_S110
MCU_NRF51_32K
MCU_NRF51_32K_BOOT
MCU_NRF51_32K_OTA
NRF51822
NRF51822_BOOT
NRF51822_OTA
ARCH_BLE
ARCH_BLE_BOOT
ARCH_BLE_OTA
ARCH_LINK
ARCH_LINK_BOOT
ARCH_LINK_OTA
SEEED_TINY_BLE
SEEED_TINY_BLE_BOOT
SEEED_TINY_BLE_OTA
HRM1017
HRM1017_BOOT
HRM1017_OTA
RBLAB_NRF51822
RBLAB_NRF51822_BOOT
RBLAB_NRF51822_OTA
RBLAB_BLENANO
RBLAB_BLENANO_BOOT
RBLAB_BLENANO_OTA
NRF51822_Y5_MBUG
WALLBOT_BLE
WALLBOT_BLE_BOOT
WALLBOT_BLE_OTA
DELTA_DFCM_NNN40
DELTA_DFCM_NNN40_BOOT
DELTA_DFCM_NNN40_OTA
NRF51_DK
NRF51_DK_BOOT
NRF51_DK_OTA
NRF51_DONGLE
NRF51_DONGLE_BOOT
NRF51_DONGLE_OTA
NRF51_MICROBIT
NRF51_MICROBIT_BOOT
NRF51_MICROBIT_OTA
NRF51_MICROBIT_B
NRF51_MICROBIT_B_BOOT
NRF51_MICROBIT_B_OTA
TY51822R3
TY51822R3_BOOT
TY51822R3_OTA
EFM32ZG_STK3200
EFM32HG_STK3400

That is a total of 119 targets out of the 184 available in targets.json.

[MarceloSalazar]

It seems this issue is affecting the tests on multiple platforms during OOB. We should remove the limitation on using a small build when selecting gcc

@sg- please comment on this

[sg-]

why would we remove this restriction? They are single threaded because of a memory limitation or are misconfigured.

[0xc0170]

why would we remove this restriction? They are single threaded because of a memory limitation or are misconfigured.

@MarceloSalazar meant that this example should provide a better indication for single thread targets (either error that the example is not for single thread targets, and how to enable it) ? Or just provide a documentation update to document this behavior. A crash does not say much for a user

[0xc0170]

@pan- Anyway, as we provide single thread option, how does the app crash? I would imagine it would not create any thread, neither start it, and app would just continue executing?

[MarceloSalazar]

The current blinky requires 2 threads. If we see this a problem for constrained devices, may need to have a single-thread-blinky app where the LED state is swapped in main.

[0xc0170]

may need to have a single-thread-blinky app where the LED state is swapped in main.

@bogdanm or me will send a patch to resolve this

[bogdanm]

This should be fixed now since blinky doesn't create any additional threads, can you please check?

[pan-]

Checked on NRF51, it works. Thanks.