IMXRT1060 example execution fails in release, but ok in debug

[camillelouapre]

Hello everyone,

I am facing a problem using MIMXRT1060-EVK, which contains an MIMXRT1062DVL6A.
I am trying to execute a simple example: SDK_PATH/boards/evkmimxrt1060/demo_apps/led_blinky
I use GCC (gcc-arm-none-eabi-8-2018-q4-major) as toolchain, and SDK_2.6.2_EVK-MIMXRT1060_for_gcc as SDK.

When I use provided ./armgcc/build_flexspi_nor_release.sh, it builds fine, and I am able to flash it on EVK at adress 0x60000000 using a Segger JLink base probe, and it runs fine.

We already have a makefile compilation system, so I would like to use it, and to avoid using MUXpresso IDE or other external tool.

I am able to build the example, building the same files, linking the same (flags extracted from CMake previous compilation), both in release and debug.

When I launch the debug or release binary with the debugger (using MCUXpresso - just for debug), it works, the led blinks.
When I flash the release binary, using the Segger tool (not using MCUxpresso debug session), nothing happens, it does not work, even after a reset.

I am not familiar with NXP chip, but I have a good background in ST ones, and so in Cortex M chips.

I seems that the debugger does something needed by the release binary, but I don't know what.

• I tried several things:
•  flashing at different adress (0x00000000)
• playing with boot modes
• using my own linker files - used for ST Cortex M4 chips (adapted for imx chip addresses)
• using exactly the same cflags/asmflasg/ldflags as the cmake example
• reduce built files to a minimum needed (with minor changes to enable build):
  • boards/evkmimxrt1060/demo_apps/led_blinky/board.c
  • boards/evkmimxrt1060/demo_apps/led_blinky/clock_config.c
  • boards/evkmimxrt1060/demo_apps/led_blinky/pin_mux.c
  • boards/evkmimxrt1060/demo_apps/led_blinky/led_blinky.c
  • devices/MIMXRT1062/drivers/fsl_gpio.c
  • devices/MIMXRT1062/drivers/fsl_clock.c
  • devices/MIMXRT1062/system_MIMXRT1062.c
• using the same flags I used for building M4 chips (adapted flags regarding M core)

In each case, the debug session runs fine, but flashing release binary with segger tool does not.

I am a bit lost...

Attached flags I am currently using (which I use with success on other Cortex M projects)

I am currently using MIMXRT1062xxxxx_flexspi_nor.ld as linker file (as MIMXRT1062xxxxx_ram.ld does not work in any case, even building using provided cmake scripts)

Help appreciated !

Thanks,
Camille

[jeremyzhou]

Hi Camille Louapre,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
Whether you can list the steps of programming the release version of binary via using the Segger tool in detail, as I'd like to replicate the phenomenon as you describe.
Looking forward to your reply.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[camillelouapre]

Hello jeremyzhou,

I am using JLink tools V6.52b, an I am on Linux Mint.

Here are described steps for flash programming the release binary:

• Open JFlashLiteExe (GUI)
• Select device MIMXRT1062XXX6A
• Select SWD, 4000kHz
• Erase chip
• Set prog address 0x60000000
• Select binary browsing folders
• Click "Program device"
• Reset EVK with SW9 button

You will find attached built binaries/map files for debug/release.

Maybe an hardware/jumper/switch setting ? I did not find any clear information about jumpers (except hardware design).

Thanks for your help,

Camille

[jeremyzhou]

Hi Camille Louapre,

Thanks for your reply.
I've programmed the release version of PCK_BRD_MINUS.bin to the MIMXRT1060 as the Fig 1 shows, it seems to program successfully, however it doesn't work actually.
I also try to program the release version of hello_world.bin which is the demo project from the SDK library, it can work well.

Fig 1

So I think the issue is not related to the hardware.
Comparing the size of debug and release version of the PCK_BRD_MINUS.bin, the release version is almost 6 KB smaller versus the debug version, it seems a bit weird, for the SDK library's demo project, they are almost as big as each other.
So I'd like to suggest you check it.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[camillelouapre]

Hello,

Thanks for your response, and sorry for my late answer, I was off for several days.

I also think that it is not related to the hardware.

But debug/release builds from sdk example are not equivalent in code size. For example building led_blinky results in 17.9ko in debug and 8ko in release (after executing arm-none-eabi-objcopy -O binary iled_blinky.elf iled_blinky.bin - to convert elf to bin).

I found that in the release map file there are missing references to a lot of libnano/libnosys.a objects, comparing to the debug map file. But maybe this is normal ?

The strange thing is that lauching a release build in a debug session works fine. It seems that the debugger is performing some initialization that the bin file does not.

Thanks for your help

Camille

[jeremyzhou]

Hi Camille Louapre,

Thanks for your reply.
1) But maybe this is normal?
-- Actually, It's hard to judge that it's normal or not, however, it's 100% certain the release bin is smaller.
According to your reply, I consider the issue is related to the IDE, the release bin maybe lacks initialization functions for the boot-up process.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[camillelouapre]

Hello,

Thanks for your reply.

I don't use any IDE (except when I debug - eclipse or mcuxpresso are working fine), I use simple gcc command line calls in a makefile, and I use Segger JFlashLite for flash programming.

I also think that something is missing in the boot process, but I am using the default SDK linker file and default startup file.

I tried to made several modifications on both, with no effect (I am not really familiar with these files...)

Nobody else got that problem ?

Thanks

Camille

[jeremyzhou]

Hi Camille Louapre,

Thanks for your reply.

In my experience, I'd like to suggest you pay attention to comparing the map files between the release and debug, it may give an insight into this issue.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------