3.- Another trial has been done with the real custom application we developed. This application has been tested and works with a previous Linux BSP v2.3 beta 1 (kernel 3.0.15) and the same MQX 4.1.1 version. Similar to the previous trial, when debugging, I can get to enable MQX OS. But after that, the application gets stuck in a serial port initialization and if I pause the debugging session I can see it jumps to the same idle task as in the 2nd test I've done.

All the debug sessions have been done while VF61 is in uboot.

Any clue of what is happening that the MQX OS is not able to create any custom task and run normally?

I have ran that hello world example on Toradex's Colibri while back, following their howto, and it worked fine.

One thing I want to note: make sure you reset your SoC properly before any code example change / re-upload. In my experience, it is not possible for MQX to initialize properly unless from a complete clean system out of reset. That's my observation and current state of my code, and I have asked multiple times about it various places, but never got to understand why.

(Besides that you cannot re-set/restart M4 on Vybrid of course.)

If you resolved your issue, please share what helped you. I'm also working on the Toradex VF61x module.

(Note: I'm not from NXP, so I guess take everything I say as suspicious )

The sources I used were taken from Toradex and MCC support is present in it. The thing was that some initializations for some peripherals that were properly done with the previous kernel/u-boot, weren't done in this kernel/u-boot.

After changing u-boot sources in order to enable clocks and initialize those peripherals, code wasn't getting stuck anymore and the execution went through.