Bootloader and emulated eeprom do not work together pretty good. When you update your flash by writing new data into it, the checksum will change. This indicates the bootloader that the project is broken and has to be re-programmed.
At first: Update Creator to latest version 3.3 CP3 and update your components.
Have a look at the memory map of the bootloadable/bootloader component (datasheet).
You need to put your flash array right below the metadata and specify the size (or a bit more) to exclude from building the checksum.
Putting a variable into flash at a fixed address is described here.
Thank you to Reiner and Bob, I can't seem to get clean compile after change to .ld
Bob, I worked thru each step. I have 3.3 and changed to new version of both bootloader and bootloadable component. Moved my var above main to make global. Then copied .ld file and renamed it to My_cm0gcc.ld and made build linker settings point to this new file. However, when I go change the .ld file I get compile error.."collect2.exe: error: ld returned 1 exit status
The command 'arm-none-eabi-gcc.exe' failed with exit code '1'."
At one point I was getting the compile error ----> files were modified outside of psoc creator..no changes have been made check files.
Not sure what that meant but can you make advisement what I did wrong on my .ld file. Comments at top of main.c lists changes to .ld MEMORY and SECTIONS commands.
To recap, my goal is to simply place My_eepromArray and other var's like FOO at top of flash where I can disable chksum calculations and allow bootloader & loadable to work correctly. See attached bundle.
I would follow a different approach that is compiler independent.
There are a lot of macros cypress provides as the size of a flash row and the number of flash rows available.
The bootloader memory map shows that the upper two flash rows are used for metadata. The flash area below is free and below that resides the bootloadable project.
So with the Macros you can calculate the address of the memory area below the metatdata. you can use the flash APIs to program those rows which will work for PSoC devices that do not support emulated eeprom.
When you define a structure that contains all your data you want to keep in flash you can assign a pointer to it the value of the first free flash row. When reading, you use the pointer to the struct, when programming you need a copy of the (modified) struct in sram.
Very well. If I understand correctly then, I need to move away from the emulated eeprom component and go directly to flash APIs ?
Can you direct me to a link that helps with flash APIs as you describe. The prior bundle was an eeprom testbed and I would like to get eerpom emulation (whether with a component) or with direct APIs functional, before I go back to my main project.
The flash APIs are documented in the "System Reference Guide" from Creator -> Help menu.
I had the same issue. Your link was helpful.
To be more accurate the "Fast bootloadable application validation" solution DID NOT work.
However, setting aside the EEPROM memory in the Bootloadable module and declaring the EEPROM data in the CY_SECTION(".cy_checksum_exclude”") worked!