Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Teensy 4.0 and CMSIS + SDK

  1. #1
    Junior Member
    Join Date
    Feb 2020
    Posts
    6

    Teensy 4.0 and CMSIS + SDK

    Hi all. I have a teensy 4.0 and I would like to use the NXP SDK (CMSIS peripheral access layer).

    I know that currently there's an external NOR flash that has a custom USB DFU-like bootloader.

    Normally there is a way to use the SDK to write a firmware for the board and overwrite the flash.
    I don't mind losing the arduino bootloader, I just want to know if it's possible to use T4.0 as a generic dev board using the SDK or the current fuses (or some other limitation) doesn't allow this.

    I've seen a couple of repos in github, but those are using the a bootdata.c file and not the startup file from the SDK that includes the mapping for interrupts e.t.c.

    Thanks.

  2. #2
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,566
    1) you cannot tamper with Teensy bootloader it is in own chip.
    2) you can easily port what ever you want to Teensy, you only have to comply with Teensy burned-in basic configuration (about which I pers. have no knowledge)
    3) If you ever get CMSIS-only working on T4.0, please let us know.

  3. #3
    Junior Member
    Join Date
    Feb 2020
    Posts
    6
    OK, I see. Then the bootloader is in the external MCU, which runs it's own dfu and handles the write to the spi flash and then pass the execution to an offset in there. Also the fuses are configured to boot only from there, I guess, which means I would have to desolder that MCU and blah blah that goes too far away.

    Yeah, probably doesn't worth the trouble for what I need then. Regarding CMSIS, I guess it can be done with some tickering, but again I don't know if it worths spending time for what I need to do.

    Thanks for the reply!

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    Teensy's bootloader and the Teensy Loader software will allow you to write any HEX file onto your Teensy's flash chip. So you could use alternate software with CMSIS to create firmware that runs on Teensy. You just need to have it output data for the flash chip in standard Intel HEX format.

    Your HEX file must contain the full firmware image, including the 512 byte boot data sector and IVT data structures that NXP documents in the chip's reference manual. You can find copies of the ones we use in Teensy's core library code. I haven't used NXP tools much (or really, at all for that matter) but when I looked briefly during the beta test, I got the impression their tools were adding some of that stuff rather than having it all in the data created by the toolchain. Teensy requires all of the flash chip's data to be in the HEX file.

    One small gotcha is Teensy Loader checks for an ELF file in the same folder as the HEX file. If the ELF file is present, and if its binary data is an exact match to the HEX file's data, then the ELF file is used to check which Teensy model your toolchain used. If you try to upload code compiled for Teensy 3.2 to a Teensy 4.0, you'll get an error message from Teensy Loader. If you create a HEX file using other software which also generates an ELF file, you may need to copy the HEX file to a different folder, or rename or move either file so Teensy Loader doesn't get confused by the ELF file.

  5. #5
    Junior Member
    Join Date
    Feb 2020
    Posts
    6
    Thanks for the detailed answer Paul. That means then that I could use the SDK to build a firmware and then upload the hex. Therefore it seems that the external MCU is acting pretty much as an external JTAG/flasher and then it lets the main MCU boot from the flash.

    Can you please tell me if the MCU is reset after the bootloader uploads the hex? I mean, is everything in a reset state when the HEX firmware boots, so I can use the SDK startup file to setup the vector tables or there is some magic going on that sets the nxp to a specific state and then the HEX firmware runs?

    I've had a brief look to your DMA implementation and if I understand right, for the NXP is only memory to memory and I can use your interface to link any peripherals or memory, right? If that's the case that's way more powerful compared to the STM implementation.

    Excuse the naive questions, I haven't read the reference manual in detail and I'm new to the NXP's architecture.

    My plan is to be able to create a cmake template project to be able to use the SDK peripheral library as a base for other projects. I've done the same for various stm32 MCUs and it helps me to start new projects.

    (By the way, since it's my first post in the forums, you've done a great job with the whole ecosystem)

  6. #6
    Junior Member
    Join Date
    Feb 2020
    Posts
    6
    Got it working. Eventually, it was much simpler than I thought.

    Actually the hint was Paul's description about the architecture and then I've made some assumptions that were actually true and now I can run the SDK examples using CMSIS e.t.c.

    I'll post a short guide later or maybe write a post on my blog and post it here.

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    Quote Originally Posted by dimtass View Post
    Can you please tell me if the MCU is reset after the bootloader uploads the hex?
    Yes, hardware reset using the physical reset pin.


    so I can use the SDK startup file to setup the vector tables or there is some magic going on that sets the nxp to a specific state and then the HEX firmware runs?
    Sorry, can't answer questions about other tools we don't support.


    I've had a brief look to your DMA implementation and if I understand right, for the NXP is only memory to memory and I can use your interface to link any peripherals or memory, right?
    Yes, the DMAChannel.h stuff is for the eDMA hardware, which is a very generic memory-to-memory copy. It can access everything on the AXI bus, and ITCM and DTCM too, so you can use it for almost anything. However, I believe the one exception is the private peripheral bus inside the ARM core (memory range 0xE0000000 & up), so I don't believe DMA can access stuff like the MPU or NVIC or SCB registers.

    Most of the fast peripherals, like USB, SDIO, Ethernet have their own bus master DMA which is completely separate and independent from the generic DMA.


    My plan is to be able to create a cmake template....
    Maybe the sample makefile can help? After installing Teensyduino, look for it in {Arduino}/hardware/teensy/avr/cores/teensy4.

    The Arduino IDE also has an option for "external editor" in File > Preferences. It disables Arduino's editor and Arduino automatically detects when you edit the files. Many people (myself included) use Arduino this way, with a different editor but then you can just click the Upload button in the Arduino window to build and load your code.

  8. #8
    Junior Member
    Join Date
    Feb 2020
    Posts
    6
    Thanks for your time Paul.

    As I've mentioned on my previous post I have it working now and I'll post the details.

    I haven't tested all the cmsis examples, but I don't see why the shouldn't work. If that's the case, then Teensy 4.0 is by far the cheapest and best dev board also for the official NXP SDK.

  9. #9
    Junior Member
    Join Date
    Feb 2020
    Posts
    6
    I've written a post with a guide how to build and flash firmwares using the SDK and CMSIS on the Teensy 4.0 here:

    https://www.stupid-projects.com/usin...th-teensy-4-0/

    I can't edit my first post and title to add the information there and mark it as resolved.

Posting Permissions

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