- Linker script is based on LPC1768
number of NVIC is 16 (CORE) + 53 (M4 in LPC43xx) = 69,
therefor, reserve at the top of RAM0 (address:0x10000000)
to relocate NVIC vector table
- startup file is based on startup_ARMCM4.S in CMSIS V3.20
change NVIC name for cortex-M4 of LPC43xx
- add GCC_ARM for LPC4330_M4 in python scripts
- add some descriptions for GCC_ARM
If don't know if this is an issue that anyone cares about. I am also
not sure what the best way to solve it is either. I just thought I
would issue a pull request with this commit to bring the issue to light
and show a possible solution that I have tested on my mbed-1768 device.
Previously the serial_putc() API didn't make any use of the Tx FIFO
since the serial_writable() API it utilizes only returns true when the
FIFO is completely empty. This is due to the fact that the THRE bit of
the UART's LSR (Line Status Register) only goes high when the whole
FIFO is empty.
I noticed this when doing some performance testing with the network
stack. I went from calling printf() to output 3 bytes every 10 seconds
(with packet drop stats) to instead output 4 bytes every 10 seconds.
I thought these should easily fit in the 16 byte FIFO but outputting
one extra byte caused an additional three 550 byte UDP packets to be
dropped. This should only happen if the additional character being
sent to the UART was taking away extra CPU cycles from the network
stack.
My solution is to keep track of the number of bytes that have been
placed in the Tx FIFO since it was last detected as being completely
empty (via the THRE bit). Only once this count hits 16 does the code
then block, waiting for the THRE bit to go high. Each time the THRE
bit does go high, the count is reset to 0 again and it is incremented
for each byte that is loaded into the THR.
Because the LPC81X HAL implementation calls error(), which in turn calls
fprintf(), quite a bit of code is added to the image, which is not a good
idea on such resource constrained targets.
The new RawSerial class is a simple wrapper over the serial HAL that can
be safely used from an interrupt handler.
Interrupt chaining code was removed from InterruptIn, Serial and Ticker
because it caused lots of issues with the RTOS. Interrupt chaining is
still possible using the InterruptManager class.
Because CT32B1 (P1_1, P1_2 and P1_3) is used by us_ticker.c for wait and ticker function. Since wait/ticker is commonly used by mbed code and I decided CT32B1 of LPC11XX should only be used for this function, not for PwmOut.
P1_6 and P1_7 are used by UART (USBTX/USBRX) and I think they should not be assigned to other function.
DEVICE_STDIO_MESSAGES is the only #define in device.h that is being used in the library as #ifdef rather than #if. This is misleading since setting it to 0 will not disable including the <stdio.h> libraries.
A recent commit, 43acaa4166, to get _sbrk() to build successfully for
LPC2368 broke the Cortex-M implementation. __get_MSP() isn't ever
defined as a macro, it is an inline function. This means that the
code would always be compiled to use SP instead of MSP on Cortex-M
parts. I switched the code to instead use the TARGET_ARM7 define
to choose which stack pointer to utilize.
I tested this fix by making sure that the LPC2368 version of the mbed
SDK would still build successfully with the Python scripts and that the
NET1 test still built and ran successfully on my mbed-LPC1768 device.
Fault is triggered by trying to read LPC_CAN1->IER when the peripheral is powered off. Fixed by checking the power control register before checking the IER register.
While fixing this issue in the various LPC* ports, I noticed a comment
pointing to this mbed forum post which summarizes this bug quite well:
https://mbed.org/forum/bugs-suggestions/topic/4473/
This bug was introduced in the following commit:
2662e105c4
The following code was added to serial_putc() as part of this commit:
uint32_t lsr = obj->uart->LSR;
lsr = lsr;
uint32_t thr = obj->uart->THR;
thr = thr;
As the forum post indicates, this causes the serial_putc() routine to
actually eat an inbound received byte if it exists since reading THR is
really reading the RBR, the Receiver Buffer Register. This code looks
like code that was probably added so that the developer could take a
snapshot of these registers and look at them in the debugger. It
probably got committed in error.
LPC11U24/LPC11U24_301/LPC11U35_401 shared the same startup file for ARM
and uARM toolchains, which is wrong, because the initial SP value is
different for LPC11U24_301. This commit fixes this issue by giving each
target its own startup file.
There were lots of overlaps in the code for LPC810 and LPC812, including
duplicated source files. This commit adds a TARGET_LPC81X_COMMON folder in
both HAL and CMSIS, this folder keeps common code for the targets.
If the FileBase::lookup operation in the constructor of FilePath returns
NULL, subsequent operations (such as isFile()/isFileSystem()) will call
methods on a NULL 'fb' pointer. This commit fixes this issue by adding
explicit NULL checks and a new method in FilePath (exists()).
1. Added: GCC_CR toolchain ID for LPC2368. (targets.py)
2. Modified: Startup codes for GCC_ARM and GCC_CR toolchain.
3. Verified: "ticker" and "basic" test program work well, so far.
(Fixed typo.)
1. Added: GCC_CR toolchain ID for LPC2368. (targets.py)
2. Modified: Startup codes for GCC_ARM and GCC_CR toolchain.
3. Verified: "ticker" and "basic" test program works well, so far.
I verified that the hang issue I was seeing when building and running
the mbed official networking tests with GCC_ARM was related to this
issue reported on the mbed forums:
http://mbed.org/forum/mbed/topic/3803/?page=1#comment-18934
If you are using the 4.7 2013q1 update of GCC_ARM or newer then it
will have a _sbrk() implementation which checks the new top of heap
pointer against the current thread SP, stack pointer.
See this GCC_ARM related thread for more information:
https://answers.launchpad.net/gcc-arm-embedded/+question/218972
When using RTX RTOS threads, the thread's stack pointer can easily
point to an address which is below the current top of heap so this
check will incorrectly fail the allocation.
I have added a _sbrk() implementation to the mbed SDK which checks the
heap pointer against the MSP instead of the current thread SP. I have
only enabled this for TOOLCHAIN_GCC_ARM as this is the only GCC based
toolchain that I am sure requires this.
A new hooks mechanism (hooks.py) allows various targets to customize
part(s) of the build process. This was implemented to allow generation of
custom binary images for the EA LPC4088 target, but it should be generic
enough to allow other such customizations in the future. For now, only the
'binary' step is hooked in toolchains/arm.py.
mazgch
Emilio Monti
Sissors
hototogi
0xc0170
bcostm
Bogdan Marinescu
Joris Aerts
Andreas Rebert
pbrier
Bogdan Marinescu
Adam Green
Joe Turner
Bogdan Marinescu
Michael Conners
Toyomasa Watarai
dinau
Erik Olieman
unknown
Toyomasa Watarai
ytsuboi