[Testers Needed] Mbed OS Port for Teensy 4.0

MultipleMonomials

Active member
Hello! I'm Jamie, one of the developers of Mbed OS Community Edition. We are working on a port of Mbed OS for the Teensy 4.0 (and soon, Teensy 4.1) boards, and I need help from someone who owns a board to test our builds!

2caa0f92be9447d2cddca363000dfe82cca7718f.png

What is Mbed OS?
Mbed OS is an operating system created by ARM to aid development of code for its microprocessors, especially for networked and Internet of Things applications. Mbed OS provides a high-level C++ API that is concise and easy to use, but also provides access to many advanced features of ARM chips such as wireless communication and asynchronous operations. Thanks to its high-level API, Mbed helps you write code that can be used across of wide variety of processors without needing significant changes.

What does Mbed OS code look like?
- See a hello world example here
- See an I2C communication example here (scroll down a bit)
- See an Internet communication example here

What is Mbed CE?
Unfortunately, Mbed OS was put into maintenance mode in January 2022, after which development of new features and bugfixes by ARM stopped. Community bugfixes are still being accepted, but that's it.

To keep development on Mbed OS running, and to fix some of the idiosyncrasies created by years of ARM constantly changing direction on the project, I and several other community members created Mbed OS Community Edition (CE). To summarize, we are working on fixing longstanding bugs, improving the build system, creating better documentation, and expanding Mbed OS to support an even wider number of targets. Being blunt, we've still got a long way to go, but we are making good progress!

Why use Mbed over Arduino IDE / the Teensy Arduino core?
To be honest, if you are a casual Arduino user, and you have found everything you need in the Arduino ecosystem, Mbed may not be for you -- the Arduino ecosystem does an excellent job of making the basics well-documented and easy to use. Mbed does require some prerequisite knowledge -- you will need to be comfortable working with git, using the command line, and installing the ARM toolchain. We have a guide for this, but experience is recommended.

However, Mbed should be very useful to those of you who are working with more complex systems and are starting to push against the limits of the Arduino framework. Need to work with lots of SPI, I2C, and UART peripherals at the same time? We got you. Want an object-oriented, POSIX-like socket API that handles different transport layers, encryption, and arbitrary network interfaces? No problem. Need to create multiple threads that time-share the processor, and then exchange data between them? This is what Mbed's RTOS and EventQueue libraries are designed for. Basically, if you want to create more complex applications that squeeze all the features out of the MIMXRT1062 processor, Mbed may be what you need.

The other big benefit of Mbed OS is its build system. Gone is Mbed's obtuse and finicky build system of the past -- it has been replaced by a sleek, logically structured CMake-based build system. CMake is highly expandable, allowing you to structure your project any way that you wish. Want to create multiple executables and libraries in a single project and link them together? Have source files that are auto-generated by a script or external tool? Want to set up unit tests that run on real hardware and report results back to your computer? All of these, and more, are possible with Mbed's build system plus a little bit of CMake script written by you.

Furthermore, the build system has been optimized at every turn for rapid and convenient development. There will be no inefficiencies like waiting for full rebuilds or manually copying/flashing programs to your board. We have out-of-the-box support for two IDEs, CLion and VS Code. If you use either of these, IntelliSense works straightaway and you can build code with a single click (automatic flashing via Teensy Loader will hopefully be added soonish). [Command-line building](https://github.com/mbed-ce/mbed-os/wiki/Project-Setup:-Command-Line) is also straightforward. Since CMake is using its efficient Ninja backend, builds are multicore and code is only recompiled when strictly needed. And since the Mbed source gets added as a submodule, instead of an opaque binary, it's easy for you to view or debug the lower layers when needed.

Using Mbed on the Teensy 4.0
Mbed has been extensively tested on the MIMXRT105x line of processors, but until now, it didn't contain the correct low-level init code to boot up on the Teensy 4.0. My recent patch changes this, so it should now, theoretically, work out of the box. What I need is for someone to test this!

First of all, you may want to read the doc page I wrote that explains how this processor works with Mbed OS.
Next, you must install the toolchain per the guide here.

For starters, I'd like someone to try and build the hello world project for the Teensy 4.0 (-DMBED_TARGET=TEENSY_40). If you follow the instructions in the readme to build the project, you should see a hex file in the build directory. If you flash that hex file with Teensy Loader, you should see the board enumerate as a USB serial device which will print "Hello World" at 115200 baud. If not, something must have gone wrong, so let me know!

To sum up: I'm happy to be able to bring Mbed OS to the Teensy line, and really excited to provide another option for larger projects using these microcontrollers. But, I need support from some Teensy users to make it happen! So, please give this a shot if you're interested and able.
 
Tried but failed. :confused:

on Ubuntu 18.04.06 with stock arm-none-eabi-g++ version 6.3.1, cmake looked OK, and ninja built HelloWorld.hex
Code:
ninja
[2/2] Linking CXX executable HelloWorld.elf
-- built: /ssd/mbed-ce-hello-world/build/HelloWorld.bin
-- built: /ssd/mbed-ce-hello-world/build/HelloWorld.hex
| Module                    |         .text |       .data |        .bss |
|---------------------------|---------------|-------------|-------------|
| CMakeFiles/HelloWorld.dir |       50(+50) |       0(+0) |       0(+0) |
| [fill]                    |     208(+208) |       4(+4) |     31(+31) |
| [lib]/c.a                 | 14762(+14762) | 2240(+2240) |     56(+56) |
| [lib]/gcc.a               |     832(+832) |       0(+0) |       0(+0) |
| [lib]/mbed-usb.a          | 10667(+10667) |       0(+0) |       2(+2) |
| [lib]/misc                |     268(+268) |       4(+4) |     28(+28) |
| [lib]/nosys.a             |       32(+32) |       0(+0) |       0(+0) |
| [misc]                    |         0(+0) |       0(+0) |       0(+0) |
| mbed-os/CMakeFiles        | 40200(+40200) |   436(+436) | 8379(+8379) |
| Subtotals                 | 67019(+67019) | 2684(+2684) | 8496(+8496) |
Total Static RAM memory (data + bss): 11180(+11180) bytes
Total Flash memory (text + data): 69703(+69703) bytes
BUT if i use the cli to load the .hex onto T4.0, T4.0 is flashing its red LED 8 times (no USB tty device appears)
Ref: T4 diagnostic blink codes

i also tried latest toolchain version 12.2.1, but ninja failed with "ninja: build stopped: subcommand failed" see post #34
 
Last edited:
Tried it here. Same result, doesn't work. Same 8 blink error.

It printed this at the end of the build process

Code:
[251/251] Linking CXX executable HelloWorld.elf
-- built: /tmp/mbed-ce-hello-world/build/HelloWorld.bin
-- built: /tmp/mbed-ce-hello-world/build/HelloWorld.hex
| Module                    |         .text |       .data |        .bss |
|---------------------------|---------------|-------------|-------------|
| CMakeFiles/HelloWorld.dir |       50(+50) |       0(+0) |       0(+0) |
| [fill]                    |     169(+169) |       4(+4) |     31(+31) |
| [lib]/c.a                 | 15223(+15223) | 2476(+2476) |     56(+56) |
| [lib]/gcc.a               |     760(+760) |       0(+0) |       0(+0) |
| [lib]/mbed-usb.a          | 10435(+10435) |       0(+0) |       2(+2) |
| [lib]/misc                |     248(+248) |       4(+4) |     28(+28) |
| [lib]/nosys.a             |       32(+32) |       0(+0) |       0(+0) |
| [misc]                    |         0(+0) |       0(+0) |       0(+0) |
| mbed-os/CMakeFiles        | 39797(+39797) |   436(+436) | 8379(+8379) |
| Subtotals                 | 66714(+66714) | 2920(+2920) | 8496(+8496) |
Total Static RAM memory (data + bss): 11416(+11416) bytes
Total Flash memory (text + data): 69634(+69634) bytes

Same Teensy 4.0 works fine when programmed with Arduino IDE. Button press is required for first upload to recover from the bad HelloWorld.hex code.

If anyone else wants to try, recovery only requires normal button press. The 15 second button press isn't needed to get back to loading new code.


Edit, here's the output of "arm-none-eabi-gcc -v" on the machine I used.

Code:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/9.2.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/lib/include' --mandir='/usr/lib/share/man' --infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --mandir=/usr/share/man --enable-languages=c,c++,lto --enable-multilib --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --enable-tls --build=x86_64-linux-gnu --target=arm-none-eabi --with-system-zlib --with-gnu-as --with-gnu-ld --with-pkgversion=15:9-2019-q4-0ubuntu1 --without-included-gettext --prefix=/usr/lib --infodir=/usr/share/doc/gcc-arm-none-eabi/info --htmldir=/usr/share/doc/gcc-arm-none-eabi/html --pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --disable-libstdc++-v3 --host=x86_64-linux-gnu --with-headers=no --without-newlib --with-multilib-list=rmprofile CFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' FCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0 AR_FOR_TARGET=arm-none-eabi-ar AS_FOR_TARGET=arm-none-eabi-as LD_FOR_TARGET=arm-none-eabi-ld NM_FOR_TARGET=arm-none-eabi-nm OBJDUMP_FOR_TARGET=arm-none-eabi-objdump RANLIB_FOR_TARGET=arm-none-eabi-ranlib READELF_FOR_TARGET=arm-none-eabi-readelf STRIP_FOR_TARGET=arm-none-eabi-strip
Thread model: single
gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (15:9-2019-q4-0ubuntu1)


Edit again: should mention, I tested on standard Teensy 4.0. If anyone else tries this, please don't risk a lockable Teensy 4.0. If the boot fuses get changed the wrong way, your lockable Teensy 4.0 could get permanently bricked. Standard Teensy 4.0 has the boot config fuses protected from changes, so much safer for experimenting.
 
Last edited:
I glanced at the linker script and generated code. Can't see anything obviously wrong.

I noticed you have a .csf section. Are you supporting code signing and BEE on-the-fly decryption? Of the many developments on Teensy, adding the code security stuff was by far the most difficult. If you're supporting those features, I'm curious to hear how (at least as much as you're allowed to say, please don't reveal any NXP confidential info).
 
I glanced at the linker script and generated code. Can't see anything obviously wrong.

I noticed you have a .csf section. Are you supporting code signing and BEE on-the-fly decryption? Of the many developments on Teensy, adding the code security stuff was by far the most difficult. If you're supporting those features, I'm curious to hear how (at least as much as you're allowed to say, please don't reveal any NXP confidential info).

Paul, have you examined mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/TARGET_TEENSY_4X/bootdata.c

Above my pay grade ...

Seems like the mbed T4.0 code is derived from the 1050. I did some mbed testing on 1050 EVKB as part of pre-testing (2018) for the Teensy 4,
https://forum.pjrc.com/threads/54265-Teensy-4-testing-mbed-NXP-MXRT1050-EVKB-(600-Mhz-M7)

NXP 1050 vs 1060
 
Last edited:
and I need help from someone who owns a board to test our build

My recent patch changes this, so it should now, theoretically, work out of the box. .

So have you actually run your HelloWorld project on a T4.0?

maybe add the HellowWorld.hex to your git repository.

I believe T4.0's are in stock at pjrc.com
 
Last edited:
Paul, have you examined mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/TARGET_TEENSY_4X/bootdata.c

Was going to wait until Jamie chimes in again before looking at this code again, but since you mentioned it...

Code:
__attribute__ ((section(".boot_hdr.boot_data"), used))
const uint32_t BootData[3] = {
        0x60000000,
        [COLOR="#FF0000"](uint32_t)&__USED_FLASH_END[/COLOR],
        0
};

Pretty sure this line is wrong. It's supposed to be the total length. But looking at the .HEX file, I see this:

Code:
:10100000D1002043F924006000000000000000002F
:101010002010006000100060003801600000000037
:1010200000000060[COLOR="#FF0000"]00440160[/COLOR]0000000000000000BB

Looks like it's putting 0x60014400 into the boot data table as the image length. Obviously the code isn't 1.5 gigabytes. I'm pretty sure it should have been this:

Code:
__attribute__ ((section(".boot_hdr.boot_data"), used))
const uint32_t BootData[3] = {
        0x60000000,
        (uint32_t)&__USED_FLASH_END - 0x60000000,
        0
};

I tried just now with this change and the .HEX file does seem to get a valid length in the boot data. But that doesn't seem to be the only problem. I still get no USB enumeration and 8 blink error.

If this code has only ever been tested on NXP's older eval boards and never even run on actual Teensy hardware, probably plenty of other things are wrong. I'm not planning to look deeper, at least not until Jamie replies.
 
Thanks a ton for giving it a shot, guys! Home from work now so I will check this out.

> Seems like the mbed T4.0 code is derived from the 1050

Yep, that's correct. It's based on Mbed's 105x HAL layer, plus boot code from the Teensy Arduino core that I adapted. However, I have a fair amount of experience (from where I can't say) that tells me the 105x and 106x chips are identical apart from a few differences in peripherals (and one nasty incompatibility in the flash header). I verified this by testing the Mbed code on the 1060_EVKB board, which worked fine (except for the low-power mode code, for some reason, so I disabled that for now).

> Are you supporting code signing and BEE on-the-fly decryption?

At this time, no. I only added the csf section for compatibility with the Teensy bootcode and linker script, under the assumption that Teensy Loader or the bootloader might expect it to be there.
 
I can confirm the csf section is only needed if you run the teensy_secure program which creates the .ehex file from the .hex file. Everything else just ignores it.
 
Hmm, I took a look through the boot stuff in the hex file (IVT + flash config + vector table) and I didn't see anything that screamed out at me as being wrong. Addresses for various things match the map file and are in the correct regions of memory.

I think that debugging this might be a pain. Seems like I'll have to get a Teensy board, then rework the board to mod a JTAG debugger onto it (probably have to use a J-Link, since there's nothing else that knows how to program a MIMXRT out of the box), then try and figure out where it's getting into trouble in the boot process.

That said, I'd appreciate any insights you could provide into what the 8-blink error might be caused by. The explanation on that page doesn't really seem to make sense for a software boot problem...
 
The only thing I did notice is, the Teensy bootdata.c file has this:
Code:
const uint32_t ImageVectorTable[8] = {
	0x432000D1,		// header
	(uint32_t)&Reset_Handler,// program entry
	0,			// reserved
	0,			// dcd
	(uint32_t)BootData,	// abs address of boot data
	(uint32_t)ImageVectorTable, // self
	(uint32_t)hab_csf,	// command sequence file
	0			// reserved
};
Index 6 has a pointer to the hab_csf block, but this block isn't being filled in by anything in the Mbed toolchain. The version of this file used on the dev kit sets the CSF pointer to 0, and maybe the MIMXRT doesn't like it if you provide a CSF block but don't put anything in it. What happens if you change the second-to-last entry in this array to 0?
 
Tried this. Same result, no boot, 8 blink error

Code:
__attribute__ ((section(".boot_hdr.ivt"), used))
const uint32_t ImageVectorTable[8] = {
        0x432000D1,             // header
        (uint32_t)&Reset_Handler,// program entry
        0,                      // reserved
        0,                      // dcd
        (uint32_t)BootData,     // abs address of boot data
        (uint32_t)ImageVectorTable, // self
        0, //(uint32_t)hab_csf, // command sequence file
        0                       // reserved
};
 
I can confirm the code is starting up, before something goes wrong.

Added this to mbed-ce-hello-world/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/device/TOOLCHAIN_GCC_ARM/startup_MIMXRT1052.S

Code:
    .text
    .thumb

/* Reset Handler */

    .thumb_func
    .align 2
    .globl   Reset_Handler
    .weak    Reset_Handler
    .type    Reset_Handler, %function
Reset_Handler:
    cpsid   i               /* Mask interrupts */
[COLOR="#00CF00"]
    .equ    IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03, 0x401F8338
    ldr     r0, =IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03
    ldr     r1, =(7 << 3)
    str     r1, [r0]  // IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 = IOMUXC_PAD_DSE(7);
    .equ    GPIO2_GDIR, 0x401BC004
    ldr     r0, =GPIO2_GDIR
    ldr     r1, =(1 << 3)
    str     r1, [r0] // GPIO2_GDIR = (1<<3);  Pin 13 to output mode
    .equ    GPIO2_DR_SET, 0x401BC084
    ldr     r0, =GPIO2_DR_SET
    ldr     r1, =(1 << 3)
    str     r1, [r0] // GPIO2_DR_SET = (1<<3);  Pin 13 drive high[/COLOR]

    .equ    VTOR, 0xE000ED08
    ldr     r0, =VTOR
    ldr     r1, =__isr_vector
    str     r1, [r0]
    ldr     r2, [r1]
    msr     msp, r2

This definitely causes the orange LED connected to pin 13 to turn on.

led.jpg

With some effort, this or the C equivalent could be moved farther along the startup process to find the point where it no longer causes the LED to turn on.
 
Ok, by just moving that code around inside startup_MIMXRT1052.S, I pretty quickly found this is the part that's crashing.

Code:
#ifdef __STARTUP_INITIALIZE_NONCACHEDATA
    ldr    r2, =__noncachedata_start__
    ldr    r3, =__noncachedata_init_end__
#ifdef __PERFORMANCE_IMPLEMENTATION
/* Here are two copies of loop implementations. First one favors performance
 * and the second one favors code size. Default uses the second one.
 * Define macro "__PERFORMANCE_IMPLEMENTATION" in project to use the first one */
    subs    r3, r2
    ble    .LC3
.LC2:
    subs    r3, #4
    ldr    r0, [r1, r3]
    str    r0, [r2, r3]
    bgt    .LC2
.LC3:
#else  /* code size implemenation */
.LC2:
    cmp     r2, r3
    ittt    lt
    ldrlt   r0, [r1], #4
    strlt   r0, [r2], #4
    blt    .LC2
#endif
/* zero inited ncache section initialization */
    ldr r3, =__noncachedata_end__
    movs    r0,0
.LC4:
    cmp    r2,r3
    itt    lt
    strlt   r0,[r2],#4
    blt    .LC4
#endif /* __STARTUP_INITIALIZE_NONCACHEDATA */

If I just delete that part, and remove my 12 lines of test code, the CPU appears to boot up and run a program which blinks the LED in some sort of pattern. Still no USB enumeration.
 
I deleted lines from startup_MIMXRT1052.S and added blink logic to main.cpp
Code:
#include "mbed.h"
  
int main()
{
    DigitalOut myled(LED1);
    int p = 1;
    while(true)
    {
        printf("Hello world from Mbed CE!\n");
        myled = p;
        p = 1-p;
        ThisThread::sleep_for(1s);
    }

    // main() is expected to loop forever.
    // If main() actually returns the processor will halt
    return 0;
}
Program builds and loads. T4.0 LED flashes 4 times at 1hz and then 4 quicker flashes ... forever, but if i change to 5 second sleep, blink frequency doesn't change .... so something other than main.cpp is blinking the LED ???

edit: if i comment out the printf(), then the blink rate works at various sleep values .... but still no USB tty. You could use morse code over the LED to "communicate" :D

used blinks with "if" tests to confirm T4.0 is running at 528MHz. With morse code, T4.0 running at 528MHz
confirm wait_us() and TImer tmr.read_us() working, DigitalIn and DigitalOut working

tried PwmOut test on D12 -- i get the "mbed dead" blink pattern, AnalogIn also fails with dead blink pattern
 
Last edited:
For a completely blind guess, somehow I have a gut feeling at least some of the problems are going to turn out to be the TARGET_MIMXRT1050 code assuming SEMC should be configured to access SDRAM chips which are on NXP's eval boards.
 
Awesome work, guys! Great to hear that it is booting, maybe a JTAG won't be needed after all. I completely forgot that Mbed's fault handler also has an 8 blink pattern <facepalm>.

> TARGET_MIMXRT1050 code assuming SEMC should be configured to access SDRAM chips

Nope! I made sure to disable all of that in the teensy version of the code. How it works is, the Teensy 4.0 target (defined in targets/targets.json) applies the following definitions:
Code:
MIMXRT105X_BOARD_HAS_EXTERNAL_RAM=0
MBED_APP_SIZE=0x1f0000
These are picked up by the linker script and used to disable the external RAM + adjust the flash size to account for the teensy bootloader at the top of flash.

> If I just delete that part, and remove my 12 lines of test code, the CPU appears to boot up

Wow, interesting. I wouldn't have expected the startup code to die there... But looking into it, it looks like the __noncachedata_init section has zero size on the Teensy build, so maybe something's going wrong in the asm?
 
What I would like to try is, edit mbed_app.json in the hello world project and change it to:
Code:
{
    "target_overrides": {
        "*": {
            "platform.stdio-baud-rate": 115200,
            "platform.stdio-buffered-serial": 1,
            "target.console-usb": false,
            "target.console-uart": true
        }
    }
}

Then, rerun cmake and rebuild the project. That should change the default console to be a serial port on pins D1 and D0. Let's see if that works even if the USB console isn't.
 
> tried PwmOut test on D12 -- i get the "mbed dead" blink pattern

Oh I know what's causing that, looks like the original Mbed port for the dev board didn't include a mapping for that pin, because it isn't accessible on the dev kit. I can fix that, give me a day or two.
 
edit mbed_app.json in the hello world project and change it to: ...

Tried it. Still get the 4-4 blinks.

Here's the build summary. Does the zero size for mbed-usb.a confirm the change worked?

Code:
[234/234] Linking CXX executable HelloWorld.elf
-- built: /tmp/mbed-ce-hello-world/build/HelloWorld.bin
-- built: /tmp/mbed-ce-hello-world/build/HelloWorld.hex
| Module                    |         .text |    .data |       .bss |
|---------------------------|---------------|----------|------------|
| CMakeFiles/HelloWorld.dir |        50(+0) |    0(+0) |      0(+0) |
| [fill]                    |      126(-23) |    4(+0) |     24(-7) |
| [lib]/c.a                 |  13243(-1980) | 2476(+0) |     56(+0) |
| [lib]/gcc.a               |       760(+0) |    0(+0) |      0(+0) |
| [lib]/mbed-usb.a          |     0(-10435) |    0(+0) |      0(-2) |
| [lib]/misc                |       248(+0) |    4(+0) |     28(+0) |
| [lib]/nosys.a             |        32(+0) |    0(+0) |      0(+0) |
| [misc]                    |         0(+0) |    0(+0) |      0(+0) |
| mbed-os/CMakeFiles        |  37106(-2647) |  436(+0) | 7572(-807) |
| Subtotals                 | 51565(-15085) | 2920(+0) | 7680(-816) |
Total Static RAM memory (data + bss): 10600(-816) bytes
Total Flash memory (text + data): 54485(-15085) bytes
 
updated mbed_app.json, removed build directory and re-created with cmake etc. my build summary has no mbed_usb.a
Code:
[234/234] Linking CXX executable HelloWorld.elf
-- built: /home/dunigan/ssd/mbed-ce-hello-world/build/HelloWorld.bin
-- built: /home/dunigan/ssd/mbed-ce-hello-world/build/HelloWorld.hex
| Module                    |         .text |       .data |        .bss |
|---------------------------|---------------|-------------|-------------|
| CMakeFiles/HelloWorld.dir |     162(+162) |       0(+0) |     24(+24) |
| [fill]                    |     124(+124) |       4(+4) |     24(+24) |
| [lib]/c.a                 | 12878(+12878) | 2240(+2240) |     56(+56) |
| [lib]/gcc.a               |     832(+832) |       0(+0) |       0(+0) |
| [lib]/misc                |     268(+268) |       4(+4) |     28(+28) |
| [lib]/nosys.a             |       32(+32) |       0(+0) |       0(+0) |
| [misc]                    |         0(+0) |       0(+0) |       0(+0) |
| mbed-os/CMakeFiles        | 38176(+38176) |   436(+436) | 7572(+7572) |
| Subtotals                 | 52472(+52472) | 2684(+2684) | 7704(+7704) |
Total Static RAM memory (data + bss): 10388(+10388) bytes
Total Flash memory (text + data): 55156(+55156) bytes
with printf() in main.cpp I get "dead mbed" LED flashes

commenting out printf, then main.cpp runs with my sleep values ...

simple SPI example (unconnected) with printf's commented out, seemed to work -- or at least didn't go into mbed death flashing

simple I2C example got compile errors (pin symbols unrecognized)
 
Last edited:
Back
Top