本文描述了DA 14580睡眠模式的软件体系结构。芯片的工作方式有：
1。激活模式，
2。扩展睡眠模式，
3。深度睡眠模式。
在活动中 模式、系统域(ARM处理器、SysRAM、ROM等)、无线电(包括无线电和蓝牙低能-BLE核心)和外围域(UART 1/2、I2C、SPI等)。都很活跃。
在扩展睡眠模式下，除SysRAM、无线域和外围域外，系统域被关闭，XTAL16M时钟被停止。sysram仍然可以保存数据。 但无法接近。始终打开(Aon)功率域用于将数据保存在保持RAM中，并为唤醒系统的块(即唤醒计时器、正交解码器)提供电源。 还有BLE计时器。
在深度睡眠模式下，为了进一步降低功耗，SysRAM也被关闭。其他功率域的状态与扩展睡眠模式相同。
3.2唤醒事件时，在上述任何一种睡眠模式下，可以通过两种方式唤醒DA 14580：
通过BLE定时器同步唤醒，该定时器可以编程以唤醒系统，以便 服务一个BLE事件，如果由外部事件(输入)触发，则通过唤醒定时器和正交解码器异步地服务。
在BLE应用程序中，可以将DA 14580设置为上述任何一种睡眠模式。对于广告事件、连接事件或其他无线通信事件，需要唤醒da 14580。 启动并进入活动模式，以便在BLE无线链路上发送/接收数据包。由于这些事件是基于时间的事件，所以使用BLE定时器唤醒系统，包括BLE核心， 无线电，ARM处理器和其余的模块。在这种情况下，使用以下约定：“系统与BLE核心同步唤醒”。
在扩展/深度睡眠模式下，DA 14580也可以被外部事件唤醒，并且在醒来后ARM处理器可以执行一些功能。然而，在那一刻，它可能还不是 用于BLE通信事件的时间，例如连接事件，因此BLE和无线电可以保持断电状态。在本例中，使用了以下约定：“系统被唤醒” 与BLE核心同步“。
如果系统被异步唤醒，那么向内核任务(以及最终通过蓝牙无线链路)传输消息的任何请求都不能立即执行，而且必须执行。 同步到BLE核心。这是因为堆栈是以这样一种方式构建的，即消息事件的处理要求BLE核心处于活动状态，以便从BLE核心i中获取定时信息。 有空。当BLE核心被关闭时，这个时间信息是不可用的。
4描述睡眠模式的概念
对内核的主回路进行一步的描述，以结合节能特性。
主循环的最简单形式如图1所示。
这个简单的循环一直在执行内核的调度函数。即使不需要做任何事情，主处理器也不会空闲。这个简单循环的发展如下所示。
添加对WFI()的调用后，循环执行Schedule()，它为所有挂起的事件和任务提供服务，然后主处理器暂停，等待中断发生。这件事 ACH可用于中断驱动系统，如DA 145801。它引入了一种省电功能，因为主处理器停机时的功耗低于活动时的功耗。
这种方法可以进一步扩展，以考虑到系统的特定块可以被关闭。在DA 14580中，如果不需要，可以关闭BLE核心和无线电。为了t o支持此特性，可以使用以下主循环，假设系统始终同步唤醒BLE核心。这是一个约束，因为在da 14580中，t 内核的定时参考来源于BLE核心。因此，为了能够调用Schedule()，BLE核心和无线电必须处于活动状态。
采用上述方法，不仅主处理器在所有处理完成后停止，而且在不需要时，BLE核和无线电也会被关闭，从而降低了功耗。
n甚至更远。除了控制BLE核心和无线电的电源状态外，DA 14580还提供了控制除AON域之外的所有功率域的能力。
在奥德 r为了将DA 14580的电源管理能力提高到最高水平，可以修改主回路，如下所示。
在这个主循环中，在调用Schedule()之后，通过调用ble_user()来研究睡眠的可能性。如果允许睡觉，那么BLE核心和无线电就会被关闭，就像在PRE中一样。 前案。除此之外，其他的电源域根据所选择的工作模式(扩展或深度睡眠)被设置为它们的适当状态。如果因为 挂起BLE活动，然后发出一个简单的WFI()调用来停止主处理器。
这个主循环对于同步唤醒的应用程序来说就足够了。这样可以保证每当执行主循环时，BLE核心和无线电都是活动的，调度()可以是c。 balled再包土的
如前所述，DA 14580也可以异步唤醒。因此，当BLE核心和无线电关闭时，主循环必须执行。在这种情况下，另一个结构是n。 主回路。第6节对此作了详细说明。
5 所需的（或所要的）东西
基于以上所述，需要设计一种SW体系结构，以适应以下情况：对进入和退出睡眠模式的操作进行处理。异步唤醒EV的处理 通过蓝牙链路向内核任务发送消息和传输数据的Ents/请求。此外，它还必须提供一个api，以便应用程序能够：动态地修改操作模式(Act)。 (根据其需要，扩展睡眠，深度睡眠)，并添加应用程序处理程序
o对于异步事件(请注意，“异步”一词描述了所有事件的特征，即它们的执行不是由内核任务处理的，因此与BLE co的操作是不同步的。 )，
o用于同步异步事件发出的传输请求，
o用于应用程序在系统进入休眠模式之前需要采取的操作。 就在离开之后。
6 SW体系结构
以下伪代码描述了SW中负责调度由各种任务生成的各种消息、为BL服务的部分的功能 E核的请求和处理异步事件的处理和它们的同步以及进入/退出睡眠模式的入口。
while(1)
{
------------------------------------------------------- Part 1: Scheduling (synchronous)
IF BLE is ON {
DO scheduling
DO synchronization of asynchronous events’ requests (Hook #1)
}
---------------------------------------------- Part 2: Processing of asynchronous events
DO asynchronous events processing (Hook #2)
------------------------------------------------------------- Part 3: Sleep entry / exit
#if SLEEP_ENABLED
GLOBAL_INT_STOP();
DO asynchronous events sleep processing (Hook #3)
// if app has turned sleep off, rwip_sleep() will act accordingly
SET sleep_mode based on rwip_sleep() result
// update mode according to app sleep flags
IF sleep_mode IS sleeping // app defines the mode
IF App has selected deep sleep
SET sleep_mode to deep sleep
ELSE
SET sleep_mode to extended sleep
IF (sleep_mode IS extended sleep) OR (sleep_mode IS deep sleep) {
SET radio off
DO descriptors and non-ret Heap checks
DO asynchronous events sleep preparation processing (Hook #4)
IF (sleep_mode IS extended sleep) OR (sleep_mode IS deep sleep) {
SET SCB->SCR[2] to 1
SET Pad Latches to ON
SET Peripheral power domain to OFF
IF sleep_mode IS extended sleep {
SET SRAM as retained
SET OTP copy to disabled
} else { // deep sleep
#if DEVELOPMENT__NO_OTP
SET SRAM as retained
#else
SET SRAM to OFF
#endif
DO Prepare OTP
}
}
DO App specific tasks just before sleeping (Hook #5)
WFI();
DO App specific tasks immediately after wake up (Hook #6)
SET SCB->SCR[2] to 0
}
ELSE IF sleep_mode IS idle
WFI();
GLOBAL_INT_START();
#endif
}
注意，异步事件是由外部中断生成的。强烈建议保持相应的isr尽可能短，以便系统以最小的延迟退出。 并返回到用户模式。任何处理都必须在Hook#2中完成。如果此处理的结果导致在ble无线链路上发送一个或多个数据包，则必须对此进行处理。 D在一号钩。由于进程间通信(任务消息传递)需要只有在BLE核心处于活动状态时才可用的定时信息，所以Hook#1是任何应用程序任务消息都应该是可用的。 发送到堆栈的下层(被“同步到BLE”)。
由于这一点至关重要，下面的几个例子说明了这两个钩子是如何使用的。
假设DA 14580处于休眠状态，并由唤醒定时器和正交控制器块发出中断。这个中断唤醒了系统。在相应的ISR中，在确认 中断时，设置一个标志(即事件1_标志)。目的是在下一个连接事件中通过BLE无线链路发送通知。因此，开发人员只需要同步事件。 1旗。因此，必须在Hook#1中添加检查此标志并向堆栈发送适当消息的代码。事件1_标志必须放置在保留内存中，因为DA 14580可能会进入睡眠状态。 直到BLE核心最终醒来。
如果该标志用于触发数据的异步处理，则必须在检查Event 1_标志的Hook#2中添加代码。如果处理结果导致必须通过 然后，必须设置另一个标志(例如，事件1_sync_标志)。必须将此标志放置在保留RAM中，因为DA 14580可能再次进入休眠状态，直到BLE核心最终醒来。T型 在这种情况下，事件1_标志不一定存在于保留RAM中。在Hook#1中，必须添加代码以检查Event 1_sync_标志并向堆栈发送适当的消息。
最后，在使用连接延迟的情况下，必须在下一个延迟锚点发送通知。在这种情况下，钩#2中的代码还必须强制唤醒t。 他没有核心。为此目的定义了一个API函数。在本例中，事件1_sync_标志不需要在保持RAM中，因为在BLE核心启动和SCH之前，DA 14580不会进入休眠状态。 编辑完成了。
Hook#3是提供的，这样应用程序可以确保在决定是否应该进入睡眠状态之前，不遗漏任何异步事件。例如，在检查了一个标志之后， 放置，安置通过异步事件的ISR，应用程序可能在此时更改其状态。为了演示这个钩子的必要性，请考虑一个已经编写了唤醒计时器a的应用程序。 Nd正交译码器块，以监测三个外部输入，并唤醒系统时，其中一个被触发。应用程序使用三个标志来表示这些前夜发生的任何一个。 NTS(即事件1_标志、事件2_标志和事件3_标志)。所有事件都会触发Hook#2中的异步处理。很明显，这个钩子中的代码将一个接一个地检查这些标志和e。 为它们中的每一个指定的操作。假设DA 14580由于触发了第三个输入而醒来，并且设置了Event 3_标志。在Hook#2中，代码将检查冷杉 ST两个标志，并发现它们没有设置，所以它将继续到第三个，即设置，并开始执行任何为这种情况编程的动作。最后，假设在此处理过程中， 第一个输入触发一个中断。处理将停止，ISR将被执行，事件1_标志将被设置。当isr退出时，代码将从Interru开始继续执行。 被抓了。问题是Hook#2已经检查了事件1_标志，并发现它没有被设置。因此，如果代码继续执行，而不再次检查此标志，并且芯片进入休眠状态，则如下所示 事件将丢失。因此，在Hook#3中，在一个受中断保护的部分中，可以再次检查所有事件的标志，以确保不丢失异步事件。
Hook#4的提供使得应用程序可以根据其当前状态动态地更改先前作出的任何进入睡眠的决定。因此，继续前面的示例，应用程序将 在这里检查它的状态，如果它不允许睡眠，那么它将睡眠模式更改为空闲。这样，就不会关闭任何权力域，并执行一个简单的WFI()。请注意 在这种情况下，BLE和收音机仍然是断电的。换句话说，这个钩子提供了使用“混合睡眠模式”的能力，在这种模式中，BLE核心和无线电被关闭，而另一个电源却被关闭。 R域是开的。
提供了Hook#5和Hook#6，以便应用程序能够在进入之前和退出低功耗模式后立即执行特定的功能。例如，一个应用程序可能 ED编程唤醒计时器和正交解码块，以唤醒系统时，它正在睡觉。或者，它可以选择降低rc16m频率时，在“混合睡眠模式”与周边设备ac。 为了进一步降低WFI期间的功耗。醒来后，应用程序应该再次恢复RC16M频率。
应用可以任意挂钩或同步修改操作模式（活动、扩展或深度睡眠）。但是，如果这是在钩子#5中完成的，则任何修改都将被带入conside 系统一次睡觉后的口粮就醒了。
在下表中，列出了各种钩子及其相应的时间约束。
Table 1: Description of Hooks
# Function name Functionality Timing
Constraints
1 app_asynch_trm()
Used for sending messages to kernel tasks
generated from asynchronous events that
have been processed in Hook #2.
用于向从Hook#2中处理的异步事件生成的内核任务发送消息。
Medium
2 app_asynch_proc()
Used for processing of asynchronous events
at “user” level. The corresponding ISRs
should be kept as short as possible and the
remaining processing should be done at this
point.
用于在“用户”级别处理异步事件。相应的ISR应尽可能短，其余处理应在此时完成。
Medium
3 app_asynch_sleep_proc()
Used for updating the state of the
application based on the latest status just
before sleep checking starts.
用于根据睡眠检查开始前的最新状态更新应用程序的状态。
Medium
4 app_sleep_prepare_proc()
Used to allow cancelling the entry to
Extended or Deep sleep based on the
current application state. The BLE and the
Radio are still powered off but the other of
the power domains stay active.
用于根据当前应用程序状态取消进入扩展或深度睡眠的条目。BLE和无线电仍然是断电的，但其他的权力域保持活跃。
Hard
5 app_sleep_entry_proc()
Used for application specific tasks just
before entering the low power mode
在进入低功耗模式之前，用于特定于应用程序的任务。.
Hard
6 app_sleep_exit_proc()
Used for application specific tasks
immediately after exiting the low power
mode.
用于在退出低功耗模式后立即执行特定于应用程序的任务。
Hard
如前所述，Hook#1用于同步异步生成的请求，以便将消息传输到OS任务(请注意，这也是发送消息Love的流程)。 r蓝牙链路)。同步是按照堆栈提出的要求进行的。这些堆栈要求转换为此函数的固定结构，pseud中对此进行了描述。 ocodeBelow。
----------------------------- synchronization of asynchronous events’ requests (Hook #1)
FUNCTION app_asynch_trm(void) RETURNS bool
{
IF Condition A is true {
DO something that results in sending a message to a kernel task
// Force rescheduling
RETURN true
}
IF Condition B is true {
DO something that results in sending a message to a kernel task
// Force rescheduling
RETURN true
}
IF Condition C is true {
DO something that does not involve sending a message to a kernel task
// Do not force rescheduling
}
RETURN false
}
在上面的例子中，函数检查三个条件并相应地采取行动。条件A和B会直接或在处理后向另一个任务发送消息。为了 是要服务的消息，必须执行调度。因此，此函数将停止任何进一步的执行并返回true。这强制执行日程安排。在此之后，这个函数将是cal。 又领先了。因此，如果所有条件(A、B和C)都为真，那么代码执行将遵循以下路径：
1。做日程安排。
2。调用APP_ANGC_TRM()。
3。条件A是真的。要求对A采取行动。一条消息被发送到另一个任务。APP_异步_TRM()停止返回true。
4。做日程安排。MES Sage由接收任务服务。也立即提供所生成的任何其它消息。
5。调用APP_ANGC_TRM()。
6。条件A是假的。条件B是真的。已要求对B采取行动。一条消息被发送到另一个任务。APP_异步_TRM()停止返回true。
7。做日程安排。这个 消息由接收任务提供。生成的任何其他消息也会立即得到服务。
8。调用APP_ANGC_TRM()。
9。条件A是假的。条件B是假的。条件C为tru e。要求对C采取行动。APP_异步_TRM()停止返回false。
10。代码继续挂钩#2。
7应用编程接口将以下API提供给应用程序以修改操作模式(活动、扩展睡眠、深度睡眠)。此API仅适用于单个PROCE SOR解决方案。
void app_disable_sleep(void);
Disables all sleep modes. The system is either in idle or active state.
禁用所有睡眠模式。系统要么处于空闲状态，要么处于活动状态。
void app_set_extended_sleep(void);
Activates extended sleep mode.
激活扩展睡眠模式。
void app_set_deep_sleep(void);
Activates deep sleep mode.
启用深度睡眠模式。
uint8_t app_get_sleep_mode(void);
Returns the current mode of operation.
0: sleep is disabled
1: extended sleep
2: deep sleep
返回当前操作模式。
0：睡眠被禁用
1：延长睡眠
2：深度睡眠
void app_force_active_mode(void)
If sleep is on then it is disabled. The current sleep mode (before setting
it to Active) is stored in order to be able to restore it, if needed.
如果睡眠是开着的，那么它就会被禁用。存储当前的睡眠模式(在将其设置为Active之前)，以便在需要时能够恢复它。
void app_restore_sleep_mode(void)
Restores the previous sleep mode (if any) that was changed with a call to
app_force_active_mode(). The application must not have modified the sleep mode in
the meantime.
恢复以前的睡眠模式(如果有的话)，该模式是通过调用app_force_Active_mode()而更改的。同时，应用程序必须没有修改睡眠模式。
void app_ble_ext_wakeup_on(void)
Put BLE into permanent sleep waiting a forced wakeup. After waking up from
an external event, if the system has to wake BLE up then it must restore the
default mode of operation by calling app_ble_ext_wakeup_off() or the BLE won't be able to wake up in order to serve BLE events!
让BLE进入永久睡眠，等待强制唤醒。从外部事件中醒来后，如果系统必须唤醒BLE，则必须通过调用app_ble_ ext_wakeup_off()或BLE将无法唤醒以便为BLE事件服务！
void app_ble_ext_wakeup_off(void)
Restore BLE cores' operation to default mode. In this mode, the BLE core
will wake up every 10sec even if no BLE events are scheduled. If an event has been scheduled earlier, then the BLE core will wake up sooner to serve it.
将BLE核心的操作恢复到默认模式。在这种模式下，即使没有安排BLE事件，BLE核心也会每10秒唤醒一次。如果某个事件已被提前调度，则BLE核心将 早点醒来为它服务。
bool app_ble_ext_wakeup_get(void)
Returns the current mode of operation of the BLE core:
false: default mode
true: permanent sleep, external wake-up is required.
返回BLE核心的当前操作模式：false：默认模式true：永久睡眠，需要外部唤醒。
bool app_ble_force_wakeup(void)
If the BLE core is sleeping (permanently or not), this function wakes it up.
A call to app_ble_ext_wakeup_off() should follow in case of permanent sleep.
如果BLE核心处于休眠状态(无论是否永久)，此函数将唤醒它。在永久睡眠的情况下，对app_ble_ext_wakeup_off()的调用应该跟着进行。
uint8_t app_last_rwble_evt_get(void)
Returns a value that informs about the last BLE or radio interrupt that has
occurred. The values returned by this function are defined in last_ble_evt
enumeration in arch_sleep.h. It can be used to synchronise asynchronous tasks,
which are executed in previously described hooks, with BLE or radio events.
返回一个值，该值通知发生的最后一次BLE或无线电中断。此函数返回的值是在arcesed.h中的lastble_evt枚举中定义的。它可以用来 与BLE或无线电事件同步在前面描述的钩子中执行的异步任务。
7.1 Setting sleep mode via da14580_config.h
文件da 14580_config.h包含两个可用于静态设置睡眠模式的定义。它们是：·cfg_ext_leke：如果定义了，则应用程序被配置为使用扩展睡眠m。 ODE，cfg_dep_·：如果未定义cfg_ext_leve，则应用程序被配置为使用深度睡眠模式，如果cfg_ext_leke和cfg_dewest都未定义，则应用程序配置为·。 AIN被配置为仅使用活动模式。外部处理器解决方案没有其他方法来定义睡眠模式，因为在这种情况下睡眠API不可用。
在单处理器解决方案的情况下，如果使用睡眠API，则应用程序代码可能会绕过这些设置，因为它具有更高的优先级。
请注意，当选中的内存映射被选中的睡眠模式检查以验证应用程序将正确构建时，也会使用这些设置。因此，即使应用程序选择 ES要绕过da14580_config.h中的睡眠模式设置并使用API(这是强烈建议的)，这些设置必须是正确的，并反映应用程序使用的深度睡眠模式。
例如，应用程序可以根据其当前状态使用睡眠API在所有操作模式(活动、扩展睡眠和深度睡眠)之间切换。在这种情况下，f中的设置 Ile da 14580_config.h应该是：
#undef CFG_EXT_SLEEP
#define CFG_DEEP_SLEEP
If the application used only Active and Extended sleep modes then these settings should be:
如果应用程序只使用活动模式和扩展睡眠模式，那么这些设置应该是：
#define CFG_EXT_SLEEP
#undef CFG_DEEP_SLEEP
8 Revision history
Revision Date Description
1.0 28-Mar-2014 Initial version.
1.1 18-Jul-2014 Minor changes, app_last_rwble_evt_get added
Status Definition
DRAFT The content of this document is under review and subject to formal approval, which may result in
modifications or additions.
APPROVED
or unmarked
The content of this document has been approved for publication.
本文件中的免责声明信息被认为是准确和可靠的。然而，Dialog半导体公司并没有对ACCURA作出任何明示或暗示的陈述或保证。 这类信息的完整性或完整性。如果Dialog S以外的任何信息源提供本文档中的内容，则DIALOG半导体公司将不对此文档中的内容承担任何责任 半导体公司。对话半导体保留更改本文件中公布的信息的权利，包括(但不限于)相关的规格和设计。 半导体产品，软件和应用。本文件中描述的应用程序、软件和半导体产品仅用于说明性目的。对话半导体没有再 说明或保证这些应用程序、软件和半导体产品将适用于指定用途，无需进一步测试或修改。除非另有书面协议 ，这种测试或修改是客户的唯一责任，而Dialog半导体公司不承担这方面的所有责任。客户注意：本文档中的任何内容都不能进行分析。 ED作为用户使用本文档中提到的Dialog半导体产品、软件和应用的许可证。这样的许可必须由客户单独地向DialogSemicond寻求。 布托。除另有规定外，本文件所述的所有使用Dialog半导体产品、软件和应用均须遵守Dialog半导体的标准销售条款和条件。 调味。公司名称：Dialog半导体有限公司。版权所有。
RoHS合规Dialog半导体公司遵守欧洲第2001/95/EC号指令，并从2013年1月2日起遵守关于限制危险物质的欧洲第2011/65/EU号指令(RoHS/R) (OHS2)。DIALOG半导体公司关于RoHS的声明可以在客户门户网站https://support.diasemi.com/.上找到如有要求，我们的供应商提供RoHS证书。
Company confidential
User manual
DA14580 Sleep mode configuration
UM-B-006
Abstract
This document contains information about the sleep mode configuration of the DA14580 and the
software architecture that has been defined to support these modes of operation.UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 2 of 15 © 2014 Dialog Semiconductor GmbH
Contents
Contents ............................................................................................................................................... 2
Figures.................................................................................................................................................. 2
Tables ................................................................................................................................................... 2
1 Terms and definitions................................................................................................................... 3
2 References ..................................................................................................................................... 3
3 Introduction.................................................................................................................................... 4
3.1 Sleep modes ......................................................................................................................... 4
3.2 Wake up events .................................................................................................................... 4
4 Description of sleep mode concept ............................................................................................ 4
5 Requirements ................................................................................................................................ 7
6 SW architecture ............................................................................................................................. 7
7 Application Programming Interface .......................................................................................... 11
7.1 Setting sleep mode via da14580_config.h.......................................................................... 12
8 Revision history .......................................................................................................................... 14
Figures
Figure 1: Simple main loop.................................................................................................................... 5
Figure 2: Main loop that allows main processor to be idle .................................................................... 5
Figure 3: Main loop that allows the BLE core and the radio to be powered down................................ 5
Figure 4: Main loop that implements Deep and Extended sleep modes............................................... 6
Tables
Table 1: Description of Hooks ............................................................................................................... 9
Table 2: Sleep API............................................................................................................................... 11UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 3 of 15 © 2014 Dialog Semiconductor GmbH
1 Terms and definitions
AON Always ON
API Application Programming Interface
ARM Acorn RISC Machines
BLE Bluetooth Low Energy
GPIO Generic Purpose Input Output pin
I2C Inter-Integrated Circuit interface
ISR Interrupt Service Routine
OS Operating System
RAM Random Access Memory
RC16M 16MHz clock generated by internal oscillator
ROM Read Only Memory
SPI Serial Peripheral Interface
SysRAM System RAM
UART Universal Asynchronous Receiver Transmitter
WFI Wait For Interrupt instruction
XTAL16M 16MHz crystal
2 References
1. DA14580 Datasheet, Dialog Semiconductor
2. UM-B-002, DA14580 Software architecture, Dialog SemiconductorUM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 4 of 15 © 2014 Dialog Semiconductor GmbH
3 Introduction
3.1 Sleep modes
This document describes the software architecture of the sleep modes of DA14580. The various
modes of operation of the chip are:
1. Active mode,
2. Extended sleep mode,
3. Deep sleep mode.
In active mode, the system domain (ARM processor, SysRAM, ROM, etc.), the radio (including Radio
and Bluetooth Low Energy – BLE core) and the peripheral domains (UART1/2, I2C, SPI, etc.) are
active.
In Extended sleep mode, the system domain except the SysRAM, the radio domain and the
peripheral domain are powered down and the XTAL16M clock is stopped. The SysRAM is still
powered to retain data but is not accessible. The Always ON (AON) power domain is on to keep data
in the retention RAMs and to supply power to the blocks that can wake the system up, i.e. wakeup
timer, quadrature decoder and the BLE timer.
In Deep sleep mode, to reduce the power consumption even further, the SysRAM is also powered
off. The status of the other power domains is the same as in Extended sleep mode.
3.2 Wake up events
When in any of the above mentioned sleep modes, DA14580 can be woken up in two ways:
● Synchronously, via the BLE timer which can be programmed to wake up the system in order to
serve a BLE event and
● Asynchronously, via the Wakeup Timer and Quadrature Decoder if triggered by an external event
(input).
In a BLE application, DA14580 could be set to either of the above mentioned sleep modes. For an
advertising event, connection event or other wireless communication event, DA14580 needs to be
woken up and go to active mode in order to send/receive packets over a BLE wireless link. Since
these events are time based events, the BLE timer is used to wake up the system, including the BLE
core, the radio, the ARM processor and the rest of the blocks. In this case, the following convention
is used: “the system is woken up synchronously with the BLE core”.
When in Extended / Deep sleep mode, DA14580 can also be woken up by an external event and
after waking up the ARM processor can perform some functions. However, at that moment it may not
yet be the time for a BLE communication event, e.g. a connection event and thus the BLE and the
radio can remain in power off state. In this case, the following convention is used: “the system is
woken up asynchronously with the BLE core”.
If the system is woken up asynchronously then any requests for transmission of messages to kernel
tasks (and, eventually, over the Bluetooth wireless link) cannot be performed immediately and must
be synchronized to the BLE core. This is because the stack is built in such a way that the handling of
message events requires the BLE core to be active so that timing information from the BLE core is
available. This timing information is not available when the BLE core is powered down.
4 Description of sleep mode concept
In this section, a step-by-step description is given of the way a kernel’s main loop can be modified in
order to incorporate power saving features.
The simplest form of the main loop is shown in Figure 1.UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 5 of 15 © 2014 Dialog Semiconductor GmbH
Figure 1: Simple main loop
This simple loop executes the kernel’s scheduling function all the time. The main processor is never
idle even when nothing needs to be done.
An evolution of this simple loop is shown below.
Figure 2: Main loop that allows main processor to be idle
With the addition of a call to WFI(), the loop executes schedule(), which serves all pending
events and tasks, and, then, the main processor is halted, waiting for an interrupt to occur. This
approach can be used in interrupt driven systems like DA14580
1
. It introduces a power saving
feature since the main processor consumes lower power when it is halted than when it is active.
This approach can be extended further to take into account that specific blocks of the system can be
powered down. In DA14580, the BLE core and the radio can be turned off, if not needed. In order to
support this feature, the following main loop can be used, assuming that the system always wakes up
synchronously to the BLE core. This is a constraint that comes from the fact that, in DA14580, the
kernel’s timing reference is taken from the BLE core. So, in order to able to call schedule(), the
BLE core and the radio must be active.
Figure 3: Main loop that allows the BLE core and the radio to be powered down
1
Actually, the same approach is used even in non-interrupt driven systems. In this case, a System Timer is set to hit at every i.e. 10ms
which triggers the execution of the main loop.UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 6 of 15 © 2014 Dialog Semiconductor GmbH
With the above approach, not only the main processor is halted when all processing has finished but
the BLE core and the radio are turned off when they are not needed, reducing the power
consumption even further. Apart from controlling the power status of the BLE core and the radio, the
DA14580 offers the ability to control the state of all the power domains except for the AON domain.
In order to exploit the power management capabilities of DA14580 to the highest level, the main loop
can be modified as shown below.
Figure 4: Main loop that implements Deep and Extended sleep modes
In this main loop, after the call to schedule(), the possibility to sleep is investigated by calling
ble_sleep(). If sleeping is allowed then the BLE core and the radio are turned off as in the
previous case. Apart from this, though, the other power domains are set to their proper state
according to the selected mode of operation (Extended or Deep sleep). If sleeping is not allowed
because of pending BLE activity, then a simple WFI() call is issued to halt the main processor.
This main loop suffices for applications that wake up synchronously. This way it is guaranteed that
whenever the main loop is executed, the BLE core and the radio are active and schedule() can be
called.
As mentioned before, the DA14580 can also wake up asynchronously. So, the main loop will have to
be executed while the BLE core and the radio are turned off. In this case, a different structure is
needed for the main loop. This is described in detail in Section 6.UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 7 of 15 © 2014 Dialog Semiconductor GmbH
5 Requirements
Based on the above, a SW architecture needs to be devised that will accommodate the following:
● Handling of entry to and exit from the sleep modes of operation.
● Handling of asynchronous wake up events / requests to send messages to kernel tasks and
transmit data over the Bluetooth link.
Also, it has to provide an API so that the application can:
● Dynamically modify the mode of operation (Active, Extended sleep, Deep sleep) according to its
needs and
● Add application handlers
o for asynchronous events (note that the term “asynchronous” characterizes all events that
their execution is not handled by kernel tasks and, thus, are not synchronous to the operation
of the BLE core and the stack),
o for the synchronization of requests for transmission made by asynchronous events and
o for actions the application needs to take just before the system enters into the sleep mode
and immediately after exiting.
6 SW architecture
The following pseudocode describes the functionality of that part of the SW that is responsible for
scheduling the various messages generated by the various tasks, for serving the BLE core’s
requests and handling the asynchronous events’ processing and their synchronization and of the
entry to / exit from the sleep modes.
while(1)
{
------------------------------------------------------- Part 1: Scheduling (synchronous)
IF BLE is ON {
DO scheduling
DO synchronization of asynchronous events’ requests (Hook #1)
}
---------------------------------------------- Part 2: Processing of asynchronous events
DO asynchronous events processing (Hook #2)
------------------------------------------------------------- Part 3: Sleep entry / exit
#if SLEEP_ENABLED
GLOBAL_INT_STOP();
DO asynchronous events sleep processing (Hook #3)
// if app has turned sleep off, rwip_sleep() will act accordingly
SET sleep_mode based on rwip_sleep() result
// update mode according to app sleep flags
IF sleep_mode IS sleeping // app defines the mode
IF App has selected deep sleep
SET sleep_mode to deep sleep
ELSE
SET sleep_mode to extended sleep
IF (sleep_mode IS extended sleep) OR (sleep_mode IS deep sleep) {
SET radio off
DO descriptors and non-ret Heap checks
DO asynchronous events sleep preparation processing (Hook #4)
IF (sleep_mode IS extended sleep) OR (sleep_mode IS deep sleep) {
SET SCB->SCR[2] to 1UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 8 of 15 © 2014 Dialog Semiconductor GmbH
SET Pad Latches to ON
SET Peripheral power domain to OFF
IF sleep_mode IS extended sleep {
SET SRAM as retained
SET OTP copy to disabled
} else { // deep sleep
#if DEVELOPMENT__NO_OTP
SET SRAM as retained
#else
SET SRAM to OFF
#endif
DO Prepare OTP
}
}
DO App specific tasks just before sleeping (Hook #5)
WFI();
DO App specific tasks immediately after wake up (Hook #6)
SET SCB->SCR[2] to 0
}
ELSE IF sleep_mode IS idle
WFI();
GLOBAL_INT_START();
#endif
}
Note that the asynchronous events are generated by external interrupts. It is strongly advisable that
the corresponding ISRs are kept as short as possible so that the system exits with minimal delay and
returns to user mode. Any processing has to be done in Hook #2. If the outcome of this processing
results in sending one or more data packets over the BLE wireless link then this must be handled in
Hook #1. Since inter-process communication (task messaging) requires timing information that is
available only when the BLE core is active, Hook #1 is where any application task message shall be
sent to the lower layers of the stack (be “synchronized to the BLE”).
Since this point is critical, a few examples follow that clarify how these two hooks are used.
Assume that DA14580 is sleeping and an interrupt is issued by the Wakeup Timer and Quadrature
Controller block. This interrupt wakes up the system. In the corresponding ISR, after acknowledging
the interrupt, a flag is set (i.e. event1_flag). The intention is to send a Notification over the BLE
wireless link at the next connection event. Thus, the developer needs only to synchronize the
event1_flag. So, code has to be added in Hook #1 that checks this flag and sends the appropriate
message to the stack. The event1_flag must be placed in the Retention RAM since DA14580 may
go to sleep until the BLE core eventually wakes up.
If the flag is used to trigger asynchronous processing of data then code has to be added in Hook #2
that checks the event1_flag. If the processing results into having to send a Notification over the
BLE link then another flag must be set (i.e. event1_sync_flag). This flag must be placed at the
Retention RAM because the DA14580 may fall again into sleep until the BLE core eventually wakes
up. The event1_flag does not have to be in the Retention RAM in this case. In Hook #1 code
must be added to check the event1_sync_flag and send the appropriate message to the stack.
Finally, there is a case where connection latency is used and the Notification must be sent at the next
latency anchor point. In this case, the code in Hook #2 must additionally force a wake up of the BLE
core. An API function is defined for this purpose. The event1_sync_flag needs not be in the
Retention Ram in this case since the DA14580 will not go to sleep until the BLE core is up and
scheduling is done.
Hook #3 is provided so that the application can make sure that no asynchronous events are missed
before deciding whether it should fall in sleep or not. For example, after examining a flag that was set UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 9 of 15 © 2014 Dialog Semiconductor GmbH
by an asynchronous event’s ISR, the application may alter its state at this point. In order to
demonstrate the necessity of this hook, consider an application that has programmed the Wakeup
Timer and Quadrature Decoder block to monitor three external inputs and wake up the system
whenever one of them is triggered. The application uses three flags to indicate the occurrence of any
of these events (i.e. event1_flag, event2_flag and event3_flag). All events trigger
asynchronous processing in Hook #2. It is obvious that the code in this hook will examine these flags
one after the other and execute the actions specified for each one of them. Assume a case where
DA14580 wakes up because the third input was triggered and that the event3_flag is set. In Hook
#2, the code will check the first two flags and find them to be not set so it will move on to the third
one, which is set, and start executing any actions programmed for this case. Finally, assume that
during this processing the first input triggers an interrupt. The processing will stop, the ISR will be
executed and the event1_flag will be set. When the ISR exits the code will resume execution from
the point it was interrupted. The problem is that Hook #2 has already checked event1_flag and
found it was not set. So, if the code execution continues without checking this flag again and the chip
goes to sleep then this event will be lost. Thus, in Hook #3, which is in a section that is protected
from interrupts, all events’ flags can be checked again to make sure that no asynchronous events are
lost.
Hook #4 is provided so that the application may dynamically alter any previously taken decision to go
to sleep, based on its current state. So, continuing the previous example, the application would check
its state at this point and if it does not allow sleeping then it would change sleep_mode to idle. This
way no power domains would be shut off and a simple WFI() would be executed. Note that the BLE
and the Radio are still powered off in this case. In other words, this hook offers the ability to use a
“hybrid sleep mode” where the BLE core and the radio are turned off but the other power domains
are on.
Hook #5 and Hook #6 are provided so that the application can execute specific functionality just
before entering and immediately after exiting the low power mode. For example, an application may
need to program the Wakeup Timer and Quadrature Decoder block to wake up the system while it is
sleeping. Or, it may choose to lower the RC16M frequency when in “hybrid sleep mode” with
peripherals active to reduce the power consumption even further during the WFI period. After waking
up, the application should restore the RC16M frequency again.
The application can modify the mode of operation (Active, Extended or Deep sleep) at any Hook or
synchronously. However, if this is done in Hook #5, then any modification will be taken into
consideration after the system sleeps once and wakes up.
In the following table the various Hooks are listed together with their corresponding timing
constraints.
Table 1: Description of Hooks
# Function name Functionality Timing
Constraints
1 app_asynch_trm() Used for sending messages to kernel tasks
generated from asynchronous events that
have been processed in Hook #2.
Medium
2 app_asynch_proc() Used for processing of asynchronous events
at “user” level. The corresponding ISRs
should be kept as short as possible and the
remaining processing should be done at this
point.
Medium
3 app_asynch_sleep_proc() Used for updating the state of the
application based on the latest status just
before sleep checking starts.
MediumUM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 10 of 15 © 2014 Dialog Semiconductor GmbH
# Function name Functionality Timing
Constraints
4 app_sleep_prepare_proc() Used to allow cancelling the entry to
Extended or Deep sleep based on the
current application state. The BLE and the
Radio are still powered off but the other of
the power domains stay active.
Hard
5 app_sleep_entry_proc() Used for application specific tasks just
before entering the low power mode.
Hard
6 app_sleep_exit_proc() Used for application specific tasks
immediately after exiting the low power
mode.
Hard
As already mentioned, Hook #1 is used for synchronizing asynchronously generated requests for
transmission of messages to OS tasks (note that this is also the flow followed for sending messages
over the Bluetooth link). The synchronization is done following the requirements posed by the stack.
These stack requirements translate to a fixed structure of this function which is described in
pseudocode below.
----------------------------- synchronization of asynchronous events’ requests (Hook #1)
FUNCTION app_asynch_trm(void) RETURNS bool
{
IF Condition A is true {
DO something that results in sending a message to a kernel task
// Force rescheduling
RETURN true
}
IF Condition B is true {
DO something that results in sending a message to a kernel task
// Force rescheduling
RETURN true
}
IF Condition C is true {
DO something that does not involve sending a message to a kernel task
// Do not force rescheduling
}
RETURN false
}
In the example above, the function checks three conditions and acts accordingly. Conditions A and B
result, either directly or after processing, in sending a message to another task. In order for this
message to be served, scheduling must be executed. Thus, this function stops any further execution
and returns true. This forces the execution of scheduling. After that, this function will be called again.
So, if all conditions (A, B and C) are true then the code execution will follow this path:
1. DO scheduling.
2. CALL app_async_trm().
3. Condition A is true. Requested action for A is taken. A message is sent to another task.
app_async_trm() stops returning true.
4. DO scheduling. The message is served by the receiving task. Any other messages that are
generated are also served immediately.UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 11 of 15 © 2014 Dialog Semiconductor GmbH
5. CALL app_async_trm().
6. Condition A is false. Condition B is true. Requested action for B is taken. A message is sent
to another task. app_async_trm() stops returning true.
7. DO scheduling. The message is served by the receiving task. Any other messages that are
generated are also served immediately.
8. CALL app_async_trm().
9. Condition A is false. Condition B is false. Condition C is true. Requested action for C is
taken. app_async_trm() stops returning false.
10. Code continues to Hook #2.
7 Application Programming Interface
The following API is provided to the application to modify the mode of operation (Active, Extended
sleep, Deep sleep). This API is available only for single processor solutions.
Table 2: Sleep API
API Functions
void app_disable_sleep(void);
Disables all sleep modes. The system is either in idle or active state.
void app_set_extended_sleep(void);
Activates extended sleep mode.
void app_set_deep_sleep(void);
Activates deep sleep mode.
uint8_t app_get_sleep_mode(void);
Returns the current mode of operation.
0: sleep is disabled
1: extended sleep
2: deep sleep
void app_force_active_mode(void)
If sleep is on then it is disabled. The current sleep mode (before setting
it to Active) is stored in order to be able to restore it, if needed.
void app_restore_sleep_mode(void)
Restores the previous sleep mode (if any) that was changed with a call to
app_force_active_mode(). The application must not have modified the sleep mode in
the meantime.UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 12 of 15 © 2014 Dialog Semiconductor GmbH
API Functions
void app_ble_ext_wakeup_on(void)
Put BLE into permanent sleep waiting a forced wakeup. After waking up from
an external event, if the system has to wake BLE up then it must restore the
default mode of operation by calling app_ble_ext_wakeup_off() or the BLE won't be
able to wake up in order to serve BLE events!
void app_ble_ext_wakeup_off(void)
Restore BLE cores' operation to default mode. In this mode, the BLE core
will wake up every 10sec even if no BLE events are scheduled. If an event has been
scheduled earlier, then the BLE core will wake up sooner to serve it.
bool app_ble_ext_wakeup_get(void)
Returns the current mode of operation of the BLE core:
false: default mode
true: permanent sleep, external wake-up is required.
bool app_ble_force_wakeup(void)
If the BLE core is sleeping (permanently or not), this function wakes it up.
A call to app_ble_ext_wakeup_off() should follow in case of permanent sleep.
uint8_t app_last_rwble_evt_get(void)
Returns a value that informs about the last BLE or radio interrupt that has
occurred. The values returned by this function are defined in last_ble_evt
enumeration in arch_sleep.h. It can be used to synchronise asynchronous tasks,
which are executed in previously described hooks, with BLE or radio events.
Note that the module monitors the calls to app_force_active_mode() (a counter is incremented
at each call) and to app_restore_sleep_mode() (the counter is decremented). In order for
app_restore_sleep_mode() to actually enable sleep, the counter must be zero! In other words,
the application must ensure that app_restore_sleep_mode() is called (at least) as many times
as app_force_active_mode(). If the application is split into different modules then this rule
applies to each module separately.
Finally, note that the Debugger cannot be used in any of the sleep modes because it has to be
turned off in order to allow powering down the System power domain.
7.1 Setting sleep mode via da14580_config.h
The file da14580_config.h includes two definitions that can be used to set the sleep mode
statically. These are:
CFG_EXT_SLEEP: if defined then the application is configured to use Extended sleep mode,
CFG_DEEP_SLEEP: if defined and CFG_EXT_SLEEP is not defined, then the application is
configured to use Deep sleep mode,
if both CFG_EXT_SLEEP and CFG_DEEP_SLEEP are undefined then the application is
configured to use Active mode only.
External processor solutions have no other means to define the sleep mode since the sleep API is
not available in this case.
In case of single processor solutions these settings may be bypassed by the application code, if the
sleep API is used since it has higher priority.UM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 13 of 15 © 2014 Dialog Semiconductor GmbH
Note that these settings are also used when the chosen memory map is checked against the chosen
sleep mode to verify that the application will be built correctly. Thus, even if the application chooses
to bypass the sleep mode settings in da14580_config.h and use the API, which is strongly
suggested, these settings must be correct and reflect the deepest sleep mode that the application
uses.
For example, an application may use the sleep API to switch between all modes of operation (Active,
Extended sleep and Deep sleep) depending on its current state. In this case, the settings in the file
da14580_config.h should be:
#undef CFG_EXT_SLEEP
#define CFG_DEEP_SLEEP
If the application used only Active and Extended sleep modes then these settings should be:
#define CFG_EXT_SLEEP
#undef CFG_DEEP_SLEEPUM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 14 of 15 © 2014 Dialog Semiconductor GmbH
8 Revision history
Revision Date Description
1.0 28-Mar-2014 Initial version.
1.1 18-Jul-2014 Minor changes, app_last_rwble_evt_get addedUM-B-006
DA14580 Sleep mode configuration Company confidential
User manual Revision 1.1 18-Jul-2014
CFR0012-00 Rev 1 15 of 15 © 2014 Dialog Semiconductor GmbH
Status definitions
Status Definition
DRAFT The content of this document is under review and subject to formal approval, which may result in
modifications or additions.
APPROVED
or unmarked
The content of this document has been approved for publication.
Disclaimer
Information in this document is believed to be accurate and reliable. However, Dialog Semiconductor does not give any
representations or warranties, expressed or implied, as to the accuracy or completeness of such information. Dialog
Semiconductor furthermore takes no responsibility whatsoever for the content in this document if provided by any information
source outside of Dialog Semiconductor.
Dialog Semiconductor reserves the right to change without notice the information published in this document, including without
limitation the specification and the design of the related semiconductor products, software and applications.
Applications, software, and semiconductor products described in this document are for illustrative purposes only. Dialog
Semiconductor makes no representation or warranty that such applications, software and semiconductor products will be
suitable for the specified use without further testing or modification. Unless otherwise agreed in writing, such testing or
modification is the sole responsibility of the customer and Dialog Semiconductor excludes all liability in this respect.
Customer notes that nothing in this document may be construed as a license for customer to use the Dialog Semiconductor
products, software and applications referred to in this document. Such license must be separately sought by customer with
Dialog Semiconductor.
All use of Dialog Semiconductor products, software and applications referred to in this document are subject to Dialog
Semiconductor’s Standard Terms and Conditions of Sale, unless otherwise stated.
© Dialog Semiconductor GmbH. All rights reserved.
RoHS Compliance
Dialog Semiconductor complies to European Directive 2001/95/EC and from 2 January 2013 onwards to European Directive
2011/65/EU concerning Restriction of Hazardous Substances (RoHS/RoHS2).
Dialog Semiconductor’s statement on RoHS can be found on the customer portal https://support.diasemi.com/. RoHS
certificates from our suppliers are available on request.
Contacting Dialog Semiconductor
Germany Headquarters
Dialog Semiconductor GmbH
Phone: +49 7021 805-0
United Kingdom
Dialog Semiconductor (UK) Ltd
Phone: +44 1793 757700
The Netherlands
Dialog Semiconductor B.V.
Phone: +31 73 640 8822
North America
Dialog Semiconductor Inc.
Phone: +1 408 845 8500
Japan
Dialog Semiconductor K. K.
Phone: +81 3 5425 4567
Taiwan
Dialog Semiconductor Taiwan
Phone: +886 281 786 222
Singapore
Dialog Semiconductor Singapore
Phone: +65 64 849929
China
Dialog Semiconductor China
Phone: +86 21 5178 2561
Korea
Dialog Semiconductor Korea
Phone: +82 2 3469 8291
Email:
enquiry@diasemi.com
Web site:
www.dialog-semiconductor.com
776
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
