hi dialog
I'm implementing a function that pushes a movement by operating a GPIO level flip to output a waveform every second. This waveform lasts about 10ms +. I use the systick interrupt to generate the second event, and use time0 to control the gpio level to flip the output waveform. In the case of sleep off, it can output the waveform I expected, but in the ext sleep mode, it cannot output the waveform, but debugging I saw that the program did run into the time0 isr and operated gpio. But the gpio level has not changed.
ps 1: In order not to go to sleep during the output waveform, I am in
In user_app_on_system_powered (), check whether this waveform action is completed. If not, return KEEP_POWERED.
PS 2: The initial project I used was sdk5.04, pxp, and the chip was da14580.
What is the reason for this, because the system does not wake up, so I can not operate gpio? Do you have any advice?
thanks！
Hi zyosintek,
I am not completely sure for what you are trying to accomplish, so please try to describe more clear your requirement. Keep in mind that in sleep mode, all the peripheral domains( including timer0) are shut down. You can wake up the device either synchronously, via the BLE timer or asynchronously, via an external interrupt (input). To do so, you might use the app_easy_timer() to wake up the device and generate the second event instead of using the systick interrupt.
When using the app_on_system_powered you should not stay there for long. If your procedure takes time to be completed, you can divide it into smaller procedures and return KEEP_POWERED in order to force again the schedule_while_ble_on() to re-run. With this way the scheduler will run any other BLE events that will occur and then the SDK will run the .app_on_system_powered. So, you should return KEEP_POWERED until your procedure will have finished, and then you should return GOTO_SLEEP.
In general, there isn’t a standard delay that you can add into the user_app_system_powered(), but you should not stay there for long. You will have to make sure that the delay in the user_app_system_powered(), will let the scheduler to run all the events in the queue. In order to achieve that you will have to divide your procedure in smaller procedures that can be attached to the app_on_system_powered callback and return KEEP_POWERED as long as there is more procedure to perform. So, the device would execute the entire procedure piece by piece and without delaying the scheduler which schedules other events.
Thanks, PM_Dialog