Developer experience programming the M4 on the iMX8MM

I’ve been reading through different documentation about programming the M4 processor on the iMX8MM and have successfully ran the hello_world example in the official NXP SDK.

However I was wondering what the preferred and fastest way to flash the chip is when actively developing with the board? Is there any documentation for such a workflow?

Re-uploading the .bin/.elf with a J-Link is fine during development, but this does not setup up the binary to start on boot (as far as I am aware)

Using u-boot is fine but a very cumbersome process to repeat every time.

I noticed the VSCode integration uses the J-Link solution behind the scenes.

Would love to hear if there is a preferred method of development. For example is there a process on the Torizon side of things that allows me to easily upload a .bin file using ssh for example? And how will this work with OTA support when updating not only the docker-compose file but also the cortex-m software?


Hi @samuelous,

First, welcome to our community! Feel free to ask any questions you might have.

Although we don’t have any specific documentation about workflow, you can save the commands you ran with u-boot using the “saveenv” command and add them to your boot command, so you do that only once. Every time u-boot boots again, it will load your firmware automatically. For more instructions, please check this guide: High performance, low power Embedded Computing Systems | Toradex Developer Center. The second part shows how to run your firmware automatically on every boot.

You can also set up everything using the u-boot-env-sd file, so when you flash your image with TEZI, all the commands for u-boot will be ready to use.

We have a guide for VSCode debugging as well, you can check it here: High performance, low power Embedded Computing Systems | Toradex Developer Center

We don’t have anything prepared on TorizonCore right now that works with Cortex-M as you described. However, we’re working right now with new features on the Torizon Platform that will allow changing the binary more easily.

For now, you can create a new OStree commit with your updated binary inside and commit this new version to your module. This won’t be that easy though, because the etc and var folders are not part of OSTree.

Unfortunately, for OTA, I recommend you wait our next release of the Torizon Platform that will enable such features.

Best Regards,

Thank you for the reply!

Is there an example somewhere on how to configure this in the tcbuild.yaml?

This is fine for our use-case, we can work around that no problem.

Hi @samuelous,

For now, TorizonCore Builder does not support modifying the u-boot environment variables.

To change that, we have two options:

  1. First, create a custom TorizonCore build with Yocto. This can be hard if you’ve never worked with Yocto before. There is an example on this thread: Bitbake recipe to modify u-boot-default-env or boot.scr

  2. Second, edit the u-boot environment file manually. Note that you only need to edit this file once, since you can use the same TorizonCore image to flash all of your modules. If you download an image from our feeds and extract the file, you will see the file inside called u-boot-initial-env-sd. This file can be edited to include the variables related to the Cortex-M, as described here: How to load compiled binaries into Cortex-M | Toradex Developer Center

Let me know if you have any questions.

Best Regards,

Hello @samuelous ,

Do you have any updates on this topic? Were you able to try the suggestions from @hfranco.tx ?

Best regards,