Hello,
We are building an audio streaming application wherein the central sends compressed audio to the peripheral.
On the peripheral, we have an external audio processor that toggles a GPIO line to interrupt the DA14580 every 8 ms. In response, the DA14580 streams 71 bytes of data to the processor via I2C. The I2C data transfer is interrupt driven. The peripheral does not transmit to the central. Note that our peripheral operates in Boost mode.
This works as expected when sleep is not enabled.
When we enable extended-sleep (with the peripherals kept awake all the time), the following wait loop in the BLE_WAKEUP_LP_Handler is executed once per wake-up.
while ( GetBits32(BLE_CNTL2_REG, WAKEUPLPSTAT) || !GetBits32(BLE_INTSTAT_REG, SLPINTSTAT))
如果(t)休息;
This loop along with the succeeding BLE_SLP_Handler seems to take just under 5 ms to complete. Being lower priority interrupts, any GPIO or I2C ISRs are held off until the wake-up completes. This breaks the data flow to the processor.
Indeed, the I2C transfer is fast enough that I can hold off the start of the data transfer until the wake up completes. The problem that remains is that the wake up may start while the I2C transfer is in flight thus disrupting the flow.
I can manually service the GPIO and I2C tasks within the wait loop. I was able to get this to work for a particular set of parameters for I2C, connection parameters, etc, but it does not seem to be robust. Clearly such an approach can delay the wake-up process and I'm not sure what effects that can have.
As an alternative, I would like to investigate whether the wait loop can be brought out of the BLE_WAKEUP_LP_Handler and executed within the main loop - in app_sleep_exit_proc() for example. This should allow the GPIO and I2C interrupts to execute and yet hold up the main loop till such time the wake up is complete. However, this does not seem to work.
Any suggestions would be welcome.
Thanks in advance,
Sandeep
-----------
Hi Sandeep Sira,
I understand your issue, but what you are trying to do is something that we can't guarrante that it will work, the time below 5ms that you see is the time that the XTAL needs to settle, if disrupting any of these functions there is a chance that you will miss the BLE event. What i can recommend is since you have your peripherals on, the BLE isn't going to save you that much power, so i would advise you to keep the BLE open as well while there is audio processing.
由于MT_dialog
Hi MT_dialog,
Thanks for your prompt response.
I have managed a workaround by waiting for any ongoing I2C transaction to finish before the wake-up wait is executed. As long as the transaction is shorter than, say 3 ms, I should be OK, right? Further transactions are prevented from being started since the GPIO interrupt is held off.
Could you please point me to an analysis of peripheral power consumption? Our audio processor is sub 1 mA @ 1.5 V so everything counts.
谢谢,
Sandeep
-----------
Hi Sandeep,
When waking up, you should avoid delaying the execution of the LP handler. The XTAL16M should be enabled as quickly as possible. Then the LP waits in the while loop in order to be de-asserted and the code then jumps immediately to the SLP. It is critical not to delay the LP to SLP transition. If you start the I2C transaction while you are waiting for the LP to de-assert and you finish the transaction before the de-assertion you should be ok, but you cannot stall the execution of the LP for 3ms in order for the I2C transaction to finish and then execute the LP nor delay the LP to SLP transition. If you do so you will face issues with the BLE connection.
We would also propose to try and measure on your application the time that the 580 is able to go sleep (with GPIOs) and check if it’s worth the additional complexity, as well as if the penalty from the sleep/wake-up procedure give you any actual power benefit when going into sleep. If the time of sleeping isn't that long perhaps you should reconsider the sleeping scheme and keep your 580 always awake while streaming.
This is dependent with the connection interval you are using, which in your case should be small to avoid latency.
We hope that we have not misunderstood your system configuration and we have not misguided you in any way.
由于MT_dialog
Hi MT_Dialog,
Again thanks for your response. Indeed, you have understood our situation quite correctly and your observations are helpful and very much inline with what I expected.
I have already been using GPIO lines to tell me about sleep events but perhaps you could advise me of the exact location at which I should assume exit from sleep (from a power draw perspective).
Is it at the point in BLE_WAKEUP_LP_Handler after the instructions
SetBits16(CLK_RADIO_REG, BLE_ENABLE, 1); // BLE clock enable
(PMU_CTRL_REG, RADIO_SLEEP, 0); // Power up! Note: System must run at 16MHz when powering up RADIO_PD.
or should it be after the completion of the BLE_SLP_Handler?
I am assuming radio sleep after the instruction
SetBits16(PMU_CTRL_REG, RADIO_SLEEP, 1);
in main().
I am trying to get a measurement of actual current draw in various situations but that will take me some time.
谢谢,
Sandeep
-----------
Hi Sandeep,
You can place it in the main loop before closing your peripherals before the WFI() and in the LP handler when you after the peripheral initialization.
由于MT_dialog
Thanks for your help.
Sandeep
-----------