You are here

Problem using EM_EEPROM with BOOTLOADER and Cy8ckit_049 | Cypress Semiconductor

Problem using EM_EEPROM with BOOTLOADER and Cy8ckit_049

Summary: 7 Replies, Latest post by lpoma on 18 May 2017 06:23 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
R.Thomas's picture
User
21 posts

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.

user_1377889's picture
User
10686 posts

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

repsoc's picture
User
23 posts
user_119654's picture
User
3 posts

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!

R.Thomas's picture
User
21 posts

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.

 

 

user_1377889's picture
User
10686 posts

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

R.Thomas's picture
User
21 posts

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.
 

user_1377889's picture
User
10686 posts

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

 

Bob

Log in to post new comments.