Unclear where firmware example comes from/cannnot reproduce

[tloanPhytec]

mcu-plus-sdk-firmware/am64x/m4f0/am64-mcu-m4f0_0-fw is used in the Linux BSP.

It is not clear which MCU+ SDK (https://github.com/phytec/mcu-plus-sdk) example provides this binary and this is important information for customers to recreate it.

Is it:

• examples/drivers/gpio/gpio_led_blink/phyboard-electra-am64xx/m4fss0-0_nortos (branch mcu_plus_sdk_am64x_09_02_01_05) ?
• or demo/phyboard-electra-am64xx/m4fss0-0_freertos (branch mcu_plus_sdk_am64x_09_02_01_05) ?

I have tried building/running both of these and neither matches the behavior of the binary included with the Linux BSP.

mcu-plus-sdk-firmware/am64x/m4f0/am64-mcu-m4f0_0-fw

• start/stop in sysfs works
• mcu_uart output works
• blinking heartbeat works

demo/phyboard-electra-am64xx/m4fss0-0_freertos (branch mcu_plus_sdk_am64x_09_02_01_05)

• start/stop in sysfs DOES NOT work
• mcu_uart output works
• blinking heartbeat DOES NOT work (solid on, no blinking)

examples/drivers/gpio/gpio_led_blink/phyboard-electra-am64xx/m4fss0-0_nortos (branch mcu_plus_sdk_am64x_09_02_01_05)

• start/stop in sysfs DOES NOT work
• mcu_uart output works
• blinking for 5 seconds works

It looks like demo/phyboard-electra-am64xx/m4fss0-0_freertos (branch mcu_plus_sdk_am64x_09_02_01_05) is the one used in the Linux BSP... but their seems to be some mismatch between the source for this example and the prebuilt binary.

[dnltz]

It's the demo/phyboard-electra-am64xx/m4fss0-0_freertos but you need to build the Release target.

[tloanPhytec]

Thanks Daniel, that worked.

Why does the build profile (Release vs Debug) change the behavior of the demo? Shouldnt these work the same?

[dnltz]

They reason for two different build profiles lies in the IPC initialization: https://github.com/phytec/mcu-plus-sdk/blob/cca71574f3d4e7d032fb6942c707fb267ff936f5/demo/phyboard-electra-am64xx/m4fss0-0_freertos/main.c#L111

The Linux remoteproc driver will notify all co-processors when they can start the application.

When flashing a firmware directly into the co-processor memory, we need to disable this check since the Linux driver is already loaded and won't send the wake-up notification again.