PSoC™ 6

The attached workspace bundle contains two projects:  a bootloader minimally modified from CE216767, Bootloader_DevKit, and a very simple bootloadable, App_Stub_DevKit.  I'm operating with PSoC Creator 4.2, PDL 3.1.4 (though 3.1.0 has the same issue), and the CYBLE-416045-EVAL dev kit.

The release build of the App Stub builds the App Stub against the bootloader's linker command files making it a standalone application in slot 0.  Flash that into the part and it runs.  The green LED on the dev kit is being operated by the M4 core and the red LED is being operated by the M0+ core at a different rate.

Fine so far.

Build the debug build of the bootloader and flash it into the part.  The LED blinks white as it should.

Build the debug built of the App Stub.  This is built against the App Stub's own linker command files which put it in slot 1.  That build also creates the .cyacd2 file.

Use CySmart to load the App Stub .cyacd2 file via the bootloader.  CySmart says it loads fine.  The LEDs don't blink.

Problem:  the application doesn't run.

Go into the App Stub's clock configuration and source Clk_HF0 from path 0 instead of path 1.  Change nothing else.  Rebuild the App Stub.

Reflash the bootloader into the board to destroy the broken App Stub.  Note that I have disabled the button functionality of the bootloader since my real hardware doesn't have a usable button.

Use CySmart to load the rebuilt App Stub into the board.  CySmart says it loads fine.  The LEDs blink correctly.

For some reason, when the App Stub is in slot 0, the PLL clock works.  When it's in slot 1, the PLL clock fails.  Switching the App Stub to the FLL clock enables the App Stub to run in slot 1.

Help, please!

Hi,

while porting WHD, I have similar question as https://community.infineon.com/t5/Wi-Fi-Combo/Support-for-porting-WHD-to-stm32F7/m-p/212755 .

1. However this question seems not answered fully. So, please let us know it.

2. & I assume the port specific type can be something like below -

e.g. 

i am trying to carry out clock glitching with the new target board PSoC 62 with Chip Whisperer pro kit. but am not able to. after making changes in the code there is not effective changes seen, the results are the same. 

attached is the file with changes made please help me out what am i missing are doing wrong?

Hi.

I'm trying to put my device to deep sleep using a 16 bit WDT (Counter0) . I'm able to put the device to deep sleep for 4ms.

1. However, when I try to increase the time to 30s by using a for loop, the device isn't going to deep sleep (current ~ 2mA). 

2. Even when I use a 32 bit WDT ( Counter2), I get a current of about 2mA.

Can someone help me out with the code of putting the device to deep sleep for long intervals like 1-2 minutes and then wake up the device. 

Thanks!

Hi ,

I have one question Is there any method to check if the device is returned from Backup Domain. I am working on device in which Backup domain is required for time tracking and other implementations.

I have looked into Technical Reference Manual Section for Backup Systems and Power Supply where I found VDDBAK_CTL for switching the Power rail between VDDD and VDDBAK.

I also looked into Registers Technical Reference Manual for Backup System Registers BACKUP_STATUS But it only tells the status of WCO and RTC_Busy not if system is returned from BACKUP domain

I also tried to look into Pdl reference manual no API found that could help me.

Kindly help me with the situation

PSoC Creater 4.4 will program my CY8KIT-059.
However, Programmer 4.00 will not recognize the device.
However, Programmer will detect my CY8KIT-147.
What must I do to get Programmer to detect the CY8KIT-059 ?

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
                        );