The DEVICE_FOO macros are always defined (either 0 or 1).
This patch replaces any instances of a define check on a DEVICE_FOO
macro with value test instead.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
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
### Description
The Mbed 2 release was broken for FF_LPC546XX as it would include
the entire mbed 2 build of the LPC546XX. This PR seperates these 2
builds completely by:
* Removing non-shared extra labels from the MCU_LPC546XX target
* Moving the target implementation to a shared target directory
### Pull request type
[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change
--legacyalign, --no_legacyalign are deprecated from ARMC6 compiler, in order to
remove deprecated flags all linker files (GCC and IAR as well to have uniformity)
should strictly align to 8-byte boundary
1. Add Pin defines for missing PWM pins
2. Update the hal to account for the number of PWM instances
3. Fix the register reload policy
4. Configure the XBAR to put the PWM fault inputs in inactive state
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
1. Added a flag to issue START command
2. Do not send START command inside i2c_start function as
the LPI2C hardware will issue a STOP on reception
of a NACK
3. Remove the i2c_address global variable, this is not
required
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
1. Remove the repeated_start flag and code as this is not needed
for the LPI2C module
2. Enable the SION bit on the I2C pins
3. Enable 22K Pullup option of the I2C pins
4. Update the 0 byte write implementation to ensure the START
command gets flushed out of the FIFO
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Low power functions related to powering off FLEXSPI and SDRAM needs
to be copied to internal memory
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
This PR provides implementation of ticker_free() function for the following boards:
ARCH_PRO
EV_COG_AD3029LZ
EV_COG_AD4050LZ
K22F
K64F
K82F
KW24D
KW41Z
LPC546XX
NRF51_DK
NRF52_DK
NUCLEO_F207ZG
NUCLEO_F401RE
NUCLEO_F429ZI
NUCLEO_F746ZG
REALTEK_RTL8195AM
1. Add the IVT header to the binary as this is required for boot up
This was earlier added by the DAPLink firmware. As it is no longer
handled in DAPLink, the header needs to be added inside mbed.
2. Update drivers
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
1. Problems were seen on the LPC54628 as the ADC clock source was too
high
2. Moved the pin configuration to set Analog mode to the end of the
function
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Sleep - within 10us
Deepsleep - within 10ms
Note about mbed boards with interface, moved to lpc176x, as they are target related,
should be documented in the target documentation.
The tests will come as separate PR, to conform to this updates to sleep API.
Patch to LPC546XX SDK code - write the low Ethernet MAC address
register last, as that synchronises the update.
Without this change, the ENET_SetMacAddr call only seems to work prior
to MAC initialisation, causing problems for the new mbed OS EMAC system,
which expects it to be changable later.
Updated emac greentea tests #6851.
We cannot rely on the default value as a pin could
be use for Analog purposes in which this bit is cleared
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
The ci-shield tests that manually generate the START, STOP
by calling the HAL functions were failing. The byte operation
HAL functions cannot use the MCUXpresso SDK driver API's.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Since revision 5499db1 (mbed-os-5.6.0) a hardfault occurs after a power-cycle.
It doesn't occur after a reset when the application has been downloaded using
drag-and-drop or via debugger. This is probably the reason why this problem
isn't detected when testing new mbed releases.
The hardfault occured in hal_sleep(). Adding a __NOP after __WFI solves the
problem although I don't fully understand why.
- Revision ca661f9 is the last revision where the problem doesn't occur.
- The problem doesn't occur when compiling with GCC instead of ARM compiler
- This issue describes a similar, but not identical problem and led me to test adding a __NOP: https://github.com/ARMmbed/mbed-os/issues/5065
* Add source address word alignment check
* malloc and memcpy are called only if data is unaligned
* malloc size is now copySize (program page size), rather than whole buffer to be written
This patch fix flash write issue when program size is more than page size (= 1024 bytes). See detail - https://github.com/ARMmbed/mbed-os/issues/6165
Source data always use aligned data in heap memory.
Target of LPC1769 links to mbed LPC1768.
The PinNames.h has conditional compile for the pin names.
LWIP lpc17xx emac driver modified to allow LPC1769 target
From RM:
32.3.2.6 Interrupts during IAP
The on-chip flash memory is not accessible during erase/write operations. When the user
application code starts executing the interrupt vectors from the user flash area are active.
The user should either disable interrupts, or ensure that user interrupt vectors are active in
RAM and that the interrupt handlers reside in RAM, before making a flash erase/write IAP
call. The IAP code does not use or disable interrupts.
Since mbed-os 5.4.3, something increased foot print of mbed-os and the applications that were barely fitting in started to spill.
IAR toolchain for LPC176x target family is set to use 2 RAM regions (32K each). RAM region
2 is being used for ETH/USB and 1 is being used for vector table, stack/heap/static data.
In this commit we have decreased heap size allocation from 8K to 7K so that the is more room for stack and static data.
fire_interrupt function should be used for events in the past. As we have now
64bit timestamp, we can figure out what is in the past, and ask a target to invoke
an interrupt immediately. The previous attemps in the target HAL tickers were not ideal, as it can wrap around easily (16 or 32 bit counters). This new
functionality should solve this problem.
set_interrupt for tickers in HAL code should not handle anything but the next match interrupt. If it was in the past is handled by the upper layer.
It is possible that we are setting next event to the close future, so once it is set it is already in the past. Therefore we add a check after set interrupt to verify it is in future.
If it is not, we fire interrupt immediately. This results in
two events - first one immediate, correct one. The second one might be scheduled in far future (almost entire ticker range),
that should be discarded.
The specification for the fire_interrupts are:
- should set pending bit for the ticker interrupt (as soon as possible),
the event we are scheduling is already in the past, and we do not want to skip
any events
- no arguments are provided, neither return value, not needed
- ticker should be initialized prior calling this function (no need to check if it is already initialized)
All our targets provide this new functionality, removing old misleading if (timestamp is in the past) checks.
Restore cmsis_nvic (cmsis_nvic.c and cmsis_nvic.h) files for the
implementations which use a mechanism other than the VTOR to set
interrupts. These are vendor specific and were done for M0 devices
which do not have a VTOR.
Note - There were two cmsis_nvic files which did not use the VTOR that
which not restored in this patch. This is because these targets were
not M0 devices and could use the new unified implementation instead.
These files are:
targets\TARGET_ARM_SSG\TARGET_MPS2\TARGET_MPS2_M0P\device\cmsis_nvic.c
targets\TARGET_ONSEMI\TARGET_NCS36510\device\cmsis_nvic.c
Note - cmsis_nvic.c and cmsis_nvic.h were initial removed in
(and restored from) the commit:
b97ffe8fdc -
"CMSIS5: Replace target defined NVIC_Set/GetVector with CMSIS implementation"
The use of mktime was causing a fault when called in interrupt handler because on GCC it lock the mutex protecting the environment, To overcome this issue, this patch add dedicated routine to convert a time_t into a tm and vice versa.
In the process mktime has been optimized and is now an order of magnitude faster than the routines present in the C library.
For keep supporting external APIs with the same name (supposedly there are a larger
number of users of those APIs), BufferedSerial and ATParser are being renamed.
BufferedSerial becomes UARTSerial, will complement a future USBSerial etc.
ATParser becomes ATCmdParser.
* UARTSerial moves to /drivers
* APN_db.h is moved from platform to cellular/util/.
* Original CellularInterface is restored for backward compatability (again, supposedly there
are users of that).
* A new file, CellularBase is added which will now servce as the base class for all
upcoming drivers.
* Special restructuring for the driver has been undertaken. This makes a clear cut distinction
between an on-board or an off-board implementation.
- PPPCellularInterface is a generic network interface that works with a generic FileHandle
and PPP. A derived class is needed to pass that FileHandle.
- PPPCellularInterface provides some base functionality like network registration, AT setup,
PPP connection etc. Lower level job is delegated to the derived classes and various modem
specific APIs are provided which are supposed to be overridden.
- UARTCellularInterface is derived from PPPCellularInterface. It constructs a FileHandle and
passes it back to PPPCellularInterface as well as provides modem hangupf functionality.
In future we could proive a USBInterface that would derive from PPPCellularInterface and could
pass the FileHandle back.
- OnboardCellularInterface is derived from UARTCellularInterfae and provides hooks to
the target provided implementation of onbard_modem_api.h. An off-board modem, i.e, a modem on
a shield has to override the modem_init(), modem_power_up() etc as it cannot use
onboard_modem_api.h.
This provides a HAL layer for Modem bearing devices.
Provides a standard interface to upper layer drivers.
Platform providers will be implementing this API under their
specific targets.
As a reference, two implementations are provided under TARGET_C027 (UBLOX)
and TARGET_MTS_DRAGONFLY_F411RE (MultiTech).
targets.json now contains a tag "MODEM" which tells that this target
has a modem and the modem_api is protected by a flag DEVICE_MODEM
(following the DEVICE_SERIAL fashion ).
* Lays down ground for mbed modem_api
* Standardizes pin names relating to modem device for UBLOX C027 and MTS_DRAGONFLY_F411RE
devices
* Ublox modem api is changed to use a standard, platform independent name so that same
api could be used with multiple ubloc modems.
* DCD Polarity macro is added to assist the driver in knowing correct polarity
There is an easy default implementation of spi_master_block_write that
just calls spi_master_write in a loop, so the default implementation
of spi_master_block_write has been added to all targets.
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.
SystemInit() was called condititionally, but necessary defines were not
set in mbed. Calling SystemInit() unconditional now.
Removed also conditiional calls to legacy CodeRed lib.
Add sleep/deepsleep functions to platform layer which are replacing HAL
functions with the same name, rename existing symbols in HAL layer
to hal_sleep/hal_deepsleep. This way sleep functions
are always available, even if target doesn't implement them, which makes
the code using sleep clearer. It also enables us to make decision on in
which builds (debug/release) the sleep will be enabled.
Ari Parkkila
Mahesh Mahadevan
Przemyslaw Stekiel
Martin Kojtal
Anna Bridge
Alastair D'Silva
fluidblue
JojoS62
Derek Miller
Jimmy Brisson
Cruz Monrreal II
David Saada
Jarkko Paso
alrodlim
Deepika
thesupershan
Aleshandre Diaz
Yossi Levy
canhkha
Wilfried Chauveau
Bartek Szatkowski
Martin Kojtal
Kevin Bracey
Andreas Rebert
Joris Aerts
toyowata
Cruz Monrreal
gorazd
Serge Camille
Kevin Gilbert
Piotr Grygorczuk
Chris Snow
Russ Butler
Hasnain Virk
Rob Meades
Sam Grove
Vincent Coubard
Christopher Haster
adustm
Brian Daniels
0x6d61726b
Willie Walker
JojoS
Richard Lin
micromint
Peter Harliman Liem