PSoC 6 MCU

[Anonymous]

Hi,

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.

Thank you.

Regards

Andre

[VaisakhK_66]

Hi Andre,

Please refer to the following code example for a typical BLE broadcaster example:

http://www.cypress.com/documentation/code-examples/ce218139-psoc-6-mcu-ble-connectivity-eddystone-be...

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.

Regards,

Vaisakh

[Anonymous]

Hi,

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?

Thank you!

Regards

Andre

[MeenakshiR_71]

Hello Andre,

Some minor comments on your implementation -

1. You have selected Single core stack operation on CM4 - this means CM4 handles both the controller and host code. What that means is CM4 does the advertising processing as well i.e. it wakes up periodically from deep sleep or sleep (depending on what the CPU state is in) at the configured advertising interval and then sends the packet, listens for requests from potential masters etc.
2. You are not checking if the Cy_SysPm_DeepSleep returned success or not. What this could mean is the BLE controller may not be ready to enter deep sleep mode and might have returned failure at some times (say if the BLESS was listening for master scan/conn requests after sending advertising packet, it cannot enter deep sleep). So please always check the return status of the DeepSleep API. Only if it returns success, the system entered and exited deep sleep properly (i.e. either the BLESS interrupt or RTC interrupt woke it up). This could explain the delay you require to successfully enter deep sleep.
3. In the code you attached, RTC interrupt does not really matter as the BLESS wakes up the CPU every time it needs to send an advertisement packet. I think your idea of RTC interrupt is to wake up the CPU after a particular time and then stop advertisement. If thats the case, then tie the "StopAdvertisement" API to the RTC interrupt - say set a flag in the interrupt and then only if the flag is set call "StopAdvertisement".
4. I not sure what was intention behind setting RTC alarm seconds to '3'. If the intention is to interrupt the device every 3 second, then that is not how the alarm works RTC alarms work very similar to how our normal alarms work. If you set it to '3' and enable seconds and disable every other element. Then it is going to generate an interrupt every time the seconds value of the RTC equals 3 i.e. interrupts every minute If you want periodic interrupt and wake up from deep sleep, then check the MCWDT block. If this is the functionality you are intending, then fine

Let me know if you have more questions on this regard.

Regards,

Meenakshi Sundaram R

[VaisakhK_66]

Hello Andre,

I am attaching a reference project as per your indented usage and with the modifications suggested by Meenakshi..

Let us know if this helps.

Regards,

Vaisakh

[Anonymous]

Hi Meenakshi,

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.

Thank you!

Regards

Andre