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.
Mahesh Mahadevan
Martin Kojtal
Cruz Monrreal
Andreas Rebert
Joris Aerts
toyowata
Cruz Monrreal
Martin Kojtal
gorazd
Serge Camille
Przemyslaw Stekiel
Jimmy Brisson
Kevin Gilbert
Anna Bridge
Piotr Grygorczuk
Chris Snow
Russ Butler
Hasnain Virk
Deepika
Rob Meades
Sam Grove
Vincent Coubard
Bartek Szatkowski
Christopher Haster
adustm
Brian Daniels
0x6d61726b
Willie Walker
JojoS
Richard Lin
micromint
Peter Harliman Liem