EM_EEPROM and IPC Module Interference

[StNu_1610991]

We are using the CYBLE-416045-02 module in a doppler radar speed collection
module that sends traffic speed data to a server.  We have a half dozen
units in the field for testing and the system is running very well.

An external FRAM is being used for parameter and system state saving during
processor hibernation.  For system reliability we want to also save the
parameters in PSoC 6 flash using the EEPROM V2.20 component.  Creator 4.4
is being used for development.

The "Em_EEPROM" component was first configured with 1024 bytes, redundant copy,
blocking write and no wear leveling.  Auxiliary audits were added to see the
results of the writes and reads on the EEPROM.  At first nothing went through;
even the initialization returned a CY_EM_EEPROM_WRITE_FAIL.  After
various trials with the configuration, a number of writes and reads
went through with no redundant copy and non-blocking writes.  After more
experimenting, I could not even get that case to work any more.

Also, when the EEPROM component is active none of the ipc functions which are
used to communicate between CM0p and CM4 were working any more.
So, the EEPROM component must be interfering with the ipc operation.

To check this further, a compiler conditional variable was added to
be able to comment out the new EEPROM interface code.  When
the EEPROM was allowed to be compiled in,  the system did not
work.  When it was not, the system worked as well as before starting
to add the EEPROM.

So, the problem is what should I be doing to prevent this interference.
The documentation for EEPROM does not say anything about such
interaction and I do not know what internal chip resources the
EEPROM is using that might be colliding with those used by ipc.
This should not have to be known to the user.

Also, the documentation for the EEPROM component is much too sparse.
For example, writes can be in non-blocking mode.  Normally when
this is provided, there is a way of starting the operation and a
way of checking when the operation is done.  There is no information
about this in the EEPROM documentation.

A second example is the return codes.  Sure, they are defined.  But,
what the user needs to know is why did a write error appear and
what should be done to fix it.

The only EEPROM calls used in the interface are the following:

  fnvm__status= Em_EEPROM_Init(0);      // address not used in PSoC 6

      fnvm__status= Em_EEPROM_Write((U4)ind,(V *)vUP,(U4)nb_used);

      fnvm__status= Em_EEPROM_Read((U4)ind,(V *)dUP,(U4)nb_used);


The following are the ipc calls used in the CM0p and CM4 processors:

CM0p:

  Cy_IPC_Pipe_RegisterCallback(         // Register the Message Callback
                   CY_IPC_EP_CYPIPE_ADDR
                , ipcCB_cm0p_rx_msg
                , CY_IPC_EP_CYPIPE_CM4_ADDR
                );   



  Cy_IPC_Pipe_SendMessage(
                            CY_IPC_EP_CYPIPE_CM4_ADDR
                        , CY_IPC_EP_CYPIPE_CM0_ADDR
                        , (void *) &ipc0__ipc_msg
                        , ipcCB_cm0p_tx_release
                        );


CM4:

  Cy_IPC_Pipe_RegisterCallback(         // Register the Message Callback
                   CY_IPC_EP_CYPIPE_ADDR
                , ipcCB_cm4_rx_msg
                , IPC_CM0_TO_CM4_CLIENT_ID
                );   


  Cy_IPC_Pipe_SendMessage(
                            CY_IPC_EP_CYPIPE_CM0_ADDR
                        , CY_IPC_EP_CYPIPE_CM4_ADDR
                        , (void *) &ipc4__ipc_msgT
                        , ipcCB_tx_release
                        );

[Ekta_N]

Hi @StNu_1610991 

The "Em_EEPROM" component was first configured with 1024 bytes, redundant copy,
blocking write and no wear leveling.  Auxiliary audits were added to see the
results of the writes and reads on the EEPROM.  At first nothing went through;
even the initialization returned a CY_EM_EEPROM_WRITE_FAIL.  After
various trials with the configuration, a number of writes and reads
went through with no redundant copy and non-blocking writes.  After more
experimenting, I could not even get that case to work any more

For general EM_EEPROM configuration, you can refer to the already existing code example that we have for Emulated EEPROM. You can try directly using the code example to see if it works correctly for you. You can find the code example at the following link: CE195313 – PSoC Emulated EEPROM

So, the problem is what should I be doing to prevent this interference.
The documentation for EEPROM does not say anything about such
interaction and I do not know what internal chip resources the
EEPROM is using that might be colliding with those used by ipc.
This should not have to be known to the user.

The EEPROM Middleware used for Flash reads and writes operates on the top of the flash driver included in the Peripheral Driver Library (mtb-pdl-cat1 or mtb-pdl-cat2). You can read about the constraints for Flash operations at the PDL API Reference Guide. 

The EEPROM Middleware Library also mentions a list of restrictions. Make sure you follow the points mentioned on this page.

Flash operations are implemented as system calls. System calls are executed out of SROM in the privileged mode of operation. Users have no access to read or modify the SROM code. The driver API requests the system call by acquiring the Inter-processor communication (IPC) and writing the SROM function opcode and parameters to its input registers. As a result, an NMI interrupt is invoked and the requested SROM function is executed. The operation status is returned to the driver context and a release interrupt is triggered.

If you want to get more details on how the Flash memory programming actually works, you can refer to section 13.2 from the PSoC 6 Architecture TRM.

In case you face issues even after following the above guidelines can you please attach your project? 

Best Regards
Ekta

[StNu_1610991]

Hi Ekta:

Thanks for your response.  I looked up some of what you suggested but have not found any solution.

Remember:  

1.  All that is needed is a simple write of an array to Em_EEPROM and a read.  With the current code in the project this does work occasionally.  What I don't understand is why the WRITE_FAIL responses, even from the _init function.

2. The IPC functions used in the project have been working well with no problems.  Why would the addition of the Em_EEPROM functions cause a problem?  They should be protected from other IPC uses.

I will look further into IPC constraints, but feel that I really should not have to do that;  I am simply a user and do not want to become an expert in the PSOC or the PDL library.

I will also look at work-arounds since we do need the non-volatility of the em_EEPROM in our system.

Steve

[StNu_1610991 · Accepted solution]

Still have not found a solution with Em_EEPROM.  So, a workaround using FRAM has been implemented and it is adequate for the project.