定制板DA 14585-行为差异

⚠️
嗨,...感谢您来论坛。令人兴奋的消息!我们现在正在迁至我们的新论坛平台,将提供更好的功能,并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
13个职位/0个新职位
最后一篇
Wisilica.
离线
最后一次见到:11个月1周前
加入:2015-03-17 08:16
定制板DA 14585-行为差异

你好,

我们正在使用自定义DA 14585董事会。来自Flash的电路板靴子,因为我们不使用默认的SPI引脚,我们已将次级引导加载程序编程到OTP中。睡眠模式延长(没有OTP拷贝)。我们面临的问题是:
1.启用扩展睡眠的代码,当闪烁到HW中时,显示不一致的行为。它发布了一段时间,然后进入非响应状态。
2.相同的代码,睡眠禁用,当闪存到HW中时,工作正常
3.通过RAM(使用keil调试器)运行时启用扩展睡眠的代码工作正常。

我们的设计中包括了32khz和16Mhz晶体。

为什么会这样?请建议。

谢谢

设备:
MT\u对话框
离线
最后一次见到:3个月3天前
职员
加入:2015-06-08 11:34
嗨Wisilica,

嗨Wisilica,

我无法弄清楚这种行为的任何明显,我可以提到一些事情,以便你测试。

如果您在flash中烧录一个SDK项目并启动该项目,您会看到相同的行为吗?你能估计一下这个设备的广告时间吗?我假设这个设备在保持清醒的时候会做广告,在进入睡眠状态时会暂停,所以试着从fw切换到RCX而不是XTAL32。你能试着用默认的pin(也许在dev工具包上)从flash启动你的固件并检查这是否有什么不同吗?

在这篇文章中,我还漏掉了一些关于从特定SPI引脚引导的内容https://support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...在585中,除了从特定引脚启动的OTP中刻录的辅助引导加载程序外,585还包括一个机制,以便从特定引脚引导,这可以在OTP标题的引导特定映射字段中定义,您将能够找到附录G和4.3.1 OTP标题段落中的585的数据表中的信息,尽管我不认为您观察到的行为的原因是您在OTP中刻录了辅助引导加载程序。

谢谢你的对话

Wisilica.
离线
最后一次见到:11个月1周前
加入:2015-03-17 08:16
你好,

你好,

谢谢你的及时回复。我试过你提到的东西,结果如下:
1.我没有使用我们的应用程序fw,而是将barebone项目编程到flash中,默认睡眠模式选择为extended。行为保持不变,即,设备播发大约3-4个数据包,然后进入无响应状态。
2.还尝试将CFG\u LP\u CLK设置为LP\u CLK\u RCX20,但问题仍然存在。
3.尝试使用Booter将固件直接加载到RAM中,然后设备正常通告。
4.在开发板中尝试了相同的固件(即SPI引脚的默认配置),设备运行良好。

我还配置了OTP头以便从SPI引脚引导,如下所示:

SPI CLK=P0\ U 0,SPI\ U EN=P0\ U 1,SPI\ U DI=P0\ U 2,SPI\ U DO=P0\ U 3
引导=正常顺序,唤醒命令代码=00,串行速度选择0

配置有问题吗?
此外,在二级引导加载程序固件中,所做的唯一更改是定义SPI_FLASH_SUPPORTED和SUPPERT_AN_B_001,并根据我们的原理图配置SPI引脚。

请说明上述问题的原因。

谢谢

MT\u对话框
离线
最后一次见到:3个月3天前
职员
加入:2015-06-08 11:34
嗨Wisilica,

嗨Wisilica,

既然您已经指出引导序列应该从特定的SPI引脚完成,那么引导标志就不应该是0x00(正常序列),而是0xAA(从特定位置的SPI端口引导)。另外,如果您已经在OTP中烧掉了辅助引导加载程序,那么设备仍将使用辅助引导加载程序而不是串行引导序列进行引导。不过,我也不认为使用辅助引导加载程序会导致无响应的行为,毕竟设备正在引导,固件正在运行,所以只要您有延长的睡眠时间,而不是(OTP\u COPY\u ON),设备就应该保留固件。您还可以尝试调试的是,通过调试器进行连接,以便知道fw到底在哪里暂停,并在崩溃前后监视电源,以便知道设备是否正在睡眠而没有醒来,或者是否已卡在断言中。

谢谢你的对话

Wisilica.
离线
最后一次见到:11个月1周前
加入:2015-03-17 08:16
你好,

你好,
通过调试器(RAM)运行fw,设备不会停止。我还检查了通过booter将fw直接加载到RAM中的方法,它工作得很好,只有从flash引导时才会出现问题。

谢谢

MT\u对话框
离线
最后一次见到:3个月3天前
职员
加入:2015-06-08 11:34
嗨Wisilica,

嗨Wisilica,

上面提出的是在设备从Flash启动时附加兼容,此问题发生了,以便尝试和检查设备丢失并检查它是否有助于调试问题(只是启动等待insident。发生然后附加调试器 - 为了在“调试”选项卡中将调试器通过keil删除初始化文件,然后点击设置按钮,取消选中“连接后的”重置“。由于设备似乎卡住时的第二个引导加载程序运行时,可能遇到的是与该事实有关,也许这是辅助引导加载程序的问题,并且从OTP运行后它不会重置寄存器或类似的东西。设备睡眠休眠状态(尽管从RAM运行辅助引导加载程序和上面的案例和BLE_APP_PERITERAL配置的SPI引脚)运行辅助引导程序,但是设备可以直接从指定的引脚上直接从SPI闪存启动并运行它应该,我再也不能将辅助引导加载程序与设备摊位的事实相连。您还应该尝试将OTP标题刻录到启动特定的映射标志设置为您想要的引脚并检查设备是否操作。

谢谢你的对话

Wisilica.
离线
最后一次见到:11个月1周前
加入:2015-03-17 08:16
你好,

你好,
我们如何在运行时将调试器附加到电路板上?重新供电后,设备开始从闪存启动,然后在几秒钟后停止。我们什么时候需要启动调试会话?我想调试会话,将固件转化为RAM。那么,我们如何知道代码停止的点?

此外,应用程序编程标志1和2配置为YES,OTP DMA长度为1FC0和SWD使能标志作为在OTP标题中启用的JTAG。同一的快照附上(OTP标题智能片段)。请看看是否缺少任何配置。

此外,问题不会一致。在某些运行相同的固件中,未观察到该问题,设备正常工作。请暗示它的原因。

谢谢

MT\u对话框
离线
最后一次见到:3个月3天前
职员
加入:2015-06-08 11:34
嗨Wisilica,

嗨Wisilica,

使用您使用的相同项目来构建已刻录到Flash的.hex文件,根据您通常执行的,从闪存启动设备,然后按照上面提供的指令,以防止Keil下载设备的图像并防止JTAG重置(为了在“调试”选项卡中通过Keil连接调试器,请删除初始化文件,然后点击设置按钮并取消选中“连接后重置”)。在这样做只是点击“开始/停止调试会话”而且您将能够附加到自定义板(在附加JTAG之前,您不应该重置设备,或者让Keiil为您做这一点,这就是您应该首先准备的原因上述设置然后启动过程,例如,当检查“连接后”时,jlink将重置设备。击中“停止”按钮以停止执行(或FW可能已停止)并在装配模式中检查如果设备粘在某个地方,您将能够看到此问题和通过地图文件,您将能够查看哪个功能停止了。

关于您对OTP的设置,由于设备能够从SPI正确启动镜像过程确定,因此只有在设备关闭SYSRAM时才能编程OTP DMA,因为它也仅在SYSRAM关闭时使用因此,OTP将不得不知道要在唤醒时复制多少数据(也是您所放置的值为580,其中有一个较小的OTP,但在任何情况下,这不应该对您所在的内容产生任何影响)。无论如何,还燃烧了一个585个设备,具有辅助引导加载程序并从指示的SPI引脚启动,设备再次运行,因为它应该没有问题。

如果该问题并非一致,那么这是否意味着即使在FW通过JTAG下划线时,也可能发生问题?因此,可能存在问题和通过闪存下载之间没有连接?

谢谢你的对话

Wisilica.
离线
最后一次见到:11个月1周前
加入:2015-03-17 08:16
你好,

你好,

我们在直接将FW加载到RAM中,我们没有观察到这个问题。此外,在构建代码时,各种内存部分的大小如下:

程序尺寸:码= 20808 RO-DATA = 2892 RW-DATA = 600 ZI-DATA = 8400

这跟这个问题有关系吗?

现在,单击“开始调试会话”选项卡,然后在停止它时,我无法查看“装配”窗口。有没有任何设置缺失?

谢谢

MT\u对话框
离线
最后一次见到:3个月3天前
职员
加入:2015-06-08 11:34
嗨Wisilica,

嗨Wisilica,

您已发布的是从keil生成的二进制文件的大小,不必为您所在的内容做任何事情。已发布的值是代码(20808)RO数据(2892)的大小是常量数据的大小,RW Data(600)是您的变量,Zi数据(8400)是零初始化变量的大小。请检查上面提到的内容,并尝试使用简单的BLE SDK示例,并检查是否发生了相同的问题。关于拆卸窗口,您必须启用它才能查看拆卸窗口,只需进入“视图”,然后单击“拆分窗口”。

谢谢你的对话

Wisilica.
离线
最后一次见到:11个月1周前
加入:2015-03-17 08:16
你好,

你好,

正如你所建议的,我尝试了ble\u app\u barebone项目。我所做的唯一更改是将默认睡眠模式设置为ARCH\u EXT\u sleep\u ON。即使在这种情况下,也观察到了这个问题。
现在,在重新启动电路板以从flash引导之后,在单击startdebug session选项卡之后,将显示反汇编窗口,并高亮显示下面的行(附加的快照)。
这是什么意思?

谢谢

附件:
Wisilica.
离线
最后一次见到:11个月1周前
加入:2015-03-17 08:16
你好,

你好,

此外,我还附加了barebone项目十六进制文件,用于卡住中途。唯一的改变是将睡眠模式设置为延长。
请尝试使用我已分享的固件,在可以从我之前描述的引脚启动的电路板中。

CLK-P0 0,CS-P0 1,DI-P0 2,DO-P0 3

谢谢

MT\u对话框
离线
最后一次见到:3个月3天前
职员
加入:2015-06-08 11:34
从keil的照片来看

从您附加的keil图像来看,似乎设备没有停止(反汇编窗口中的指令指示设备正在从内存加载地址),我想如果您在附加时按“Run”按钮,您就可以运行代码了。

您在拆卸窗口中看到的代码的部分是从睡眠中恢复后执行的指令,以便获取ARCH_RESUME_FROM_SLEEP()函数,这意味着设备不会停止,但代码继续执行,这是在哪里安装调试器时,设备将停止。因此,在我的角度来看,尽管您无法在空中看到设备,但该设备仍然运营。

因此,就我可以告诉设备正在运营,以及我们拥有的唯一线索是,当通过次级引导加载程序加载时,闪存后闪烁少数广告字符串,您无法再查看任何广告。下一步是检查设备的功耗,您可以从Pro套件中电源电源,并使用电源分布器来检查设备的功耗,这将告诉我们设备是否实际上Emmiting广告字符串和某种原因,另一侧的设备无法接收(例如,您的XTal16可能关闭,您的XTal16可能在同一频率下发送),或者由于某种原因它丢失了BLE事件并唤醒了如果没有执行广告(出于某种原因,它醒来时太晚并且堆栈取消了BLE活动),您是否正在执行任何温度测试,并且您获得该问题?您也可能想检查任何丢弃的电源。

测试了您已上传并从设备上从OTP引导中的烧焦的辅助引导加载程序从您所指示的引脚中进行的设备进行了测试,并使用无问题的FW正确启动的FW,我可以正确连接它,我想是什么you are experiencing is due to a h/w issue, and not due to the bootloader or the sw that the flash has.

最后,值得在另一块板上尝试,使用“Boot specific mapping”字段而不是辅助引导加载程序。

谢谢你的对话