targets.json was not specifying the same macro name as the code was
checking for, so setting was ineffective.
Making this work tripped up not-supported checks in ARMv8-M - rather than deal
with making this work, support it instead.
Both ARMv7-M and ARMv8-M slightly reduce code size and runtime impact if
mpu-rom-end is 0x1fffffff, using one fewer region.
This means default setup for ARMv8-M now requires 5 regions, with
mpu-rom-end set to default 0x0fffffff, but this can be put back to 4 by
changing the setting.
### Description
PR #8607 will cause problems for the NRF52832 and the NRF52840
in the online compiler starting with 5.10.2. This PR prevents this problem
by using a toggle in `targets.json` to enable these new defines for every
target except for the NRF52832 and NRF52840.
### Pull request type
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change
The cause of the pelion-enablement test failures for Nuvoton boards
is not caused by or related to the MPU so this patch re-enables the
MPU for these boards.
The cause of the pelion-enablement test failures for the
UBLOX_C030_U201 has been identified and corrected so this patch
re-enables the MPU for this board.
This reverts commit b217c5fe4d.
Turn off MPU for the UBLOX_C030 and MCU_M480 and all targets derived
from these. When the MPU is enabled on these platforms they do not
pass the pelion-enablement tests. Once the root cause is determined
and fixed the MPU can be re-enabled for these targets.
1. Resolve the Error: L6218E: Undefined symbol flash_get_erase_value
2. Bug fix (ADC, USART, etc.)
3. Modify the wrong name (TATGET_GigaDevice-->TARGET_GigaDevice)
4. Add new targets (GD32-F450ZI and GD32-E103VB) support to target.json
5. Add INITIAL_SP macro for GD32-F450ZI and GD32-E103VB
StackTop calculation was not adjusted when ram size was increased by using al 3 ram regions.
This caused memory allocation failures althogh enough free heap was reported
* Modify linker scripts to be compatible with bootloader and PSA
* Add memory protection
* Modify original post-build step to allow link with PSA binaries
* Config kvstore for ITS on FUTURE_SEQUANA_PSA
* Enable PSA-Crypto on PSoC6 with NVSeed
Connection status issue corrected. If the link layer status changes,
the connection status callback is now called correctly.
mbedtls headers from library are removed and the mbed-os one's are used.
When using UARTSerial sending data over the uart follows the sequence
below:
<-TX done ISR runs and sets a software interrupt to pending
<-Software interrupt fires:
-disables TX done interrupt
-calls UARTSerial TX handler which sends bytes until the uart
buffer filled (writeable returns false). Sending a byte
re-enables the TX done interrupt continuing the cycle
Due to this sequence, if the UARTSerial TX handler does not send a byte
then the transmit state machine mentioned above will get stuck with
the TX done interrupt disabled. The events causing this failure:
<-TX done ISR runs and sets a software interrupt to pending
<-Software interrupt fires:
-disables TX done interrupt
-calls UARTSerial TX handler:
-checks writeable which is true and sends a byte
<- interrupted by a higher priority interrrupt
<- TX done ISR runs, setting software interrupt to
pending again
-checks writeable which is true and sends a second byte
-Software interrupt finishes
<-Software interrupt fires:
-disables TX done interrupt
-calls UARTSerial TX handler:
-checks writeable which is false and DOES NOT SEND A BYTE
-Software interrupt finishes, the TX interrupt is still disabled
*-Byte gets sent but TX done ISR does not fire
This patch prevents the TX lockup by removing the code in the
software interrupt which disables the TX done interrupt. Disabling the
TX done interrupt at this point is not necessary so this code is safe
to remove.
With support for checking H/W UART initialized or not, we can simplify stdio management:
1. When serial_init(&stdio_uart) calls in, just set the 'stdio_uart_inited' flag.
2. When serial_free(&stdio_uart) calls in, just clear the 'stdio_uart_inited' flag.
Except above, we needn't make special handling with 'stdio_uart'.
The same H/W UART may be shared by multiple serial_t objects. This fix tries to avoid
re-configuring the same H/W UART in serial_init() when there are multiple serial_t
objects constructed. To re-configure UART, call serial_baud() and serial_format()
explicitly. This can avoid confusion when e.g. a newly constructed serial_t object
changes baudrate unexpectedly in serial_init().
jeromecoutant
Cruz Monrreal
test user
vervaekejonathan
Martin Kojtal
Kevin Bracey
Jimmy Brisson
Steve Cartmell
Russ Butler
Leszek Rusinowicz
Toyomasa Watarai
toyowata
Anna Bridge
Juho Eskeli
c_jin
Qinghao Shi
Oren Cohen
JojoS62
TomoYamanaka
Wilfried Chauveau
Kari Haapalehto
Russ Butler
ccli8
Mahesh Mahadevan
Vincent Coubard
Donatien Garnier
Netanel Gonen