Colibri IMX7D bare metal M4 initialize memory

Technical Support
, , , ,
1

I have a simple C program developed in Eclipse for M4 running in TCM_L RAM with a small initalized array.
If I print with the PRINTF() function the array elements the result is different from what I set in the initialization.

On the A7 CPU I have Linux 4.9.166-2.8.6+gd899927728be #1 SMP, loading the program from Linux via imx-m4fwloader

2

Hi @bzzpaolo

Could you provide the version of the Hardware (including Carrier Board) and Software of your module?

Could you share an example code with all the needed files to reproduce the error?
Did you already have a look here?

Best regards,
Jaski

3

Working to verify the previous problem, I realized (os: Windows 10 - Eclipse 2019-09) the example “GPIO example using Eclipse” and running Build “Release” produced two files, gpio_demo.elf and gpio_demo. bin, this one of size 524kB, impossible to load with the program imx-m4fwloader.
In addition, the compilation displays:

Invoking: GNU ARM Cross Create Flash Image'.
arm-none-eabi-objcopy -O binary "gpio_demo.elf" "gpio_demo.bin" "gpio_demo.bin"
Finished building: gpio_demo.bin'.
' '
Invoking: GNU ARM Cross Print Size
arm-none-eabi-size --format=berkeley "gpio_demo.elf"
   text data bss dec hex filename
  10588 200 2112 12900 3264 gpio_demo.elf
Finished building: gpio_demo.siz

how to get the correct size of the gpio_demo.bin file?

Thanks for the help. Kind regards.

4

Good morning,

I did some tests on the problem of initialization of variables in the Cortex-M4 environment.
I ran the tests in parallel on an Aster V1.1B platform with Colibri iMX7D 1GB V1.1A module and our TF-RP21 platform.

I attach the project in Eclipse TF-RP21_M4B.zip. I tried 3 linker files,

  • the first MCIMX7_M4_tcm.ld creates a 524MB bin file, not usable, and a 240KB elf file that runs with U-boot works correctly.
  • The file MCIMX7D_M4_tcm_bin.ld creates a 65KB bin file that cannot be loaded with imx-m4fwloader, and if you run the elf file from U-boot it stops the execution of U-boot by looping it.
  • the third MCIMX7D_M4_tcm_bin_ok.ld creates a 9KB bin file that only works by running it with imx-m4fwloader but the values of the variables are overwritten.

I would be grateful if you give me some indication to solve this problem.

  • OS: Linux Colibri-imx7-emmc 4.9…166-2.8.6
  • Toolchain: GNU Tools ARM Embedded 5.4 2016q3
  • Eclipse 2019-09

Best regards

5

Dear @bzzpaolo

.bin files don’t contain any address information, and represent one contiguous range of memory. This means:

  • if your application consists of 1 byte at address 0x00000000 and 1 byte at address 0x00100000, your .bin file is 1MB in size.
  • .bin files don’t contain any information about the proper location of the code, it is the responsibility of the loader to load the .bin contents to the proper memory location.

.elf files cover both of these problems, because

  • it contains a file header which allows to have multiple code sections: So in the example above the elf file would be 2 bytes + file-header-overhead.
  • Each section also contains the start address.

Conclusion: Use the .elf file, even if the intermediate .bin file is huge.

Regards, Andy

6

dear Andy,
your answer is correct and clear, but my problem is understanding why the third linker file example (MCIMX7D_M4_tcm_bin_ok.ld) doesn’t work correctly (i.e. the initial value of the variables).
So I would need information on where to find the user manual on the syntax and structure of link files for Cortex-M4, also in view of the need to extend the firmware beyond TCL RAM, i.e. OCRAM or DDR RAM. Moreover there is a loader like imx7-m4fwloader that also accepts the elf format?
I apologize for my English, but it is all the fault of DeepL.
Best regards, Paolo

7

Dear @bzzpaolo

The linker is a regular GNU linker. Documentation can be found in various places, for example here:

I never used any other method, so I’m not aware whether there is a Linux utility to load M4 code. If there is none, there are a number of .elf parsing libraries around. Probably it is not too complex to combine such a library with the m4fwloader to add support for .elf files.

Regards,
Andy