PSoC™ 4

I am using the bootloader host to program the KtiProg to be an oscilloscope/function generator as shown in this project outlined here .  It works well for me, but there is a problem when some of my students try it. (The tcl  program that controls the Ktiporg Scope can not find the com port assigned by bootloader host and crashes.)  It can happen on Intel and AMD machines.

After some debugging it looks like the bootloader host uses COM3 no matter what.  When it works I get:

"Selected device: Intel(R) Active Management Technology - SOL (COM3) - UART
Generic Serial Port "  after loading the program into the kitprog.

When it is does not work (some students) IT will program the kitprog but it will give:

"Selected device: Standard Serial over Bluetooth link (COM3) - UART"  It looks like COM3 has been assigned to a blue tooth device.  Can you change which port it uses?  Bootloader host gives no error, but the software that uses the Ktiprog as an oscilloscope/function generator crashes when it tries to use it.  I have even programmed the CY8CKIT-043 and got everything working on one machine, only to have it fail when trying to use the software that controls the KitProg.  Maybe this is a Windows issue with COM3?

Thanks,

-Dave 

I am using PSoC4  CY8C4247AZI-M485 to measure 8 currents and i also want to measure a thermistor.  I can not seem to get PSoC to build this is there another way I can do this?

Hi，SIR:

Can you please help me solve a problem?

My current customer is using the PS0C4100S series, which has 5 TCPWMs, and the customer expects to generate 5 PWM outputs and needs an additional timer interrupt.
Can a TCPWM module be used as a timer interrupt and PWM output at the same time? If so, how do I set it up? If not, is there any other way to implement timer interrupts?
Thank you for your answer!

I'm using USB Audio code similar to the CY8CKIT_046_USB_Audio example project, in CY8C4246AZI-L433, and when the IN/OUT bandwidth is high, on one computer, in particular, the code will consistently lock up inside this loop:

/* Request for dynamic re-configuration of endpoint. */
USB_DYN_RECONFIG_REG |= USB_DYN_RECONFIG_ENABLE;
/* Wait until block is ready for re-configuration */
while (0u == (USB_DYN_RECONFIG_REG & USB_DYN_RECONFIG_RDY_STS))
{
}

This register is at memory location 0x402c0050, and when the PSoC is locked up in this loop, that location reads 0x00000003 = 0b00011:

• DYN_RECONFIG_RDY_STS = 0b0 = not ready for reconfiguration
• DYN_RECONFIG_EPNO = 0b001 = Endpoint 2 ("Use 0 for EP1, 1 for EP2, etc.")
• DYN_CONFIG_EN = 0b1 = enable the dynamic re-configuration for the selected EP

So we've enabled re-configuration on EP2 (IN audio) but it's not entering the ready state.  Any idea why?

Before this happens:

• Data is flowing normally IN (EP2) and OUT (EP1), with feedback IN packets regularly (EP8)
• The IN packets start to become identical. Buffer is not being updated?  This might actually be the root of the problem.  They are still changing length, though, to maintain the correct sample rate.
• The feedback packets stop
• After another ~35 OUT packets on EP1, the OUT packets stop
• After another ~35 IN packets on EP2 (all of which are now identical), the IN and OUT interfaces are both put into zero-bandwidth mode
• The OUT interface is put into active mode
• OUT packets are transmitted on EP1
• Feedback packets are transmitted on EP8, all zeros
• After ~40 OUT packets on EP1, the firmware locks up in that loop, seemingly during reconfiguration of EP2.

We are using PSOC 4 device [CY8C4014SXI-421 ] for proximity sensing application. 

We are using internal flash as EEPROM to store the  value of calibration in order to calibrate the sensor.

We have used UART interface to monitor value of proximity.

Normally we see what the value of proximity is without foreign object near to it and we call it as background noise.

After taking the object to be detected near to sensor we record the value of proximity sensor ( which is higher than the noise value ), which then continuously polled for detecting the object. 

This works perfectly fine. Hence we deployed this system in pilot lot. 

However to our surprise its observed that, background noise changes after few days. And sensor starts detecting the noise value ( as the noise value exceeds the calibration value )

Although nothing has been changed since from the 1st installation & calibration,  this random event is observed couple of times.

I am attaching schematic FYR.

Please advise so that can bring reliability to our application.

We use the cypress chip as controller of a battery management systems (BMS). Sporadic we have seen that chips misbehave. We've been unable to bring the chip in the misbehave state intentionally but discovered many occurrences over last year many BMS devices.

What is the misbehaviour:
- the cypress chip suddenly starts to consuming much higher power and heats up (>70°C).
- Software reset, reset over XRES or flashing different software doesn't help to get out of this high power consumption state.
- Only a full power off cycle might bring the chip back to normal power consumption. (Some keep consuming more).

My feeling is that the misbehaviour gets triggered by going in/out of DeepSleep, hibernate or similar but as already mentioned we were not able to trigger it on purpose. While going into the sleep state all unnecessary devices were turned off and the power source is switched to a LDO (3.3V), while active run a DC_DC converter with 3.5V is used. The VDDA and VDDD stays active but VRef is switched off.

What have we done to debug that:
- We verified the supply voltages
- Flashed a example when the chip was in this state (SysTick_Example with adapting/using the minimal GPIO to shown on our board).
- Tried to reset over Softreset, XRES
- using different capacitors/filters on VccD and VDDA/VDDD

Have you ever heard of a problem like this? Do you have an idea what the reason could be, how it could be provoke or most important how we could prevent getting into this mode?
Looking forward for your feedback