How-to create a single firmware build of a CCGx Host SDK v3.2.1 example project?

Announcements

Live Webinar: USB-C adoption. Simple & Cost-efficient solutions | April 18th @9am or 5pm CEST. Register now !

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
jeda_3234496
Level 1
Level 1
First like given

I am constantly running out of space because I am linking the static pd lib which is pretty big.

ERROR: address 0x213c2 of Z:\devel\myproject-pd.cydsn\CortexM0\ARM_GCC_541\Debug\myproject-pd_2.elf section `.text' is not within region `rom'

ERROR: Z:\devel\myproject-pd.cydsn\CortexM0\ARM_GCC_541\Debug\myproject-pd_2.elf section `.eh_frame' will not fit in region `rom'

ERROR: address 0x213c2 of Z:\devel\myproject-pd.cydsn\CortexM0\ARM_GCC_541\Debug\myproject-pd_2.elf section `.text' is not within region `rom'

ERROR: address 0x213c2 of Z:\devel\myproject-pd.cydsn\CortexM0\ARM_GCC_541\Debug\myproject-pd_2.elf section `.text' is not within region `rom'

ERROR: section .cyloadablemeta loaded at [0001ff40,0001ff7f] overlaps section .text loaded at [00010a80,000213c1]

ERROR: region `rom' overflowed by -128 bytes

We don't need the second firmware. To update, we're confident we can simply reboot the chip in boot mode, then perform the upgrade of the FW1 only using i2c.

I looked for a way to do this in the linker scripts (cm0g_2.ld) but I am no expert there and have not found anything I amconfident will work correctly and durably.

Any pointers or ideas welcome!

0 Likes
1 Solution

Ok, so to answer myself... very bad come back from cypress here.

Normally, and from the example project, the main app project contains a bootloadable component which considers from it's configuration, the .hex of a bootloader project (a project containing the bootloader component in its topdesign.) Through some black magic (tcl code in the component source dir), the bootloadable component analyzes this .hex to figure out if it is expected to be loaded by a dual or single app bootloader. As such, it will either generate a single linker script, or two linker scripts which places the first and second apps and metadata tables at the appropriates locations in flash.

The example projects contain a "noboot.cydsn" and "i2c_boot.cydsn" sub-projects. The key is to:

  1. open up the i2c_boot project and configure the bootloader component as "single application".
  2. Then generate the .hex there
  3. come back to the main app project
  4. edit it's bootloadable component and in the second tab, point to the newly generated bootloader .hex file.
  5. rename cm0g_1.ld at the project root directory to cm0gcc.ld
  6. edit the number of APPS at the top of the files (this part may be optional)

I am now able to program this single firmware using the dual-app bootloader.

View solution in original post

0 Likes
3 Replies
ShifangZ_26
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 1000 replies posted

Hi ,

May I know whether your question is based on CCG3 CYPD3125 or CCG4 CYPD4xxx notebook example code based on CCGx Host SDK V3.2.1?

As you many know that CCG5 is using asymmetry image for firmware (Primary firmware and secondary Firmware).

Best Regards,

Lisa

I am using the CCG3 CYPD3125 notebook example on v3.2.1.

We are designing so that we can program our firmware using i2c (HPI). We need to support 2 scenarios:

  1. new "blank" CYPD3125 chip. Pre-programmed with the bootloader. We need to program our single app there
  2. An already programmed CYPD3125. We trigger the firmware to reboot and stay in boot mode so we can reprogram the app.

Thanks for your help!

0 Likes

Ok, so to answer myself... very bad come back from cypress here.

Normally, and from the example project, the main app project contains a bootloadable component which considers from it's configuration, the .hex of a bootloader project (a project containing the bootloader component in its topdesign.) Through some black magic (tcl code in the component source dir), the bootloadable component analyzes this .hex to figure out if it is expected to be loaded by a dual or single app bootloader. As such, it will either generate a single linker script, or two linker scripts which places the first and second apps and metadata tables at the appropriates locations in flash.

The example projects contain a "noboot.cydsn" and "i2c_boot.cydsn" sub-projects. The key is to:

  1. open up the i2c_boot project and configure the bootloader component as "single application".
  2. Then generate the .hex there
  3. come back to the main app project
  4. edit it's bootloadable component and in the second tab, point to the newly generated bootloader .hex file.
  5. rename cm0g_1.ld at the project root directory to cm0gcc.ld
  6. edit the number of APPS at the top of the files (this part may be optional)

I am now able to program this single firmware using the dual-app bootloader.

0 Likes