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
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.
I'm currently trying to program a brand new CY8C4146FNI-S433 on a custom board with a MiniProg3 and PSoc Programmer 3.29.1
I have connected the MiniProg3's SCLK, SDAT, XRES GND, and VARG to the corresponding pins on the Cypress chip.
PSoC programmer is able to auto detect the device correctly, however it constantly runs into a "FAILED! EraseAll operation failed"
I am able to "read to log" correctly, and I've tested that the pins are properly soldered to the device.
(I tried to program when removing one pin at a time, the device was undetected, upon reconnecting the pin, it was able to detect the device.)
When I read the flash, it says that the state is "OPEN" but I'm not convinced.
I've tried every combination I can think of when it comes to the settings, but unfortunately nothing is removing this EraseAll error.
This is the second chip I have tried it on with the same issue.
The only things I can think of are:
I'm not convinced that the device is damaged since I can read flash and detect the device. (Am I wrong in this assumption?)
I have removed all other active components from the board to remove the load on the VDD line.
Is there something I'm missing? I didn't do much with changing settings and I'm working with a hex file that I received from the company that wrote the firmware.
I pretty much just downloaded PSoC programmer, Connected the MiniProg3 and went to work. Is there some setup I missed?
Any information would be greatly appreciated!
When is the Spanning option in the Pin component going to be given separate control from the Contiguous option? Or, if it has been overlooked, can it be changed soon?
It states in both the component and in old and new documentation that this change will occur in the future. The link below is to a workaround from a similar question asked a few years ago, but if the option is supposed to exist without a workaround, I would like to use that. In my case, I am running two CAN controllers, hardware dedicated for each a single and dual wire CAN bus, on the same port, due to component spacing. The dedicated RX pins are not contiguous, so contiguous can't be used. Since they are on the same port, two separate pin components, each with interrupts, can't be used. And the spanning option can't be enabled if a dedicated interrupt is to be used, since the interrupt is port specific.Show Less
my client is more concerned about the patent aspect when doing the program;
is there any introduction of Cypress's touch technology patent?
If so, can you help me to provide it to me?
Thank you very much!Show Less
the code for the temperature sensor DS18B20 works fine using only the display. But when I add the BLE code, I can't get it to work, it disconnects before receiving the temperature value. I have tested the same BLE code with another max30102 sensor and it works perfectly.
Can you help me?
Thank youShow Less
Hi, in our application we use Cypress(Infinity) CY8C4128LQI-BL543 chip.
Development done with Cypress PSoC Creator 4.2 IDE.
Application should establish BT connection and send or receive some data.
All the time CPU and BLE in possible Sleep mode.
Accordance to data logs from our customers we know that sometimes program took Watch Dog reset.
Watch Dog timeout is about 20 sec.
We catch watchdog reset as following: LR : 0x00007027 PC : 0x00002536 (LR - Link Register,
PC – Program Counter Register).
During analyzing of disassembly file we find out that reset took place in the CyExitCriticalSection() that was called by ll_wait_to_exit_dsm.
ll_wait_to_exit_dsm called by: ll_exit_low_power_mode.
ll_exit_low_power_mode called by : CyBleController_ExitLowPowerMode or ll_task_handler.
CyBleController_ExitLowPowerMode called by:
CyBle_StackInit /CyBle_Shutdown/ CyBle_SoftReset/ CyBle_ExitLPM
It looks like Ble Stack can’t wake up BLE when application wants to send data.
Q: what can we do in application code to avoid such deadlock?Show Less
「ARM GCC 5.4-2016-q2-update」、「ARM GCC Generic」、「ARM MDK Generic」
実際にBuild出来るのは「ARM GCC 5.4-2016-q2-update」のみです。
２．「ARM GCC 5.4-2016-q2-update」を最新バージョンに変更することは問題ありませんか？
３－２．BLE OTA External Momory対応のプロジェクト（２つのプロジェクトから成り立つもの）もEXPORTで出来るのでしょうか？Show Less
I have multiple I2C slaves on a network (they are all psoc4 mcu) and I would like to make a general call from the master to all the slaves using the general call address (0x00). Is it possible to accept general call address using EzI2C slave blocks? I tried finding a way to do it, but could not find any info.Show Less
so I saw the using the EZI2C Slave (SCB mode) [v4.0], it is possible to have a secondary slave address. I was wondering if it was possible to have the same "secondary salve address" when using a regular I2C (SCB mode) [v4.0] block. I looked for information, but could not find what I wanted.Show Less