I've got an application firmware in CY8C4247FNI-BL483 which uses both BLE and I2C and sometimes I notice that the firmware "freezes" stopping his execution. Since I can't trace the cause for this problem, there are known issues concerning the contemporary usage of these components? Anyone has encountered the same issue?
Yes, but I don't see clock stretching. With led debug I find that the execution is trapped on the "CyBle_ProcessEvents()" and I notice that this happens with frequent I2C events, or at least I suppose that, since I2C slave is an accelerometer and the firmware freezes when it has frequent accelerations. In fact the slave generates GPIO interrupts (for the PSOC Master) also if the acceleration goes over a certain threshold and that may occur if the device is in fast movement. I've tried to change interrupts' priorities like in http://www.cypress.com/forum/psoc-4-ble/ble-and-deepsleep-problem but that didn't solve the issue. Any suggestions?
Update: Setting the accelerometer opportunely I was able to generate an I2C interrupt event every 35ms so I was able to notice more frequently freeze events and "catch" them using SWD debug. I've attached two screenshots of the "Call Stack" for two freeze events that I was able to detect. The first seems to be generated inside CyBle_ProcessEvents(), the second occurs when it arrives a BLE Interrupt Event early after the device wakes up and exits from the critical section.
sorry for diverting the topic actually i couldnt communicate with u all experts.
Im new to Cypress Psoc4 BLE, my abstract is to take the data from the user i.e (any value like character saying 20 people then ill switch ON the relay so that it only allows 20 people in a slot to room.)
so here i dont know how to capture the User given data from CySmart Android app or Bluetooth Dongle.
Can any one guide how do get value from user.
Are you sure that the connection between PSoC and accelerometer? Are you able to get proper values. If connection is not proper the code might get blocked waiting for I2C data.
yes, the devices are connected correctly since I can get proper data from the accelerometer. I still can't explain why the Default Interrupt handler is called inside the CyBle_ProcessEvents() stack or inside Cy_BLESS Interrupt Handler Stack and that call, in fact, generates the freeze.
If the Cyble_ProcessEvents() call is ending up in the default interrupt handler, then you are most likely calling a Cyble_ function for the BLE chip in an invalid state, which is causing the internal state machine to crash/error. My guess is that you are calling a BLE api when in an interrupt, or while it is in an invalid state for the command you are calling, etc. At least, that has been my experience. Another option could be that the cyble events aren't being handled within the required time frame due to the I2C communication interrupts, and thus the BLESS stack is timing out. Try checking your interrupt priorities.