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!
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
I need to send 256 bytes, with a 4 bytes header, for a total of 260 bytes via SPI master.
Everything works fine with TX/RX buffers set to 16bytes, and a 16 bytes data buffer.
No matter what I do, when I increase the size of the data buffer, or the TX/RX buffers, or both, if stalls on the receive buffer full, I cannot find an example with a buffer larger than 8 or data buffer larger than 8, can someone help me understand what I am missing?
I know it is interrupt related, but I cannot figure out what to handle to make this work?
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
I am using the CYBLE222014-01 in an application where I need to put the entire module to sleep in the lowest possible power mode. When in this mode, there is no BLE activity or MCU activity other than an accelerometer programmed to wake the module up with motion. Then the module will do a rest and start from the beginning.
The purpose of this operation is to store the device on the shelf for several weeks in this ultra sleep mode and then wake up when the device is moved.
The battery is 300mAH. Reading through all of the datasheets for this module, if both the BLESS is in deep sleep mode and the system MCU is in hibernate, the current should only be around 25uA. I am drawing 260uA and cant see why.
The only other two devices on the board are the accelerometer and an eeprom. Both of those combined draw less than 10uA.
I have confirmed by reading the BLE state prior going into system hibernation, it comes back as BLESS_DEEPSLEEP. I know the MCU is going into hibernation because the board will auto reset when it receives the interrupt from the accelerometer. Only hibernation mode will do an auto reset. I have also tried CYBLE_Stop(). It gives the same results.
I have changed the SWD pins to GPIO and that didnt change anything.
I am using a timer, I2C, ADC and PWM modules. I run the stop function for all of those before going to sleep.
The I2C pull ups are 2.2K to 3.3V supply.
Anyone have any ideas as to what is causing the extra current?
I am really struggling to implement a fixed duty (50%), variable frequency pwm output (controlled by a pot). - I am trying to generate a variable (+modulated) clock frequency for an external chip.
The only way I seem to be able top do it is by adjusting both the period and compare (as period/2) simultaneously, which feels a little clunky.
would anyone have any other suggestions how this could easily be done?
Any pointers how this might be done would be greatly appreciated.Show Less