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.
1. added the possibility to redirect stderr to stdout in utils.run_cmd
2. synch.py now calls the above run_cmd in redirect mode instead of the
old 'cmd' that doesn't intercept standard streams. This makes it easier
for an external tool to intercept the output of 'hg'.
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.
The dependency file generated by GCC might contain more than one
dependency listed on a single line, which wasn't taken into account by the
GCC dependency fille interpreter. This commit fixes this issue.
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()).
Asm versions of netstack memcpy() and lwip_standard_chksum()
[Note] I'm generally a bit reluctant when including optimizations like this (from an architectural standpoint), because they tend to be a bit too specific (for example, this one works only with lwIP+GCC+Cortex-M3 or M4), but for now it looks as this is the right place for them, although the optimized memcpy should ideally be in libc (or even better replaced with a DMA transfer in this particular case). But this will be both a nice optimization and a reminder of what we need to implement/change in the future.
Based on great feedback from Martin Kojtal on my previous commit, I
have modified my USBHost::fileControlBuf() change to be more portable.
ddb3fbe826 (commitcomment-3988044)
The code now fills in the setupPacket byte array a byte at a time,
using bit shifts to extract lower and upper bytes from the 16-bit
values so that the code should work on big endian or little endian
machines. I also removed the 2-byte alignment attribute from the
setupPacket array as it is no longer required.
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.)