Change the irq_handler parameter of NVIC_SetVector from a function
pointer to a uin32_t so it matches the cmsis specification. This
prevents the following problem from occurring in RTX5 when building
for IAR:
The error: Error[Pe167]: argument of type "void (*)(void)" is incompatible
with parameter of type "uint32_t".
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.
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
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 .
The USB ISTR register consists of a mix of bits that are
write-zero-to-clear and read only bits. As such, to clear a bit in
the ISTR, you should simply write the bitwise-NOT of the bit to clear.
Previously, the __HAL_PCD_CLEAR_FLAG() macro would do a bitwise-AND
with the ISTR register contents to clear a bit, but this could result
in another bit being inadvertently cleared if it is set by hardware
between the read and the write of the ISTR register.
Similarly, the USB endpoint registers have two bits that are
write-zero-to-clear, USB_EP_CTR_RX and USB_EP_CTR_TX, but the
PCD_CLEAR_RX_EP_CTR() and PCD_CLEAR_TX_EP_CTR() macros wrote back the
last read value for one of these bits when clearing the other bit.
This could result in inadvertent clearing of one of these bits if it
were set by the hardware between the read and the write. These macros
have now both been adjusted to always write one to the bit not being
cleared to prevent inadvertent clears.
Bartek Szatkowski
Jimmy Brisson
Bartosz Szatkowski
Martin Kojtal
Brian Daniels
Anna Bridge
arostm
Kevin Gilbert
Adam Green
Alexis ROCHE
0x6d61726b
Mihail Stoyanov
Laurent MEUNIER
Bradley Scott
Chris
Indrek Ardel