Problem using EM_EEPROM with BOOTLOADER and Cy8ckit_049

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I have a major problem with a design in which I am trying to use the example EM_EEPROM component from the pioneer kit to store a few strings in flash on a Cy8ckit-049 platform.  I ported the the quite simple EM_EEPROM example project from the pioneer over to the 049 and intergrated with the 049 bootloadable blinking led project.

   

The problem is if I don't REMARK OUT -->status = Em_EEPROM_1_Write(array,eepromArray,14u);  , the app breaks.

   

Normally the 049 runs the BOOTLOADER at power-up.  If the switch is not pressed within a short time, control passes to the other project (the main bootloadable app).  The problem that occurs is as long as we leave the above listed WRITE active the 2nd boot-up causes the BOOTLOADER to always go active, ie flash and wait for bootloaderhost to start bootload sequence and we can never pass control to the main bootloadable app.

   

Ie, on first boot, the above EM_EEPROM write occurs and modifies flash string, but then on 2nd boot we stick in the bootloader from that time forward on all boots. 

   

It's like some mechanism is noticing that the cksum has changed and then forces the control to somehow stay in the bootloader. 

   

If you can imagine what is happening here I would greatly appreciated it.

   

I have also attached the creator 3.3 bundle with notes at the top of the main.c describing the recreated problem.

0 Likes
9 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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.

   

Way out:

   

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.

   

 

   

Bob

0 Likes
Anonymous
Not applicable
0 Likes

Reiner,

   

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!

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

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.
 

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

The flash APIs are documented in the "System Reference Guide" from Creator -> Help menu.

   

 

   

Bob

0 Likes
MiDu_3979751
Level 1
Level 1
First like received

FYI for anyone who may see this and wants to use the emulated EEPROM component with Bootloadable/Bootloader components

All you have to do is

1. check the size of your emulated EEPROM in the component settings view (the actual size, not the requested size if you are using write protection)

2. Go to your Bootloadable component and enter the actual Emulated EEPROM size you just looked up in the "Checksum exclude section size (bytes)".

3. Wherever in your code you reserve the memory for the emulated EEPROM, add CY_SECTION(".cy_checksum_exclude").

In my code the full line looks like:

const uint8_t emEeprom[EEPROM_PHYSICAL_SIZE] CY_SECTION(".cy_checksum_exclude") __ALIGNED(CY_FLASH_SIZEOF_ROW) = {0u};

I spent quite a few hours trying to track down the same issue using emulated EEPROM with bootloader - including various changes to customised linker files etc etc. All not required! reserving the space in checksum excluded flash  and mapping the EMU EEPROM storage array to this space fixed it: Thanks.

The only additional step I had to make (which was a remnant of previous attempts in trying to get the emulated EEPROM to work ) was to revert the project build settings back from using a custom linker file. No customisation of the linker config is required for the above to work.

0 Likes