targets/targets.json already added MCU_LPC11U35_501 as an extra label
but it didn't have LPC11U35_501 (without the MCU_ prefix). Both of
these target names are used as folder names to organize files
specific to this device. For example the LPC11U35.ld linker script used
by GCC_ARM for this target is located in a TARGET_LPC11U35_501 folder.
I switched to using inheritance to properly setup the target labels
based on @theotherjimmy comments on PR #4252. Everything in the
XADOW_M0 targe appears to have been copy/pasted from LPC11U35_501
anyway so inheritance seems to be the best way to set the values of
the XADOW_M0 properties.
failing on file allocation / opening during Stream creation.
The consequence was application continues running, but any printf
to the Serial object whose Stream was not properly created
would not show any error (and characters would not show either)
Let's add a check to properly inform user of the error.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
NXP LPC176x/5x User Manual UM10360 Rev 4.1:
32.3.2.8 RAM used by IAP command handler
Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack
usage in the user allocated stack space is 128 bytes and it grows downwards.
When attempting to perform a test build of various mbed-os targets with
GCC configured to build -std=gnu++11, all of the targets built
successfully except for this one. It gave errors like this:
../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp: In function 'emac_interface_t* wifi_emac_get_interface()':
../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp:331:38: error: use of deleted function 'emac_interface::emac_interface()'
_intf = new emac_interface_t();
^
In file included from ../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp:9:0:
../mbed-os/hal/emac_api.h:150:16: note: 'emac_interface::emac_interface()' is implicitly deleted because the default definition would be ill-formed:
typedef struct emac_interface {
^
../mbed-os/hal/emac_api.h:150:16: error: uninitialized const member in 'struct emac_interface'
../mbed-os/hal/emac_api.h:151:32: note: 'const emac_interface_ops_t emac_interface::ops' should be initialized
const emac_interface_ops_t ops;
This commit contains a proposed change which fixes this issue by not
using the new operator to allocate the emac_interface_t structure but
instead using the malloc() function since the construction is being
handled explicitly in the subsequent lines of the
wifi_emac_get_interface() function anyway.
I also added code which only completes the initialization of the _intf
object if its allocation succeeds and just returns NULL otherwise.
I see no deallocation of the _intf object occurring so no change from
delete to free() needed to be made.
Revert HRM1017 file source deletion
Added in small comment next to additions
Added mapping to BTN-labelled switches
Added mapping to USER_BUTTON-labelled switches
Undo incorrect mapping to SWIO pin in NORDIC target
mbed_lwip_set_mac_address calls mbed_mac_address to get hwaddr
from device, but device may not be accessible until it is powered
up and initialized.
This patch delays mbed_lwip_set_mac_address call until device is
ready.
Signed-off-by: Tony Wu <tonywu@realtek.com>
Before this patch, many warnings like below were generated
during compilation with ArmCC
[Warning] lwip_ethernet.h@57,0: #3135-D: attribute does not apply to any entity
This happens here as ``--gnu`` option of ArmCC is being used, which
enables the GNU compiler extensions that the ARM compiler supports.
This is solve by adding a extra check on __CCARM .
arostm
Kevin Gilbert
Sam Grove
Adam Green
Jimmy Brisson
Laurent MEUNIER
Alexis ROCHE
0x6d61726b
Christopher Haster
Mihail Stoyanov
Martin Kojtal
justinkim
Tony Wu
Tony Wu