- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- open up the i2c_boot project and configure the bootloader component as "single application".
- Then generate the .hex there
- come back to the main app project
- edit it's bootloadable component and in the second tab, point to the newly generated bootloader .hex file.
- rename cm0g_1.ld at the project root directory to cm0gcc.ld
- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- new "blank" CYPD3125 chip. Pre-programmed with the bootloader. We need to program our single app there
- 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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- open up the i2c_boot project and configure the bootloader component as "single application".
- Then generate the .hex there
- come back to the main app project
- edit it's bootloadable component and in the second tab, point to the newly generated bootloader .hex file.
- rename cm0g_1.ld at the project root directory to cm0gcc.ld
- 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.