The system shall wake-up by RTC start manually Adv and after Adv go to sleep. For testing and seeing what happens, I toggle a LED every wake-up.
The only thing I am unhappy with and which could draw more power than needed is the line:
Cy_Syslib_Delay(7); When I reduce the delay to ~<5 then the system does wake-up at once in a loop and does never deep sleep. Is there a better solution for that?
I have attached my project.
Please refer to the following code example for a typical BLE broadcaster example:
Typically the broadcast timing is taken care of by the BLE hardware itself. Note that advertisement interval indicates the delay between two successive broadcast intervals. The system can be in Deep Sleep during this interval.
we want to allign all cpu activity to one wake-up event. We do not want to use RTOS.
Is it possible without RTOS to wake up the while(1) loop every BLE Adv interval?
Some minor comments on your implementation -
Let me know if you have more questions on this regard.
Meenakshi Sundaram R
you have to know that this is a benchmarking firmware for comparing current consumption to other BLE chips from other manufacturers.
The requirement is to control the exact timing of Advertising transmission. Because in future projects, the Advertising shall be executed straight after handling some analogue circuits which are influenced by voltage drops from the high impedance of a button cell. This is the reason why I am stopping and starting Advertising manually and do not let the BLESS wake up the CPU. As I asked in another thread, there is no function which passes me control to my firmware before or after the BLESS was active, so I had to enable and disable it by myself. This is the reason why I chose an Advertising intervall higher than 3 s to prevent the BLESS waking up the CPU.
1) We want to use a single core PSoC63 derivate -> there is only a M4 onboard. The Pioneer board has got a dual core, this is the reason why I am only executing the firmware on the M4 for a real benchmark.
2) Thanks for the clue. I optimized the "waiting" loop.
3) A always running RTC is a requirement for the test-case, too. Not using extra timers (which may cause extra current drawing) lead me to use the RTC for periodic triggering the wake-up of the CPU and code execution.
4) Advertisement interval shall be 3 s. This is the reason why I reset the time every wake-up. In the future project the alarm will be incremented every 3 s.
-> With a power analyzer I measured an average current consumption of 16 µA (measuring over 3 periods). Soon we will see, if other manufacturers do better in current consumption for the exactly same task.