PSoC™ 5, 3 & 1 Forum Discussions

Looking into the generated code for the EEPROM component, I see this:

cystatus EEPROM_1_Write(const uint8 * rowData, uint8 rowNumber) 
{
    cystatus status;
    
    CySpcStart();

    if(rowNumber < (uint8) CY_EEPROM_NUMBER_ROWS)
    {
        /* See if we can get SPC. */
        if(CySpcLock() == CYRET_SUCCESS)
        {
            /* Plan for failure */
            status = CYRET_UNKNOWN;

            /* Command to load a row of data */
            if(CySpcLoadRow(CY_SPC_FIRST_EE_ARRAYID, rowData, CYDEV_EEPROM_ROW_SIZE) == CYRET_STARTED)
            {
                while(CY_SPC_BUSY)
                {
                    /* Wait until SPC becomes idle */
                }

In this code is a while() statement that relies on CY_SPC_BUSY becoming false in order for it to exit the loop.

Is there any way this code could get stuck here? Are there any circumstances (temperature, voltage fluctuations) under which CY_SPC_BUSY can stay true forever?

If EEPROM_UpdateTemperature() wasn't called recently, could this loop get stuck?

If I wanted to deliberately cause this loop to get stuck by messing with the external conditions of the chip, is there some way I could do it?

If I wanted to deliberately cause this loop to get stuck by incorrectly using the EEPROM component API, is there some way I could do it?

We are using PSoC Creator 4.4 and have automated our builds.

In the PSoC Creator User guide,  I saw the option to generate project datasheets.

Would it be possible to create these using a command line tool, such that we can integrate it in our automated build?

We would like this to work for all the four projects we have in our workspace. One project is the active project and triggers the build of the other three projects. In the user guide it mentions that the generation is done for the active project. I hope this can be specified when using a command line tool.

Does Infineon support any implementations of Micro ROS on PSOC (4 or 5)? 

If not has anyone tried this and had success?

The officially supported hardware is given here: GitHub - micro-ROS/micro_ros_setup: Support macros for building micro-ROS-based firmware.

Device: CY8C5888LTI-LPO97

Simply trying to get print statement read out in putty. Device is connected to computer via USB connection. 

Firmware has been updated.

Already checked port and pin is correct one for this hardware. 

Code has not been changed. I have tired all baud rates.

Anyone I can trouble shoot this. I have no errors in the logs and nothing to tell me there is something wrong with the program. Is it possible the hardware is bad? I would appreciate any suggestions to trouble shoot. 

Hi,

I'm trying to aggressively use a hibernate mode and a WDT is intended to pull the CPU out of hibernation.

However, I need to preserve some data through the WDT reset.

Is there a keyword declaration to place certain RAM variables in an area of memory that does not get initialized immediately after a reset?

I'm aware of the .bss section of RAM.  However after multiple searches among the compiler .h files, I could not find a declarative keyword that would force RAM variables to this area of memory.

I suspect I'm missing something obvious.  Help would be appreciated. 

Hey All,

I have a warning that's suddenly cropping up in a design and I'm hoping I can get some input as to why exactly it is occurring and hopefully how to clear it up.

I have some custom logic to dictate the behavior of a "Fault LED" as well as a status register using a PSoC5LP (CY8C5667AXI-LP040).  The internal logic schematic is below:

The idea is that I have a FAULT_STAT register to see in firmware which faults have occurred, and a LED connected to FAULT_LED that is sticky so that if any fault occurs the LED will turn ON an remain ON until a power cycle/reset occurs.  Any of the faults firing will cause a rising edge on the DFF and turn FAULT_LED high.

With this setup, I receive the following on build:

Warning-1350: Asynchronous path(s) exist from "FAULT_A(0)_PAD" to "KpdClk".

Warning-1350: Asynchronous path(s) exist from "FAULT_B(0)_PAD" to "KpdClk".

I'm not sure why this is being thrown.  KpdClk is a 100Hz clock I am using mainly as a clock for the status registers that read in an external keypad.  I am also using it in a few other spots such as an Edge Detector and as the source clock for a single-shot timer elsewhere in the design that should have no bearing on the issue here.

I guess I'm confused as to why this is an issue with FAULT_A and FAULT_B specifically.  My first thought was maybe something about how I have these two signals controlling the CLK line of the DFF, but BN_FAULT is similarly connected as a way of controlling the DFF CLK, but the warning is not thrown for this pin.  I guess I just am not seeing how FAULT_A and FAULT_B can have any relation to KpdClk, but BN_FAULT does not?

Here's a snippet info pulled from the Static Timing Analysis Document:

So what's actually going on here and how would I go about clearing up this warning?  I can't share the entire project, but I can provide more details as necessary, if necessary.

Thanks!