DA14531 调试笔记

  • Post author:
  • Post category:其他


1、OTP烧录

1.烧写OTP image(你的代码,你会发现代码并没有烧写完0x40000到0x4ffff的地址内容…)

2.在OTP Header界面下Read from memory 读出原有Header配置信息,直接在上面修改以下项:

(Address)0x47F00–(Value)Yes

(Address)0x47F04–(Value)Yes

(Address)0x47FF4–(Value)otp at 0

修改完后再Burn回芯片去,程序就会从otp启动了

3.以上均为个人测试而得,有两个需要注意的:一是otp一次烧写,以后每次烧写都只能覆盖,地址里每一位置1就不能改回  0,所以烧写image需慎重;二是一旦从otp启动,蓝牙的物理id(xx.xx.xx.xx.xx.xx)将由Header表里0x47fd4,0x47fd8这两位的数据而定,而不是代码里写的了。。。这个貌似也可以在代码里修改设定,我还没找到~~

2、低功耗控制

1、user_config.h中将变量 改成这样const static sleep_state_t app_default_sleep_mode=ARCH_SLEEP_OFF;

2、da14580x_config_advanced.h中将  #define CFG_LP_CLK              LP_CLK_RCX20   这里宏定义很重要,如果你外部没有接32K,这里一定要配置成内部,不然进入低功耗起不来

在设完上面的参数后功耗降了很多,而且工作很正常,接着我把程序烧进flash后,能正常在工作。但是当我再次想烧录的时候就是烧不尽,而且在线调试也调不了。最后分析是因为单片机一直进入低功耗,导致下载都不行。所以 最后采用上电后前一分钟不进入低功耗,1分钟后再进入。直接调用这个函数即可arch_set_sleep_mode(ARCH_EXT_SLEEP_ON);

3、IO控制

DA14580 为了把功耗做的很低,在低功耗的模式的时候大部分外设都会关掉,包括IO口

arch_turn_peripherals_off()这个是睡眠之前对配置全部关掉。SetBits16(SYS_CTRL_REG, PAD_LATCH_EN, 0); 这个是锁定管脚

系统唤醒之后会调用外设初始化,periph_init()

在set_pad_functions(),获取IO口状态,然后重新设置

SetBits16(SYS_CTRL_REG, PAD_LATCH_EN, 1)  把引脚从锁死状态下 解开

4、进入低功耗后的问题

在进入扩展睡眠的时候,RAM数据是不保存的,只有在变量后面加

__attribute__((section(“retention_mem_area0”),zero_init))

这个变量才会休眠保存

所以在设计这个任务执行的时候要特别注意,那些变量是进入需要睡眠保存的,避免出现一些很奇怪的问题

在休眠唤醒后也需要先把外设再初始化

if (GetBits16(SYS_STAT_REG, PER_IS_DOWN))

{


periph_init();

}

if (arch_ble_ext_wakeup_get())

{


arch_set_sleep_mode(app_default_sleep_mode);

arch_ble_force_wakeup();

arch_ble_ext_wakeup_off();

app_easy_wakeup();

}

————————————————

版权声明:本文为CSDN博主「未知电子」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/cheng401733277/article/details/95964939

—————————————————————————————————–

DA14580是Dialog公司研制的蓝牙单芯片,号称全球功耗最低,是TI CC2541的四分之一,是运动手环等穿戴类电子产品的常用芯片。但是DA14580的开发门槛不低,适合有蓝牙开发经验的团队来开发,不适合学习爱好者,在网络上搜索DA14580相关的开发文章,基本上都是对官方仅有的几篇文档进行简单翻译,还不如直接阅读英文原文。笔者将对DA14580的系统架构和应用开发框架进行分析,之后再讲解如何进行应用开发。

对于蓝牙单芯片应用开发来说,我们要关注的问题是:蓝牙协议栈方面如何新增一个GATT profile(服务和特征值定义及操作)、SOC内核方面如何驱动外围设备、系统应用框架上如何使用定时器和任务间消息通信等等。DA14580单芯片发布时并不是一颗裸片,而是带有开发平台和SDK包,还有常用的应用例程(如防丢proximity),我们要做的就是通过SDK和相关的文档去理解它整个系统架构和应用框架,在这个基础上才能去完成以上三个方面的开发。

一、DA14580系统架构

DA14580是基于Cortex M0架构,内置ROM、OTP和RAM。其中ROM固化了大部分协议栈和操作系统(单任务)的代码实现,而OTP一次性编程则是为了降低成本,实现用户的差异化应用需求。当用户通过SPI NORFLASH引导或者直接通过JLINK下载代码到RAM进行调试后,就可以通过SmartSnippets工具下载代码到OTP。量产产品即从OTP开始引导执行。

DA14580集成的是第三方公司RW的蓝牙协议栈IP,范围包括GAT和GAP层及以下。因此我们可以在代码框架目录上看到RW开头命名的目录和头文件,官方文档涉及到蓝牙协议栈方面大部分都是RW公司出品。

二、DA14580 开发例程目录和SDK目录结构

DA14580的SDK开发平台使用keil,我们先来看看开发例程的目录结构,再来看SDK目录结构。前者简单一些,后者因为涉及到第三方IP、ROM等原因,目录实在是太多太细了,初接手真的会歇菜。

防丢(proximity,英文是接近的意思)的开发目录结构如下:

这里需要注意的是,ROM里面的固话代码,包括协议栈和单任务操作系统的相关管理代码也是整个工程应用的一部分,只不过没有列到开发目录里面。

SDK目录架构如下:

三、蓝牙profile和应用的角色和分工

从工程的代码目录结构来看,每个profile都有一个以profile(如proxr)命名的.c文件,也有一个以profile_task(如proxr_task)命名的.c文件;相应地,每个应用子任务也有一个app_profile(如app_proxr)的.C文件,和app_profile_task(如app_proxr_task)的.c文件。一般地:

在操作系统ke内核看来,Profile和profile_task共同完成一个task任务,其中app_proxr_task的task ID标识是TASK_PROXR。但app_profile和app_profile_task并不是一个具体的task任务,在代码目录的app目录,所有的task,包括app_proxr_task和app_batt_task(电池)、app_sec_task(安全)共同组成一个task,在app.c中完成任务创建,task的ID标识是TASK_APP。各个app_profile_task只不过完成应用的一个子场景功能,如防丢、电池告警等。

app是主动发送消息给profile,以执行相应的蓝牙GATT服务和操作,并接受回调。即app是profile的上层。

Profile任务执行GATT服务/属性的具体创建create、开启服务enable和属性特征的读写等操作,其调用ATT和GAP等底层接口来实现具体功能。Profile作为接口供给app层调用,app是通过消息通信来完成接口调用的。

app_profile的代码一般包括主动调用的接口实现,而app_profile_task则是接受消息回调的接口实现。两者的分工是非常清晰的。

四、应用开发框架

DA14580的应用开发框架的核心是基于状态机和消息回调。以下分析以防丢proxr为例。

1.    状态机

每个任务都必须明确自己的状态表,例如proxr的状态表是:

状态的初始化和转换是由用户主动切换的。在某个确定的状态时,内核会在对应的状态响应接口集中遍历所有发给该任务的消息。

每个任务都会在初始化时被创建,例如proxr任务的创建是:

这时,假设有个其他的任务发一个消息给TASK_PROXR,则会在proxr_disabled中查找相应的消息回调接口,并执行回调。

2.    消息回调

接下来看看各个状态的响应接口集,例如PROXR_CONNECTED连接状态时的状态响应接口集如下。可见,其会对两个消息进行回调,一个是底层ATT收到对特征值的写操作时执行回调,另一个应用层主动改写另一个特征值。在笔者的防丢和计步应用中,前者是实现防丢告警功能,后者是上报计步数据。

3.    任务间通信

消息发出之后,系统即会执行proxr_jibu_update_req_handler回调。

另外,笔者会根据文章的阅读量考虑进一步对DA14580的SDK进行分析,如系统启动过程、服务建立过程以及上面说的,如何进行应用开发,即蓝牙协议栈方面如何新增一个GATT profile(服务和特征值定义及操作)、SOC内核方面如何驱动外围设备、系统应用框架上如何使用定时器和任务间消息通信等等

————————————————

版权声明:本文为CSDN博主「吴跃前」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/yueqian_scut/article/details/50274825