PSoC™ 4 Forum Discussions

Designing a product using the CY8C4014LQI-421, which does not have XRES on this MCU, and using the on-board programmer on the CY8CKIT-042 to connect to SWDIOSWCLK for debugging, I found that it could not be connected, and that the device could not be discovered by CREATOR. What other device can I use to debug it?

smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/PSoC-4/CY8C4014LQI-421%E7%BC%96%E7%A8%8B%E8%B0%83%E8%AF%95%E8%BF%9E%E6%8E%A5%E5%A4%B1%E8%B4%A5%E7%9A%84%E5%8E%9F%E5%9B%A0-%E6%80%8E%E4%B9%88%E8%A7%A3%E5%86%B3/td-p/735447

Show Less

Background to the issue:

When customers use PSoC Creater, sometimes in order to fix bugs or find problems, they often need to add customized test programs to the code in Generated_Source, but if they add user-defined code directly to the code in Generated_Source, it will be overwritten once it is recompiled, is there a way to make the code in Generated_Source not be overwritten? Is there a way to make sure that the code in Generated_Source will not be overwritten by the customer's own additions?

Solution:

1Macro Callbacks

Macro Callbacks is a term defined in PSoC Creator to call user code from macros specified in a Component's generated code. These macros can be used by defining them in the user-defined header file named cyapicallbacks.h. This file will be included in all generated source files that offer callbacks.

A callback requires you to complete the following.

• Define a macro to signal the presence of a callback (in cyapicallbacks.h ).
• Write the function declaration (in cyapicallbacks.h ).
• Write the function implementation (in any user file).

To complete the example, the cyapicallbacks.h file would include this code.

#define SimpleComp_1_START_CALLBACK

void SimpleComp_1_Start_Callback( void ).

In any other user file, you could include cyapicallbacks.h and write the SimpleComp_1_Start_Callback() function.

For example.

2,

Merge Regions

Merge Regions provide another method to insert user code, through the use of specially marked sections in generated code, such as.

/* `#START isr_Interrupt` */

/* `#END` */

Anything you place in this region will be preserved in subsequent updates of the file. If a subsequent version of the file does not contain the same named region, the entire region from the previous file will be copied to the end of the file and placed in comments.

smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/PSoC-4/PSoC-Creater-IDE-%E5%A6%82%E4%BD%95%E4%BF%AE%E6%94%B9-Generation-Code/td-p/492049

Show Less

Background to the issue:

When using the Em_EEPROM function module of PSoC ™ 4 and using PSoC Creator to simulate and debug, the customer found that once the program runs to the "Em_EEPROM_Write" function, the simulation will be interrupted, and the following error message appears:

Problem Analysis:

1, Em_EEPROM implementation mechanism is in the chip's internal Flash divided into a region as Em_EEPROM storage space, so the erase and write of the analog Em_EEPROM is ultimately called to the internal Flash erase and write operations.

2, the operation of the chip internal Flash must use the internal clock, if the customer project is using an external clock, and did not turn on the internal clock, when writing FLash operation must be switched to the internal clock, wait for the Flash write operation is completed in the re-switching bit internal clock. After the write operation is completed, the internal clock is turned off during the process of switching to the external clock, which leads to the above exception error.

3, the user outside the use of Flash operation regardless of the time when the system uses the external clock need to turn on the internal IMO:

This avoids the need to simulate the project with internal flash writing operations.

smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/PSoC-4/PSoC-4-%E6%A8%A1%E6%8B%9FE2%E4%BB%BF%E7%9C%9F%E5%BC%82%E5%B8%B8%E4%B8%AD%E6%96%AD%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88/td-p/492044

Show Less

Can non-Automotive PSOC4 support touch screens, and what is the maximum size or resolution that can be supported? Gen6 and Gen7 are not adopted due to their high prices。

Show Less

I've been using 4.4 for a couple of years. At some point, my setup got corrupted, and it started complaining about being unable to find certain component versions. They are:

• cy_isr: have 1.70, need 1.71
• cy_boot: have 6.0, need 6.10
• LIN_Dynamic: have 5.0, need 6.0
• ADC_SAR_SEQ_P4: have 2.50, need 2.60

I uninstalled PSoC Creator 4.4, did a fresh download (which is identical to the one I downloaded two years ago), did a fresh install, and they're still not there. It looks like these install files don't contain the latest components. However, the Component Installer shows no components whatsoever, even if I set the device to "all" and turn off the "Show only newer" checkbox. It's behaving like you've completely removed the component library from your website, so now all that's available is a two year old installer. My company buys thousands of these PSoCs, and now I can't do my work. I'm stuck.

If you can't fix what's wrong at your end, can you at least provide me with the four components mentioned above, for individual download?

Show Less

I am playing with the example project, RTC_P4_WDT_Example01, using the CY8CKIT-042-BLE-A Pioneer Kit.  The RTC component (version 1.30) does not handle the DST flag in the status register of struct RTC_DATE_TIME.

 

 

void RTC_Update(void)
{
    //  [skip a bit...]

    #if(0u != RTC_INITIAL_DST_STATUS)
        if(RTC_unixTime == RTC_unixTimeDstStart)
        {
            RTC_dstStatus = 1u;
            RTC_dstTimeOffset = RTC_SECONDS_PER_HOUR;
        }

        if(RTC_unixTime == (RTC_unixTimeDstStop - RTC_dstTimeOffset))
        {
            RTC_dstStatus = 0u;
            RTC_dstTimeOffset = 0u;
            RTC_unixTimeDstStart = RTC_GetDstUnixTime(&RTC_dstStartTime);
            RTC_unixTimeDstStop  = RTC_GetDstUnixTime(&RTC_dstStopTime);
        }
    #endif /* (0u != RTC_INITIAL_DST_STATUS) */
//  [.... more .... ]

 

 

 

Note that RTC_dstStatus is set and cleared correctly, but this information never makes it into the status register. 

In contrast, here is the code that immediately follows this.  It handles the alarm status:

 

 

 

    //  [..... continued ....  ] 
   #if(0u != RTC_INITIAL_ALARM_STATUS)
        if((RTC_unixTime + RTC_dstTimeOffset) == RTC_unixTimeAlarm)
        {
            RTC_currentTimeDate.status |= (1uL << RTC_STATUS_ALARM_OFFSET);
            RTC_alarmCurStatus = RTC_alarmCfgMask;

            RTC_unixTimeAlarm = 
            RTC_GetNexAlarmTime(RTC_unixTime + RTC_dstTimeOffset,(uint8)RTC_alarmCfgMask);

            /* Call callback function only after new alarm time is obtained.
            * Cypress ticket #264756
            */
            if (RTC_alarmCallbackPtr != NULL)
            {
                RTC_alarmCallbackPtr();
            }
        }
    #endif/* (0u != RTC_INITIAL_ALARM_STATUS) */

 

 

 

Right there near the top, there's a line that modifies RTC_currentTimeDate.status.  This read-modify-write indicates the correct alarm status, but this step is missing for DST status.

To investigate this, I added a few lines of code to UpdateTimeIsrHandler() to get and print the current RTC_DATE_TIME.status .  The expected behaviour is that the status flag will change when 3:00 becomes 4:00.  It does not.

You might even think that RTC_ReadStatus() would help.  Its description says that it "Reads the Status software register, which has flags for DST (DST), Leap Year (LY), AM/PM (AM_PM)."  But it does not do this.  Instead, it modifies the Status register with the correct flags for LY and AM_PM, and then returns the modified status.  Note that if RTC_ReadStatus() is never called, then these bits are never modified.  It seems weird that an API with the name "Read" is the only way to modify the status register.  The description of RTC_ReadStatus() suggests that we use RTC_GetDateAndTime() instead, and then access the status register directly.  However, if we do this, these bits will always be zero. 

Even knowing this weird behaviour does not help with DST, because RTC_ReadStatus() does not modify status register with the correct value of the DST status flag, so even calling RTC_ReadStatus() does not return the correct DST status.

How does anyone know whether the current time is DST?  None of the APIs give you this information, and the DST flag in the status register doesn't do anything.  The only way to know if DST applies to the current time is to invoke the global flag uint8 RTC_dstStatus.  In the component datasheet, DST is mentioned 109 times.  RTC_dstStatus is given just  these five words by way of explanation: "The DST start/stop status".  That's a bit too economical.

This weirdness in how the RTC component handles the status register could explain problems that other users have encountered, such as the failure to update status described in this post.   

 

Show Less

Although the project build automatically saves the C files, it does not save any edited assembly files. Is there a way to force these files to save before building the project?

Show Less