PSoC6 & PDL em_EEPROM does not retain data on reset.

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

cross mob
HaIn_1319421
Level 1
Level 1
First like received First reply posted First question asked

The whole point of using EEPROM is to retain configuration data after power-down or reset.

PSoC5 with it's dedicated EEPROM does this perfectly,  while the emulated EEPROM proided through PDL is useless.

I have tried every "soultion" suggested in your Forum and Knowledge Base, but nothing works: The em_EEPROM is ALWAYS erased after reset or when debugging. To add insult to injury, the documentation for both PDL and em_EEPROM Middleware is abysmal! For example, defining EEPROM size as 256 bytes only provides 128 bytes of storage (easy to fix, but not clearly mentioned in the documentation).

Is there a REAL solution available to this EEPROM erase problem?

1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Halfdan,

I'm glad to see you identified the major root cause of your EEPROM retention issue.

About the EEPROM size ...  I found this in the component datasheet.

Len_CONSULTRON_0-1646745929900.png

I hope this helps.   In general, when you define the application's EEPROM size, it adds some overhead info.  EEPROM sizes above the 512 byte row size are bumped up to add the next row (+512 bytes).  Apparently the minimum size for the PSoC6 is 256 bytes.

You wrote:

"One issue remains, however: The em_EEPROM data is erased whenever I load a
program to Debug from PSoC Creator. This is a major pain when debugging!

Is there a way to prevent the debugger from erasing the em_EEPROM flash
area?"

The short answer:  No.

The Em_EEPROM is actually in FLASH.   When you program a PSoC you first command it to ERASE ALL FLASH.

This will clear any value you may have saved in Em_EEPROM.

Now there are three known ways around this issue ... kind of.

Method #1

You can detect if the EEPROM has "zero" writes.  This occurs when the FLASH is erased during a programming cycle.   This is because the "wear-leveling" counter is  reset to '0'.

By detecting this you can load default EEPROM values of your choosing.  I do this in my apps to preset the EEPROM to known values and in my app's case known running profiles.

Method #2

If Method #1 is not viable to you, then you can follow these steps:

  • Program (not debug) the PSoC and get it running.
  • Get it into the mode where you suspect something went wrong or the EEPROM values may be suspect.
  • Select the "Debug/Attach to Running Target..." menu command.
    Len_CONSULTRON_2-1646747284257.png

     

  • On the PSoC6 it will ask which processor to use,  Chances are your application code is running on the CM4.
    Len_CONSULTRON_1-1646747236603.png
  • If the "Halt target on attach" was checked, the IDE will show the location of the running code. 
  • If not, you can Pause it manually or find the location in code that you want a breakpoint and set it.  It should stop once (and if) it encounters the breakpoint.
  • You can now run the debugger without resetting the EEPROM values because you didn't force a reprogramming by using the "Debug/Debug" menu function.
  • Additionally if you want restart the code at main() by using the "Reset" icon. Len_CONSULTRON_3-1646747688140.png

     

Method #3

This method is very much like Method #2 except it engages the debugging interface and resets the CPU to main() and waits for your next command.  

  • Select the "Debug/Debug without Programming" menu command.
    Len_CONSULTRON_4-1646747872753.png

    Because you didn't reprogram the PSoC6, the EEPROM values remain.

You wrote:

"PS. I do not know if you can answer this, but there is a major hardware
problem with the CY8CPROTO-063-BLE board (I have tried several units):

The P5_0 & and P5_1 pins are auto-assigned to the first UART used, but the
P5_0 \UART:rx\ input pin seems to be so severely clamped HIGH that any
serial device connected to it only manages to pull it down by more than a
few millivolts. The rx input is useless.

Do you happen to know the cause and a solution to this?"

I have 4 of these CY8CPROTO-063-BLE boards and have used them on many projects.  When I use them with the UART (which is almost always), they work just fine.   Mind you, I'm using them with the KitProg UART interface.

Are you using the P5.0 pin with the KitProg board still attached?   If so, the reason this pin is "hard-driven" is that the KitProg board believes it has 100% control of this pin on the PSoC-side.   In a UART protocol, the pin with no communication is driven high.

If this is the case in your situation there is two suggestions:

  1. Break off the KitPRog board.   The downside is losing the UART comm interface to your PC host AND making reprogramming of the target PSoC6 much more complicated.
  2. Use a different UART and UART GPIO pins not being used by the KitProg board.   This is your safest solution while preserving functionality with the PC host.
Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

0 Likes
4 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Haln,

I have a few projects using the Em_EEPROM on PSoC6 projects.   It is working very well for me.  I can read EEPROM settings and write when needed.  The settings are preserved through any reset including a power-up.

The easiest way to help you out is to request that you share your project with this forum.  This will allow participants to review your Em_EEPROM code and possibly reproduce the issues you are seeing.

If you can't share the entire code with the community, you can make a copy of the project and simply the code to show your Em_EEPROM code.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi @HaIn_1319421 ,

Can you please let me know the PSoC 6 device or EVK that you are using to develop your firmware?

Have you also had a chance to try out the Em_EEPROM code example that is provided in ModusToolbox?

AlenAn14_0-1646674474116.png

I found this example to be very well detailed in describing how to use the emulated EEPROM in PSoC 6 devices.

If you are still facing issues for the data retention using emulated EEPROM, please share your project or a sample of the same here as @Len_CONSULTRON  has mentioned so we can help you better.

Warm Regards
Alen

0 Likes
Hi Alen, thanks for your prompt reply.

I am using the CY8CPROTO-063-BLE in my project. I am using PSoC Creator 4.4,
and have yet to try the ModusToolbox.



I initially tested the PSoC_EmEEPROM_PSoC6 code example from your "Find
Code Example" site and it works (after a fashion).

By re-visiting it (and confirming it works), I compared my emEEPROM
initialization to the example I found the reason for a part of my problem:

I use the autogenerated em_EEPROM_Init(startaddress) function in
Em_EEPROM.c, and I found that during my "try everything" frustrated stage I
hadset the "Use Emulated EEPROM" parameter to "No".

I happened to use startaddress = 0, which explains my problem. I reversed
this, and now the EEPROM retains data through both reset and powerdown.



I need to store less than 256 bytes of configuration data so I defined the
"EEPROM Size" parameter as 256. I eventually found out that only about 128
bytes of data could actually be stored.

This was easily fixed by defining the size as 512, but there is either a bug
in the Em_EEPROM Middleware Library or scant documentation.



One issue remains, however: The em_EEPROM data is erased whenever I load a
program to Debug from PSoC Creator. This is a major pain when debugging!

Is there a way to prevent the debugger from erasing the em_EEPROM flash
area?



Best regards

Halfdan Ingolfsson

Iceland



PS. I do not know if you can answer this, but there is a major hardware
problem with the CY8CPROTO-063-BLE board (I have tried several units):

The P5_0 & and P5_1 pins are auto-assigned to the first UART used, but the
P5_0 \UART:rx\ input pin seems to be so severely clamped HIGH that any
serial device connected to it only manages to pull it down by more than a
few millivolts. The rx input is useless.

Do you happen to know the cause and a solution to this?
0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Halfdan,

I'm glad to see you identified the major root cause of your EEPROM retention issue.

About the EEPROM size ...  I found this in the component datasheet.

Len_CONSULTRON_0-1646745929900.png

I hope this helps.   In general, when you define the application's EEPROM size, it adds some overhead info.  EEPROM sizes above the 512 byte row size are bumped up to add the next row (+512 bytes).  Apparently the minimum size for the PSoC6 is 256 bytes.

You wrote:

"One issue remains, however: The em_EEPROM data is erased whenever I load a
program to Debug from PSoC Creator. This is a major pain when debugging!

Is there a way to prevent the debugger from erasing the em_EEPROM flash
area?"

The short answer:  No.

The Em_EEPROM is actually in FLASH.   When you program a PSoC you first command it to ERASE ALL FLASH.

This will clear any value you may have saved in Em_EEPROM.

Now there are three known ways around this issue ... kind of.

Method #1

You can detect if the EEPROM has "zero" writes.  This occurs when the FLASH is erased during a programming cycle.   This is because the "wear-leveling" counter is  reset to '0'.

By detecting this you can load default EEPROM values of your choosing.  I do this in my apps to preset the EEPROM to known values and in my app's case known running profiles.

Method #2

If Method #1 is not viable to you, then you can follow these steps:

  • Program (not debug) the PSoC and get it running.
  • Get it into the mode where you suspect something went wrong or the EEPROM values may be suspect.
  • Select the "Debug/Attach to Running Target..." menu command.
    Len_CONSULTRON_2-1646747284257.png

     

  • On the PSoC6 it will ask which processor to use,  Chances are your application code is running on the CM4.
    Len_CONSULTRON_1-1646747236603.png
  • If the "Halt target on attach" was checked, the IDE will show the location of the running code. 
  • If not, you can Pause it manually or find the location in code that you want a breakpoint and set it.  It should stop once (and if) it encounters the breakpoint.
  • You can now run the debugger without resetting the EEPROM values because you didn't force a reprogramming by using the "Debug/Debug" menu function.
  • Additionally if you want restart the code at main() by using the "Reset" icon. Len_CONSULTRON_3-1646747688140.png

     

Method #3

This method is very much like Method #2 except it engages the debugging interface and resets the CPU to main() and waits for your next command.  

  • Select the "Debug/Debug without Programming" menu command.
    Len_CONSULTRON_4-1646747872753.png

    Because you didn't reprogram the PSoC6, the EEPROM values remain.

You wrote:

"PS. I do not know if you can answer this, but there is a major hardware
problem with the CY8CPROTO-063-BLE board (I have tried several units):

The P5_0 & and P5_1 pins are auto-assigned to the first UART used, but the
P5_0 \UART:rx\ input pin seems to be so severely clamped HIGH that any
serial device connected to it only manages to pull it down by more than a
few millivolts. The rx input is useless.

Do you happen to know the cause and a solution to this?"

I have 4 of these CY8CPROTO-063-BLE boards and have used them on many projects.  When I use them with the UART (which is almost always), they work just fine.   Mind you, I'm using them with the KitProg UART interface.

Are you using the P5.0 pin with the KitProg board still attached?   If so, the reason this pin is "hard-driven" is that the KitProg board believes it has 100% control of this pin on the PSoC-side.   In a UART protocol, the pin with no communication is driven high.

If this is the case in your situation there is two suggestions:

  1. Break off the KitPRog board.   The downside is losing the UART comm interface to your PC host AND making reprogramming of the target PSoC6 much more complicated.
  2. Use a different UART and UART GPIO pins not being used by the KitProg board.   This is your safest solution while preserving functionality with the PC host.
Len
"Engineering is an Art. The Art of Compromise."
0 Likes