armmbed / mbed-os Goto Github PK

I would like to add the option to make.py to get sources from arbitrary locations and put the build output to any other location, for ad-hock compilation (of things not in the tests.py). Any comments or suggestions to that?

When using the RTOS and usbdevice (in my case usbmidi) together the mbed just halts at the place where I initiate the usbmidi object.

Just using the 2 example programs from rtos and usbmidi together.

I was not able to figure out how to set the neserver IP address(es), seems like this is currently not exposed.

When using smaller microcontrollers, like the LPC11U23, some USB functions take up a considerable amount of memory, and do fit or leave too little memory for useful work (depending on compiler and std. libraries used; KEIL performing better than GCC). One solution is not to include the Stream class, and remove this from the USB classes. Now it does fit (of course you loose the standard Stream functionality on the interface):

For example: modify line 92 of USBKeyboard.h from:

class USBKeyboard: public USBHID, public Stream {

to

class USBKeyboard: public USBHID {

Note: A similar issue is occurs with the Serial() class, you can remove the Stream or access the C-api directly to conserve memory.

Question: Can a build option be provided for compilation without Stream classes?
(e.g. NOCPPSTREAM?)

There are few issues, I made a diff with KL25Z (entire hal is almost copy one-to-one). I created a branch from master. I'll update you with the status.

I'll run all available tests and I'll probably add KEIL support as well.

Regards,
0xc0170

Since USBDevice was updated for the latest batch of microcontrollers, it has been generating the following warning while compiling for an LPC11UXX:
Warning: C4017W: __regarg_2 may be used before being set in "AlphaPlatform/Libraries/USBDevice/USBMIDI/USBMIDI.cpp", Line: 45, Col: 11

Reference : http://mbed.org/users/mbed_official/code/mbed/issues/12

the exporters are enabled, thus it is available also in online compiler. But targets script does not contain IAR as toolchain supported.

@bcostm
Did you test IAR toolchain for this target?

Regards,
0xc0170

While I was working today on gpio irq enable/disable, git issued warning about line endings.

For example file TARGET_LPC176X in HAL has different line endings.

We should consolidate all files, I assume UNIX line endings are default for mbed repositories.

The blog states that the mbed SDK is Apache licensed and the CMSIS components are BSD licensed (https://mbed.org/blog/entry/mbed-SDK-is-now-Open-Source/ , https://mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/ ).

However, some of the files in this repository (mostly, but not only, in libraries/mbed/targets/cmsis/TARGET_*) carry a copyright notice and either "All rights reserved" or a proprietary license. Are these items not considered part of "the mbed SDK" (http://mbed.org/users/mbed_official/code/mbed/ is currently giving "Page error" so I can't check there), or is this a mistake?

palmer@lap14:~$ licensecheck -r /fs_dev/git/mbed | grep -e UNKNOWN | grep -v -e"No copyright" # licensecheck is available from http://sources.debian.net/src/devscripts/2.14.5/scripts/licensecheck.pl
/home/palmer/fs_dev/git/mbed/libraries/USBDevice/USBDevice/USBRegs_STM32.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/fs/fat/ChaN/ff.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/fs/fat/ChaN/ff.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F072RB/stm32f0xx_hal_irda.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F072RB/stm32f0xx_hal_pcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F072RB/stm32f0xx_hal_spi.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F072RB/stm32f0xx_hal_cec.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F072RB/stm32f0xx_hal_usart.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F334R8/system_stm32f3xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F334R8/stm32f3xx_hal_usart.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F334R8/stm32f3xx_hal_wwdg.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F334R8/stm32f3xx_hal_crc_ex.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F334R8/stm32f3xx_hal_cec.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F334R8/stm32f3xx_hal_pcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F334R8/stm32f3xx_hal_irda.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_hal_hcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_ll_fmc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_hal_pcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_hal_pccard.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_ll_fsmc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_hal_spi.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_hal_nand.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_hal_flash_ex.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F407VG/stm32f4xx_hal_nor.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F103RB/system_stm32f10x.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F4XX/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F4XX/system_stm32f4xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F4XX/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F4XX/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F4XX/stm32f4xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F4XX/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F302R8/stm32f30x_gpio.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F302R8/stm32f30x_flash.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F302R8/stm32f30x_adc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F302R8/stm32f30x_can.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F302R8/stm32f30x_dma.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_hal_hcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_ll_fmc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_hal_pcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_hal_pccard.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_ll_fsmc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_hal_spi.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_hal_nand.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_hal_flash_ex.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/stm32f4xx_hal_nor.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L053R8/stm32l0xx_hal_crc_ex.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L053R8/stm32l0xx_hal_pcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L053R8/stm32l0xx_hal_usart.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L053R8/stm32l0xx_hal_tim_ex.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_hal_hcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_ll_fmc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_hal_pcd.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_hal_pccard.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_ll_fsmc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_hal_nand.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_hal_flash_ex.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F411RE/stm32f4xx_hal_nor.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_i2c.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_comp.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_syscfg.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_dma.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_opamp.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_aes.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_gpio.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_L152RE/stm32l1xx_exti.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F303VC/stm32f30x_gpio.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F303VC/stm32f30x_flash.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F303VC/stm32f30x_adc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F303VC/stm32f30x_can.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F303VC/stm32f30x_dma.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F3XX/stm32f30x_gpio.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F3XX/stm32f30x_flash.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F3XX/stm32f30x_adc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F3XX/stm32f30x_can.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F3XX/stm32f30x_dma.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F030R8/stm32f0xx_can.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F030R8/stm32f0xx_gpio.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F030R8/stm32f0xx_exti.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F030R8/stm32f0xx_flash.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F030R8/stm32f0xx_dma.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F030R8/stm32f0xx_adc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F051R8/stm32f0xx_can.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F051R8/stm32f0xx_gpio.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F051R8/stm32f0xx_exti.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F051R8/stm32f0xx_flash.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F051R8/stm32f0xx_dma.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_DISCO_F051R8/stm32f0xx_adc.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/TOOLCHAIN_GCC_CR/TARGET_LPC11U68/mtb.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/system_LPC11U6x.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/system_LPC11U6x.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11U6X/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC81X/system_LPC8xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC81X/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC81X/TARGET_LPC812/system_LPC8xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC81X/TARGET_LPC810/system_LPC8xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC81X/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC81X/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC81X/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/system_LPC11Uxx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/system_LPC11Uxx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/LPC17xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/system_LPC17xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/system_LPC17xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC176X/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/TOOLCHAIN_GCC_CR/startup_LPC43xx.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/system_LPC43xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/system_LPC43xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/LPC43xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC43XX/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/TARGET_LPC11XX/system_LPC11xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/system_LPC11xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/TARGET_LPC11CXX/system_LPC11xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11XX_11CXX/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC13XX/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC13XX/system_LPC13Uxx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC13XX/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC13XX/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC13XX/system_LPC13Uxx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC13XX/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC13XX/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/TOOLCHAIN_GCC_CR/startup_lpc407x_8x.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/system_LPC407x_8x_177x_8x.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/TOOLCHAIN_ARM_STD/sys_helper.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/LPC407x_8x_177x_8x.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/system_LPC407x_8x_177x_8x.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC408X/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/system_LPC23xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/core_arm7.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/vector_defns.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/core_arm7.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/vector_realmonitor.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/system_LPC23xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/LPC23xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC23XX/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC15XX/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC15XX/system_LPC15xx.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC15XX/system_LPC15xx.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC15XX/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC15XX/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC15XX/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/system_MKL46Z4.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/system_MKL46Z4.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/MKL46Z4.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/system_MKL05Z4.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/system_MKL05Z4.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/MKL05Z4.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/system_MKL25Z4.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/system_MKL25Z4.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/MKL25Z4.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/TOOLCHAIN_ARM_MICRO/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K20D5M/MK20D5.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K20D5M/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K20D5M/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K20D5M/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K20D5M/system_MK20D5.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K20D5M/system_MK20D5.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K20D5M/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K64F/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K64F/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K64F/system_MK64F12.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K64F/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K64F/MK64F12.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K64F/system_MK64F12.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_K64F/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_NRF51822/cmsis.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_NRF51822/TOOLCHAIN_ARM_STD/sys.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_NRF51822/nrf51.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_NRF51822/nrf51_bitfields.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_NRF51822/compiler_abstraction.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_NRF51822/cmsis_nvic.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_NRF51822/cmsis_nvic.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_Freescale/TARGET_KPSDK_MCUS/TARGET_K64F/device/MK64F12/system_MK64F12.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_Freescale/TARGET_KPSDK_MCUS/TARGET_K64F/device/MK64F12/MK64F12.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_ranges.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_gap.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/nrf_soc.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_hci.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/nrf_error_sdm.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_l2cap.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_gatt.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_types.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_gatts.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/nrf_sdm.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/softdevice_assert.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/nrf_error.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_err.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble_gattc.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/ble.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_NRF51822/Lib/s110_nrf51822_6_0_0/s110_nrf51822_6.0.0_API/include/nrf_error_soc.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/rtos/rtx/cmsis_os.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/lwip/lwip/netif/ppp/vj.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/lwip/lwip/netif/ppp/md5.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/lwip/lwip/netif/ppp/md5.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/lwip/lwip/netif/ppp/vj.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/eth/lwip-eth/arch/TARGET_NXP/lpc_phy.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/eth/lwip-eth/arch/TARGET_NXP/lpc_emac_config.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/eth/lwip-eth/arch/TARGET_NXP/lpc17xx_emac.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/eth/lwip-eth/arch/TARGET_NXP/lpc_phy_dp83848.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/net/eth/lwip-eth/arch/TARGET_NXP/lpc17_emac.c: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/mbed/interrupt_chaining/main.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/mbed/freopen/TextDisplay.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/mbed/freopen/TextLCD.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/mbed/freopen/TextDisplay.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/mbed/freopen/TextLCD.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/mbed/spifi1/spifi_rom_api.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/mbed/spifi2/spifi_rom_api.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/libs/SerialHalfDuplex/SerialHalfDuplex.h: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/libs/SerialHalfDuplex/SerialHalfDuplex.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/libs/SPIHalfDuplex/SPIHalfDuplex.cpp: UNKNOWN
/home/palmer/fs_dev/git/mbed/libraries/tests/libs/SPIHalfDuplex/SPIHalfDuplex.h: UNKNOWN
palmer@lap14:$

Hi, all

I've been successful to use the newlib-nano libraries with LPCXpresso compiler (GCC_CR).
This is highly experimental,
but some simple example programs ("ticker" and "basic") work well at this moment.

1. First, needed for the newlib-nano libraries included in
   Launchpad GCC
   https://launchpad.net/gcc-arm-embedded
   I'm using Ver.4.7-2013q2.
2. Copy the newlib-nano libraries to the library folder of LPCXpresso.
   Assume that Launchpad GCC root folder name is "launchpad-gcc-root" and
   LPCXpresso root folder name is "lpxpresso-root".

(1) nano.specs file
[copy] launchpad-gcc-root/arm-none-eabi/armv7-m/nano.specs
[to] lpcxpresso-root/lpcxpresso/tools/arm-none-eabi/lib/

(2) Each libraries
i.e. for Cortex-M3 micros
[copy] launchpad-gcc-root/arm-none-eabi/lib/armv7-m/*_s.a
[to] lpcxpresso-root/lpcxpresso/tools/arm-none-eabi/lib/armv7-m/

i.e. for Cortex-M0 micros
[copy] launchpad-gcc-root/arm-none-eabi/lib/armv6-m/*_s.a
[to] lpcxpresso-root/lpcxpresso/tools/arm-none-eabi/lib/armv6-m/

Adding "--specs=nano.specs" option to the linker script option.

[workspace_tools/toolchains/gcc.py]:

    class GCC_CR(GCC):
        def __init__(self, target, options=None, notify=None):
            GCC.__init__(self, target, options, notify, GCC_CR_PATH)

            additional_compiler_flags = [
                "-D__NEWLIB__", "-D__CODE_RED", "-D__USE_CMSIS", "-DCPP_USE_HEAP",
            ]
            self.cc += additional_compiler_flags
            self.cppc += additional_compiler_flags
            if "nanolib" in self.options:
                # Use latest gcc nanolib
                self.ld.append("--specs=nano.specs")
                if target.name in ["LPC1768"]:
                    self.ld.extend(["-u", "_printf_float", "-u", "_scanf_float"])
            self.ld += ["-nostdlib"]

Building "basic" test program with newlib-nano libraries

    $ workspace_tools/build.py -m LPC1768 -t GCC_CR
    $ workspace_tools/make.py  -m LPC1768 -t GCC_CR -d. -p 0 -o nanolib

dinau

Hello,

I have used mbed on and off for several years without having any issues with the serial port. Recently I started using a IC that has a UART output (Silabs si8900).When powered has an auto baud function that happens were you send a single byte until it can match the baud and send a single byte response . I have no trouble receiving and reading the single character during auto baud, only when I try to read the 3 byte response during normal use does it appear to not read the 2nd and 3rd byte.

Below is an image showing what is going on.

The top section of code shows my read statement which picks bytes from the buffer while readable() returns 1. The 3 byte response comes after I send a request byte, which is not shown.

The middle section shows the values during debugging which shows I read the first byte but shows no values stored in the other bytes due to readable() returning 0.

The third section is the logic analyzer output showing the 3 byte response.

The only thing I can think of is there is no delay between bytes and the serial port might see it as a single byte with framing issues. I do not know enough about the serial port library to know what could be causing this issue. It would be helpful if somebody could take a look at this and see if they can find anything.

As a side note, I programmed simple software serial functions but due to how quickly the response is from the IC the timing does not work out well.

Any help would be appreciated.

File I/O performance is currently very poor when using FATFileSystem on the μARM toolchain. This is made evident by the attached SD card benchmarks. More details are available here.

I found out yesterday that Cortex M4 core enables FPU by default.

An example for ARM toolchain

        if   target.core == "Cortex-M0+":
            cpu = "Cortex-M0"
        elif target.core == "Cortex-M4":
            cpu = "Cortex-M4.fp"
        else:
            cpu = target.core

I propose to create two cores Cortex-M4 and Cortex-M4F.
All current targets for M4 will become M4F, and the new one coming K20D5 will be just M4. I'll create a branch for this with a fix.

Regards,
0xc0170

Compilation of the network library (e.g. for LPC1768) is not possible with the GCC_ARM compiler, due to code incompatibilities (required gnu++11) and missing ETH ram segment in linker script

When I compile projects for the EA LPC11U35 QuickStart Board using the online compiler, the Build tab reports the RAM usage to be out of 10KB. This is incorrect, the LPC11U35/401 only has 8KB of main SRAM just like the LPC11U24/401.

I was trying to sync code between the LPC11XX and LPC11CXX and I noticed the following pull request: 1d1c8c6

Why are the pins disabled? If a user wants to use the SWD interface I guess he should just not configure those pins.

Issue #14 was not solved.
Here is procedure.

1. workspace_tools\build.py --clean -r -m xxxx -t ARM
2. workspace_tools\build.py --clean -r -m xxxx -t uARM
3. make.py -m xxxx -t uARM -p 32
4. make.py -m xxxx -t ARM -p 32

So, you will get error message like this.

Build Options: debug-info

>>> BUILD PROJECT: BASIC (xxxx, ARM)
Link: basic
[ERROR] Error: L6267E: Input objects request both standardlib and microlib. Please choose using the --library_type option.
Finished: 0 information, 0 warning and 1 error messages.

When i execute the script workspace_tools/make.py to execute a test on my lpcxpresso1549 board, an exception is raised on line https://github.com/mbedmicro/mbed/blob/master/workspace_tools/make.py#L189 in serial.sendBreak().

Linux: Fedora 20 kernel 3.14.7-200.fc20.x86_64
Python: 2.7.5

When i replace the line serial.sendBreak() with the following code, it works fine:

           try:
                serial.sendBreak()
            except:
                # In linux a termios.error is raised in sendBreak and in setBreak.
                # The following setBreak() is needed to release the reset signal on the target mcu.
                try:
                    serial.setBreak(False)
                except:
                    pass

I'd like to run the I2C bus on the LPC11U35 and LPC11U68 at 1MHz (Fast-mode Plus), but the current implementation of i2c_api.c does not configure the I2C mode on PIO0_4 and PIO0_5. In fact, pinmap.c doesn't provide a way to specify the I2C mode at all. According to both datasheets, the mode needs to be set using bits 8 and 9 in the PIO0_4 and PIO0_5 IOCON registers.

ARM and uARM shares same directory to store temporary object files for target specific APIs. Therefore, we have to clean binaries (trash "build" folder manually) before change to another target touching.

We want "trash build folder" option for build.py

The mbed-rtos library does not use or honour SystemCoreClock and is not responsive to changes in SystemCoreClock at run time. To change the core frequency, you must first change the registers and call SystemCoreClockUpdate() mechanism, but then you must update #define OS_CLOCK in mbed-rtos/rtx/RTX_Conf_CM.c. Obviously the later can't be done by code at run time, and this makes run-time clock changes impossible. This furthermore makes the RTOS almost impossible to use in a energy-constrained application. I realise fixing this properly is non-trivial, but I would urge you to find a good solution rather than a quick one.

There is a problem building the SD Card test using:

python workspace_tools\make.py -t ARM -m LPC1768 -n MBED_A12

When I compile this in ARM, it throws up lots of errors,

[ERROR] Error: L6218E: Undefined symbol gpio_init (referred from test_env.o).
Error: L6218E: Undefined symbol wait (referred from test_env.o).
Error: L6218E: Undefined symbol mbed::SPI::write(int) (referred from SDFileSyste
m.o).
Error: L6218E: Undefined symbol mbed::SPI::frequency(int) (referred from SDFileS
ystem.o).
Error: L6218E: Undefined symbol mbed::SPI::SPI(PinName, PinName, PinName) (refer
red from SDFileSystem.o).
Error: L6218E: Undefined symbol wait_ms (referred from SDFileSystem.o).
Error: L6218E: Undefined symbol typeinfo for mbed::FileSystemLike (referred from
 FATFileSystem.o).
Error: L6218E: Undefined symbol mbed::FileHandle::~FileHandle__sub_object() (ref
erred from FATFileHandle.o).
Error: L6218E: Undefined symbol typeinfo for mbed::FileHandle (referred from FAT
FileHandle.o).
Error: L6218E: Undefined symbol vtable for mbed::FileHandle (referred from FATFi
leHandle.o).
Error: L6218E: Undefined symbol mbed::FileSystemLike::FileSystemLike__sub_object
(const char*) (referred from FATFileSystem.o).
Error: L6218E: Undefined symbol mbed::FileSystemLike::~FileSystemLike__sub_objec
t() (referred from FATFileSystem.o).

On the other hand, when I use GCC_ARM, there are no errors when building for the LPC1768

I tested the RTOS Timer example in the online compiler and it works fine. I exported to LPCexpresso and when I have -O2 optimization enabled for C compiler the callback function isn't executed (leds don't blink)

Tested with LPC4088.

Creating a PwmOut object using P0_8, and setting the period to 2µs (500kHz) produces an incorrect waveform running at ~33kHz. This code worked on a previous version of the mbed library, leading me to believe it was broken 4 months ago as part of a3465b5.

I'm getting a "missing device.h" error on all my online builds for the nRF51822 target. I believe I've traced it back to this commit:

582eb65

That moves some device.h files for the nordic targets. I'm not setup to do an offline build, so I don't know if that's broken.

I seem to have uncovered a serious memory problem with fopen() while trying to use SDFileSystem with mbed-rtos. On an LPC11U24, it's requiring a thread stack size of at least 1600B, 3.125x the default stack size, and it's hanging the system after a certain number of calls. More details here: http://mbed.org/forum/bugs-suggestions/topic/5073/

Currently the GCC_ARM compiler is not supplorted for the target NXP LPC1549.
#434 adds support for GCC_ARM for the target NXP LPC1549.

As I was code reviewing the serial_api.c source code for the LPC176X port, I noticed the following code in serial_clear():

void serial_clear(serial_t *obj) {
    obj->uart->FCR = 1 << 1  // rx FIFO reset
                   | 1 << 2  // tx FIFO reset
                   | 0 << 6; // interrupt depth
}

I never see this API being called from any code in the mbed SDK but if it was called, wouldn't it end up disabling the FIFO as it does not keep bit 0, the FIFO enable bit, set high?

The app timer based on RTC is used by
https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/us_ticker.c
and
http://mbed.org/teams/Nordic-Semiconductor/code/nRF51822/file/9689ec201907/btle/btle.cpp

And mbed-src libraries includes app_timer.c, nRF51822 library includes app_timer.cpp. The two are also the same and will cause multiple symbols compile error.

The Environment

• Mbed LPC1768 on an Embedded Artists base board.
• LPCXpresso v5.2.4 [Build 2122].
• Using CAN2, LEDs and serial I/O interfaces.

The Problem

Hardfault interrupt on LPC1768 when attaching a callback function to a CAN object and only one CAN object is defined.

How to Reproduce

Run the following app on an mbed LPC1768 . Note the blue LEDs of death as HardFault_Handler() is called.

#include "mbed.h"

BusOut myleds(LED1, LED2, LED3, LED4);
CAN can2(p30, p29);
bool got_message = false;

extern "C" void HardFault_Handler ()
{
    error("Hit HardFault handler!\r\n");
}

void can_callback()
{
    got_message = true;
}

int main()
{
    CANMessage msg;

    printf("main()\n");
    can2.attach(can_callback, CAN::RxIrq);
    int i = 0;
    while(1) {
        printf("loop()\n");
        if (got_message)
        {
            got_message = false;
            can2.read(msg);
            printf("Message received: %d\n", msg.data[0]);
        }
        wait(0.2);
        myleds = i++;
        i %= 16;
    }
}

The Workaround

Create a second unused CAN object

CAN can1(p9, p10);

and run the app again. The app now works OK.

The Cause

Checking IER on both CAN peripheral modules when only one of them is enabled causes a hard fault.

The error is in function can_irq_set(), at line 167 of file …/mbed/targets/hal/TARGET_NXP/TARGET_LPC176x/can_api.c.

I'm not sure whether this goes against the intentions of workspace_tools, but I think it would be useful if workspace_tools could be used to build generic mbed based projects, as well as the tests which are already available. This could be using a json file or some other kind of configuration file inside a directory representing a project, which defines things like toolchain, target etc. Then, all the user would have to do would be to call python -m workspace_tools.build_project or something similar to that, which would then build the project.
I would be happy to implement this myself and submit a pull request, since I think it would be useful for a project of mine, however I wanted to check with @PrzemekWirkus in particular that this functionality does not yet exist.

In rt_CMSIS.c in svcThreadCreate(...) , rt_init_context(...) is called before a proper value is given to task_context->task_id (which is done one line after).

But rt_init_context(...) in rt_Task.c calls rt_init_stack(...) in HAL_CM.c with the following last two lines:
if (p_TCB->task_id != 0x01)
p_TCB->stack[0] = MAGIC_WORD;

That could cause a mismatch in some cases in rt_stk_check (...) in rt_System.c because
os_tsk.run->stack[0] != MAGIC_WORD

I'm currently doing offline development with the mbed SDK, and noticed it fails to build under certain condition with a following error:

# python build.py -t GCC_ARM -m LPC1114 -o debug-info -r
...
Building library RTX (LPC1114, GCC_ARM)
Compile: rt_CMSIS.c
[Error] rt_CMSIS.c@588: In function 'osKernelInitialize': r7 cannot be used in asm here
c:\src\mbed\libraries\rtos\rtx\rt_CMSIS.c: In function 'osKernelInitialize':
c:\src\mbed\libraries\rtos\rtx\rt_CMSIS.c:588:1: error: r7 cannot be used in asm here
 }
 ^

Culpit is the following code in rt_CMSIS.c:

#if (defined (__CORTEX_M0)) || defined (__CORTEX_M0PLUS)
#define SVC_Call(f)                                                            \
  __asm volatile                                                                 \
  (                                                                            \
    "ldr r7,="#f"\n\t"                                                         \
    "mov r12,r7\n\t"                                                           \
    "svc 0"                                                                    \
    :               "=r" (__r0), "=r" (__r1), "=r" (__r2), "=r" (__r3)         \
    :                "r" (__r0),  "r" (__r1),  "r" (__r2),  "r" (__r3)         \
    : "r7", "r12", "lr", "cc"                                                  \
  );
#else
...

Cortex-M0 LDR has a limitation that it cannot directly load value into upper register (r12), and that's why r7 is being used as a temporary register. However, that breaks GCC on debug build since GCC is also using r7 as frame pointer.

I posted a patch as well as a pull request here -> #472

The non-blocking read method in the USBHID class randomly returns zero byte reports when a report is sent using SimpleHIDWrite. This is made evident by using a simple program that echos every received report back to the host PC.


The exact same program runs on the LPC1768 without issue. A discussion regarding this issue can be found at: http://mbed.org/forum/bugs-suggestions/topic/4806/

Because of a blocking connect function in USBDevice ( https://github.com/mbedmicro/mbed/blob/master/libraries/USBDevice/USBDevice/USBDevice.cpp#L711 ) called from the USBCDC constructor ( https://github.com/mbedmicro/mbed/blob/master/libraries/USBDevice/USBSerial/USBCDC.cpp#L34 ), instatiating USB Serial with nothing connected on the actual port blocks execution.

I tried just commenting the while loop out and everything seems to run fine (connect/disconnect and CDC/serial communication with a host computer.

Maybe this should be solved in a different way - but especially when running on battery on KL25Z, this is a problem (the blocking).

Hi,
I would like to report the problem I had during the building:
Traceback (most recent call last):
File "workspace_tools/build.py", line 14, in
from workspace_tools.targets import TARGET_NAMES, TARGET_MAP
File "/home/mario/mbed/mbed/workspace_tools/targets.py", line 176, in
LPC4330(),
NameError: name 'LPC4330' is not defined

After commenting line 176 in target.py, the building works.

Thanks

bye

I noticed that the HAL_CM4.s and SVC_Table.s files were not recognized by KDS until I converted their suffix to a capital S - HAL_CM4.S and SVC_Tables.S.

Hello,

I've ported mbed-sdk to STM32VL-Discovery board.
This port is basically derived from NUCLEO_F103RB port
and ported only with GCC_ARM toolchain at the momemt.

The target name is 'DISCO_F100RB'.

The statement at this moment is as follows,
I've checked working well,
(1) Simple 'ticker' program 'MBED_11: Ticker' is ok.
(2) RTX OS sample 'RTOS_1: Basic' is ok.
(3) printf() function outputs to UART port is ok.
PA2: UART TX
PA3: UART RX
(4) MBED_5: PWM
PWM port is PB3 and PB4.
Period 20msec, duty 75% and 50% are ok.

NUCLEO_F103RB(STM32F103RB) and STM32VL-Discovery(STM32F100RB) have
very similar peripheral architecture,
so probably some other peripheral test will be pass.

Build method:
(1) Build mbed library with RTX OS
python workspace_tools/build.py -m DISCO_F100RB -t GCC_ARM -r
(2) Generate test project (i.e.)
python workspace_tools/project.py -m DISCO_F100RB -i gcc_arm -p 39
(3) Build test project
Unzip
build/export/MBED_11_gcc_arm_DISCO_F100RB.zip
and execute command line 'make'.

May I send pull request of this implimentation ?

dinau

We are in a situation, where we would like to bring down the USBSerial device and bring it up again with a different VID/PID. However, it seems that just calling disconnect and delete on the USBSerial object (followed by a new object construction) is not enough. We have even tried with a 2 sec delay between all calls.

example:

USBSerial* serial = new USBSerial(OLDVID, OLDPID, 0x0001, false);
...
serial->disconnect();
delete serial;
serial = new USBSerial(NEWVID, NEWPID, 0x0001, false);

The result in dmesg is:

[83207.507577] usb 1-1.2: new full-speed USB device number 52 using ehci-pci
[83207.601690] usb 1-1.2: New USB device found, idVendor=xxOLDVIDxx, idProduct=xxOLDPIDxx
[83207.601701] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[83207.601707] usb 1-1.2: Product: CDC DEVICE
[83207.601711] usb 1-1.2: Manufacturer: mbed.org
[83207.601716] usb 1-1.2: SerialNumber: 0123456789
[83207.602476] cdc_acm 1-1.2:1.0: ttyACM3: USB ACM device
[83208.076002] usb 1-1.2: USB disconnect, device number 52
[83212.109597] usb 1-1.2: new full-speed USB device number 53 using ehci-pci
[83212.181370] usb 1-1.2: device descriptor read/64, error -32
[83212.357118] usb 1-1.2: device descriptor read/64, error -32
[83212.533016] usb 1-1.2: new full-speed USB device number 54 using ehci-pci
[83212.604863] usb 1-1.2: device descriptor read/64, error -32
[83212.780560] usb 1-1.2: device descriptor read/64, error -32
[83212.956277] usb 1-1.2: new full-speed USB device number 55 using ehci-pci
[83213.363562] usb 1-1.2: device not accepting address 55, error -32
[83213.435790] usb 1-1.2: new full-speed USB device number 56 using ehci-pci
[83213.842899] usb 1-1.2: device not accepting address 56, error -32
[83213.843300] hub 1-1:1.0: unable to enumerate USB device on port 2

Hello,

since i cannot post to the google group, i raise this here. It is not really a bug.
I think the exporters (at least for gcc arm) can be improved by using template inheritance from jinja2: http://jinja.pocoo.org/docs/templates/#template-inheritance

I did a very rough sample implementation for four exporters:
https://github.com/chrta/mbed/compare/exporter_template_refactoring

What do you think?

Would it be a suggestion to implement a "formal" code commit and review process?
e.g. something like this:
https://github.com/energia/Energia/wiki/Bug-fix-and-new-feature-review-process

We could use topic branches, or at least have some staging in the process from feature/bugfix to master branch (e.g. using a "development" branch)

The github wiki pages could be used to document the process (along with coding styles and other considerations)

See: https://mbed.org/questions/2599/Is-USBSerial-giving-problems-on-new-Hasw/

To save people some time: The main flashing port on an untouched KL25Z (from factory) works fine on these macs (comes up with the additional tty USB port in /dev/tty.usbmodem....).

In the issue mentioned on mbed.org, I've included the CDC (and rest of USB) profiles as shown in linux for the two ports. As you can see there seem to be some things missing from what the mbed CDC should have been reporting (e.g. power consumption defaults to 100mA and some other params are not the same). It could be that the new apple devices are more strict in SW or HW and that we need to get the parameters fixed on the mbed side to match.

I've modified targets.py so that I can compile the mbed libraries with ARM GCC for my LPC11U24 microcontroller. There was a problem in the LPC11U24.ld linker script, which caused interesting problems. I have the LPC11U24FBD48/301 microcontroller. Note the "/301" and see the datasheet (UM10462, Rev. 4.1 — 19 July 2013, page 15). It has 6 kB SRAM, starting at 0x1000 0000. The datasheet says the /401 version has 8 kB SRAM, starting at 0x1000 1800. Maybe would be good if I could specify this for the "-m" parameter for the make.py and build.py scripts.
The new line in LPC11U24.ld, which seems to work (at least no funny 0-bytes anymore when trying a printf("%i", 123)) :
RAM (rwx) : ORIGIN = 0x100000C0, LENGTH = 0x1740

I designed and built a custom board using the LPC1549. When writing test code our team found that only AN0 channels would work as expected while the AN1 channels would not give valid values. I have not looked closely at the API but I am assuming something in AN1 is not implemented correctly.

Thanks

Hi,

Translated this bug report from:
https://mbed.org/questions/3281/Nucleo-F401REPD_8/

Morpho headers of the Nucleo-F401RE shows PD_8, but there is no definition in PinNames.h, so he gots compile error.

Can you add the PD_8 pin in this target?

Thanks in advance.

I happened to run into the source code of the Nucleo boards, and it looks to me like ALOT of the possible pinmaps are missing. For some missing I can imagine reasons, and I only looked at it shortly (since I don't have them myself anyway), but unless I am mistaken it is missing most pinmap options.

Something which I think is better to mention here before I go ahead and remove it and create a pull request. The issue:

void deepsleep(void) {
    // ensure debug is disconnected
    mbed_interface_disconnect();

    // PCON[PD] set to deepsleep
    LPC_PMU->PCON = 0x1;

    // SRC[SLEEPDEEP] set to 1 = deep sleep
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;

    // Power up everything after powerdown
    LPC_SYSCON->PDAWAKECFG &= 0xFFFFF800;

    // wait for interrupt
    __WFI();
}

Since the M0 core is not debug aware, it will always try to disconnect the mbed interface. If there is none (ie: Seeeduino Arch, DipCortex, but also when powering it from battery), it will hang/crash there. It only works if the original LPC11u24 is fully powered.

Why is it called? Because it cannot enter deepsleep when debugger is connected. However that is only partially true. Yes, the power consumption is high when deepsleeping with debugger connected (I assume this, that was the case with the KL25Z, I cannot easily measure it on the mbed LPC11u24). However considering it only actually works with the complete mbed powered, that is probably the least of your issues. Considering the interface isn't powered down, it still consumes power. The voltage regulators already consume combined 10mA quiescent current.

I ran some tests, and also with debugger outside of power consumption it seems to behave pretty much the same: peripherals are shut down, so my regular timer interrupt was never called while in deepsleep. Wakeup time from an external interrupt was within the measurement uncertainity for debugger connected and disconnected.

So the TL;DR, I would propose removing that line, outside of power consumption it doesn't do anything, and power consumption is huge anyway with the complete board powered.
Advantage is that it actually works on the other boards with the LPC11u24, and when powered via the battery pin, which is the case when you want it low power.

And finally, from the sleep modes I made I always put it in the equivalent of powerdown instead of deepsleep, just changing one bit in the code here: Compared to deepsleep it takes barely longer to wakeup, the only relevant difference is that flash memory is in standby instead of running, but it consumes alot less power. (That is according to the datasheet and my experience with KLxxs and LPC812, on my LPC11u24 board I still have a 400uA unaccounted for).
My own measurements give roughly 20us longer required for waking from powerdown (on a total of 680us).

The AnalogIn class currently takes 176µs for a floating point reading, and 173µs for an 16-bit integer reading on the LPC11U68. By comparison, the LPC11U24 (which has basically the same peripherals as the LPC11U68) only takes 18µs for a floating point reading, and 14µs for an 16-bit integer reading. Something is clearly amiss here... I've attached my benchmark code and findings:

#include "mbed.h"

Timer timer;
AnalogIn adc(A0);

int main()
{
    float a = 0.0;
    unsigned short b = 0;

    printf("\nTesting floating point A/D performance...\n\n");

    timer.start();
    for (int i = 0; i < 1000000; i++) {
        a = adc.read();
    }
    timer.stop();
    printf("\tResult (%f): %fus\n", a, timer.read_us() / 1000000.0);
    timer.reset();

    printf("\nTesting integer A/D performance...\n\n");

    timer.start();
    for (int i = 0; i < 1000000; i++) {
        b = adc.read_u16();
    }
    timer.stop();
    printf("\tResult (0x%X): %fus\n", b, timer.read_us() / 1000000.0);
    timer.reset();
}

It looks like the HAL implementation for the LPC11XX and the LPC11CXX are virtually the same, except for:

• a few extra I/O pins on the LPC11XX
• the extra can peripheral on the LPC11CXX
• reserved memory for on chip drivers on the LPC11CXX (0x1000 0050 - 0x1000 00B8)

I noticed that a lot of bugs already got fixed on the LPC11XX leaving both directories out of sync. Would it make sense to use one target folder and just use a few ifdefs for the minor differences?

I have made some changes to the USBHost code to get it building with GCC_ARM but I am not confident enough in the changes to issue a pull request. Instead, I would really appreciate a code review of the changes which can be viewed at the following link: https://github.com/adamgreen/mbed/compare/master...gccFixUSBHost The commit descriptions contain more details about each of my changes.

What I have done for testing so far:

• Made sure the library builds successfully with GCC_ARM using my makefiles and the official mbed python build scripts.
• Used GCC_ARM to build and test the USBHostMSD_HelloWorld sample found here-> http://mbed.org/handbook/USBHostMSD. It ran successfully.
• I took my updated USBHost library sources and uploaded then into a USBHostMSD_HelloWorld project on the mbed site. I then built the code using the online compiler and tested the resulting binary.
• I have used GCC_ARM to build and test USBHostMouse, USBHostKeyboard, USBHostSerial, and USBHostHub samples as found in the mbed Handbook.

Thanks and I look forward to your feedback.

-Adam