Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 25 of 103

Thread: [Testers Needed] Mbed OS Port for Teensy 4.0

  1. #1
    Member MultipleMonomials's Avatar
    Join Date
    Feb 2023
    Location
    Los Angeles, CA
    Posts
    27

    [Testers Needed] Mbed OS Port for Teensy 4.0

    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!

    Click image for larger version. 

Name:	2caa0f92be9447d2cddca363000dfe82cca7718f.png 
Views:	13 
Size:	16.0 KB 
ID:	30318

    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/w...:-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.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    Which operating systems are supported? Does it work in Linux and MacOS?

    Edit: oh, I see the install instructions have Windows, Mac and Linux.
    Last edited by PaulStoffregen; 02-06-2023 at 04:06 AM.

  3. #3
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,763
    Tried but failed.

    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 by manitou; 02-08-2023 at 05:17 PM.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    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 by PaulStoffregen; 02-06-2023 at 06:27 PM.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    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).

  6. #6
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,763
    Quote Originally Posted by PaulStoffregen View Post
    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...B-(600-Mhz-M7)

    NXP 1050 vs 1060
    Last edited by manitou; 02-07-2023 at 12:48 PM.

  7. #7
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,763
    Quote Originally Posted by MultipleMonomials View Post
    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 by manitou; 02-06-2023 at 09:54 PM.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    Quote Originally Posted by manitou View Post
    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,
            (uint32_t)&__USED_FLASH_END,
            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
    :1010200000000060004401600000000000000000BB
    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.

  9. #9
    Member MultipleMonomials's Avatar
    Join Date
    Feb 2023
    Location
    Los Angeles, CA
    Posts
    27
    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.

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    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.

  11. #11
    Member MultipleMonomials's Avatar
    Join Date
    Feb 2023
    Location
    Los Angeles, CA
    Posts
    27
    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...

  12. #12
    Member MultipleMonomials's Avatar
    Join Date
    Feb 2023
    Location
    Los Angeles, CA
    Posts
    27
    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?

  13. #13
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    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
    };

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    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 */
    
        .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
    
        .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.

    Name:  led.jpg
Views: 299
Size:  13.4 KB

    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.

  15. #15
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    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.

  16. #16
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,763
    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"

    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 by manitou; 02-07-2023 at 08:47 PM.

  17. #17
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    I also saw the alternating patterns of 4 blinks (without anything in main to blink the LED).

  18. #18
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    Maybe this is the code doing the blinking?

    https://github.com/mbed-ce/mbed-os/b...ed_board.c#L36

    If only it were to blink a stack trace in Morse code, or even just the LR register.

  19. #19
    Senior Member
    Join Date
    Sep 2021
    Posts
    186
    Quote Originally Posted by PaulStoffregen View Post
    If only it were to blink a stack trace in Morse code
    ... amazing. something like this has been in demand here for more than a decade

  20. #20
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    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.

  21. #21
    Member MultipleMonomials's Avatar
    Join Date
    Feb 2023
    Location
    Los Angeles, CA
    Posts
    27
    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?

  22. #22
    Member MultipleMonomials's Avatar
    Join Date
    Feb 2023
    Location
    Los Angeles, CA
    Posts
    27
    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.

  23. #23
    Member MultipleMonomials's Avatar
    Join Date
    Feb 2023
    Location
    Los Angeles, CA
    Posts
    27
    > 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.

  24. #24
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    27,665
    Quote Originally Posted by MultipleMonomials View Post
    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

  25. #25
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,763
    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 by manitou; 02-08-2023 at 05:19 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •