PSoC™ 4 Forum Discussions

(PSoc Creator 4.4, CY8C4248LQI-BL573, MiniProg3, proprietary board)

I'm trying to debug a bootloadable app. I can attach to the running target, and the debugger appears to halt the processor at some random location, but in reality the processor continues to run. It's flashing an LED as part of its normal operation. I can examine memory, but if I try to single-step or continue, it gets an unexpected error and disconnects (not surprisingly).

If I hit the Reset button, after a few seconds it shows it halted on the first statement of main(), but after a fraction of a second I see my LED flashing again.

I thought it might have to do with sleep or the watchdog, so I disabled everything to do with those in my code, but it didn't change anything.

I've tried three different boards, and they all have the problem. I also have the problem on another board with a CY8C4125FNI-S433 processor. I've tried two MiniProg3 programmers. In their configuration, I'm using Reset for the Acquire Mode, since the device can't be powered from the programmer, and it does appear to acquire the target without any problem.

Yet whenever it tries to halt, something is either causing the core to sail right by the breakpoint, or resetting the core and making it start over without breakpoints.

FWIW, the firmware I'm debugging was written and successfully debugged by someone else, and I've only made some modest changes to it.

If anyone has seen this behavior, I'd like to know what they did to fix it. Or if there's any more info about my system that would be helpful, I can provide it.

I'm trying to bootload a 4100S from a 4200BLE over I2C, as described in AN86526, using the standard commands included in the Bootloader component in the 4100, and the cybootloaderutils that came with PSoC Creator 4.4 in the 4200. The I2C works fine in normal operation--I originally had the two devices communicating with just a simple application in the 4100--but I'm now trying to make the 4100S upgradable.

The problem I'm having is that there doesn't seem to be any flow control across the I2C. For quick commands like Enter Bootloader, there is no issue, but when I send a Get Metadata command, it takes some time to prepare the response, during which time reading the response returns all FFs. Retrying it a few times eventually returns the correct response.

But when I issue a Program Row command, which takes a very long time, and attempt to read back the result before it's finished, it reads back a copy of the beginning of the Program Row command I just sent it. Bootloader.c uses the same buffer for reading and writing, but I would think that the slave I2C wouldn't respond with any data until the response had been prepared and Bootloader_WritePacket was called, at the end of the Bootloader_HostLink loop.

So question is: why is the slave returning the data I just sent it, instead of FFs? Since a valid packet always starts with 01, that would be an acceptable way to know when the response was valid. Has anyone else seen this behavior, and found a way to deal with it?

Dear  Infineon：
      due to  in some application we need to keep the ILO frequency , We note datesheet  describle that API can improve the ILO accuracy, We see the code of CE210292_WatchDogTimer, but we don't down how to do it ;

     we design the code ,   we don't know where  is mistake of code , can you help to advice it . TKS;

uint32 iloMatchCounts=0x00;

#define WAKEUP_PERIOD_IN_MS 500u
#define DESIRED_DELAY 500000u
#define ILO_MATCH_COUNTS ((WAKEUP_PERIOD_IN_MS * CY_SYS_CLK_ILO_DESIRED_FREQ_HZ)/ 1000)

uint32 iloMatchCounts = ILO_MATCH_COUNTS;

//开始测量
CySysClkIloStartMeasurement();

CySysWdtWriteMatch(CySysWdtReadMatch() + iloMatchCounts);
//补偿ILO的值;
if(CYRET_SUCCESS == CySysClkIloCompensate(DESIRED_DELAY, &tempIloCounts))
{
iloMatchCounts = (uint32)tempIloCounts;
}

// 写值到WDT>>这个需要吗？
CySysWdtWriteMatch(CySysWdtReadMatch() + iloMatchCounts);

//读取WDTCount
count1 = CySysWdtReadCount();
CY_delay();
count2 = CySysWdtReadCount();

//算误差;
count0 = Count2-cunt1;

CySysClkIloStopMeasurement();

We are looking for PSOC4 Development Kit CY8CKIT-001 part number for university technical classes.

But when i check web page i did not find any product in marketing, its obsolete.

Which model is equal and successor of PSOC4 Development Kit CY8CKIT-001?..

https://www.mouser.com.tr/ProductDetail/Infineon-Technologies/CY8CKIT-001?qs=zlGpwCgm6hFXwW5fzLCrkQ%3D%3D

Hello

I'm working through the OTA Fixed Stack Bootloadable project but cannot compile it.  Here are the errors:

I've tried adding the "extern" keyword to the prototype in OTA_Mandatory.h with no effect.  Here is an example of one of them:   

extern CYBLE_API_RESULT_T CyBle_StoreBondingData(uint8 isForceWrite);

Any assistance would be helpful.  

PS: There is an identical post but the OP mentioned she couldn't resolve the issue.  

https://community.infineon.com/t5/PSoC-4/BLE-OTA-Fixed-Stack-with-Use-of-BLE-API-service-in-the-bootloadable/m-p/31199

Hi, I may be missing simple here and am hoping that is all it is. I setup this logic circuit in order to create a simple state machine (I tried with the LUT as well and encountered the same issue). The way it is supposed to work is if the button is pressed the LED turns on, if the button is pressed again nothing happens. If it is pressed again the LED turns off, then the cycle repeats. The issue I am encountering is that the LED always follows the clock pulse and always turns on whenever the button is pressed.

I attempted switching the clock input for the flip-flops with the button, however the same issue persisted. The clock (tied to the Clk_pin) was made from two cascading watchdog timers for 1 Hz. I changed this to an on board clock at 367 Hz (minimum frequency division for CY8CKIT-044 Pioneer kit) and the issue still persisted. 

I have attached the code I made for the 1 Hz clock I created with the schematic design and timer setup.

------------------------------------------

void Clk()
{

    ClkPin_Write(~ClkPin_Read());

}

int main()
{

/* Enable the global interrupt */
CyGlobalIntEnable;


CySysWdtSetInterruptCallback(CY_SYS_WDT_COUNTER1,Clk);
CySysWdtSetCascade(CY_SYS_WDT_CASCADE_01);

CySysWdtSetMatch(0,512);
CySysWdtSetMatch(1,64); //So our total divide is 512*64

for(;;)
    {
          CySysPmDeepSleep();
     }
}