you are complaining with most of your post that you cannot get a (simple) UART to work, but you constantly refuse from posting your project here for us to see what your error is. UART in BLE works. FULL STOP. So when you cannot get it to work probably the chip is not to blame. You are here in a developer forum and not in a Cypress roadshow. When you want to get help - post your project not running, we'll have a look at. Provide as much information as possible: Kit? which one? What runs, what doesn't run? etc.
My first guess is the example project that you are trying has some isr that is taking >100us execution time. Can you check that once.
Disable all the other components that have interrupts and see if that works.
It's either an interrupt or a messed up clock on your board that could cause this behavior I guess.
Hi I attach the project. It is ESS example project. The project relies on button press, which wakes up chip from deep sleep.
I don't need this feature, and it might cause debugging conflict as well. Therefore I commented it out (#504 main.c)
In my opinion it has at least two bugs :
1.mainTimer never zeroed. Thus condition measurementPeriod[chrInstance] <= mainTimer (#560 ess.c) doesn't make sense
2.isMeasurementPeriodElapsed[chrInstance] is never set to NO (except during initialization) although #560 ess.c contantly checks for buffer status - this functionality is single shot after startup. This is not environmental Sensor measurement, as expected
Hardware CY8CKIT-042-BLE + CY8C4247 dongle
mainTimer is set to zero in line 563.
There is a useful function when left clicking on a variable name: "Find all active References" allows to find those lines.
isMeasurementPeriodElapsed[chrInstance] is set to "NO" in line 619.
Thanks for the answer. But please note, that lines, that You've noticed is my personal insertion. But my comment is about what I've found in raw example project from CYpress. If You didn't find redundant code it means exactly what I've written. Still the open issue is what to do with this example if the code:
1. stops responding to BLE envents
2. stops responding the code itself external to BLE stack, except button press
Do You expect anything else from me?
Do You have any hints?
When nobody can help you here in the forum, consider to create a support case to get help from Cypress directly.
Silence of such experienced professional with many, many years of experience with PSOC is very meanfull.
You've change Bob. You no longer fight, when You here "Bug in Psoc"
Below is excerpt from PSOC4 Capsense example manual (but not BLE). It says WDT is used for wakeup from deep sleep. My code is example received from Cypress, which proves it's a Bug.
"An infinite loop in the main code of the design alternates the PSoC 4 device between
Deep-Sleep and Active modes. Watchdog timer is used to generate the interrupts with the wake
up period configured to either 30 ms or 200 ms depending on whether the touchpad is active or
not. If the touchpad is active, the wakeup period is 30 ms, else it is 200 ms."
it may look like, but I did not change my reaction when there is a bug. Fact was, that Robert did not reveal all the information needed to consider what help I could give him, so I asked him to contact Cypress. What could I have done better in your eyes?