你好,
我们正在使用自定义DA 14585董事会。来自Flash的电路板靴子，因为我们不使用默认的SPI引脚，我们已将次级引导加载程序编程到OTP中。睡眠模式延长（没有OTP拷贝）。我们面临的问题是：
1.延长睡眠的代码在hw中闪现时，显示出不一致的行为。它会发布一段时间，然后进入无响应状态。
2.相同的代码，睡眠禁用，当闪存到HW中时，工作正常
3.通过RAM运行时启用扩展睡眠的代码(使用keil调试器)工作良好。
我们的设计中包括了32khz和16Mhz的晶体。
原因可能是什么呢?请建议。
谢谢
设备:
嗨Wisilica，
我无法弄清楚这种行为的任何明显，我可以提到一些事情，以便你测试。
如果你在flash中刻录SDK项目并启动该项目，你会看到相同的行为吗?你能估计这个设备做多长时间的广告吗?我假设设备是在它保持清醒时发布的，在它睡觉时停止运行，所以试着从fw切换到RCX而不是XTAL32。你可以尝试使用默认引脚(也许在开发套件)从flash启动你的fw，并检查是否有任何不同?
在这篇文章中，关于从特定的SPI引脚引导，我还漏掉了一些东西https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...在585中除了燃烧次要引导加载程序在OTP从特定引脚引导585包括一个机制，以便从特定引脚引导，这可以定义在启动特定映射字段的OTP头，你将能够在附录G和585的数据表4.3.1 OTP头段落中找到信息，尽管我不认为你正在观察的行为的原因是你已经烧毁了OTP中的二级引导加载程序。
由于MT_dialog
你好,
感谢您的及时回复。我已经尝试了你提到的事情，结果如下:
1.我没有把我们的应用程序fw编程成flash，而是把最基本的项目编程成flash，默认的睡眠模式被选择为扩展模式。该行为保持不变，即设备发布约3 - 4个报文，然后进入无响应状态。
2.还尝试将CFG_LP_CLK设置为LP_CLK_RCX20，但问题仍然存在。
3.尝试使用Booter将固件直接加载到RAM中，然后设备正常通告。
4.在开发板中尝试相同的固件(即SPI pin的默认配置)，设备工作良好。
我还配置了OTP头，以便从SPI引脚引导如下:
Spi CLK = p0_0, spi_en = p0_1, spi_di = p0_2, spi_do = p0_3
启动=正常顺序，唤醒命令代码= 00，串行速度选择0
配置有什么问题吗?
此外，在辅助引导加载程序固件中，惟一的更改是定义SPI_FLASH_SUPPORTED和SUPPORT_AN_B_001，并根据我们的原理图配置SPI引脚。
请说明以上问题的原因。
谢谢
嗨Wisilica，
既然您已经指出引导序列应该从特定的SPI引脚完成，那么引导标志不应该是0x00(正常序列)，而是0xAA(从特定位置的SPI端口引导)。此外，如果您已经烧毁了OTP中的辅助引导加载程序，设备仍将使用辅助引导加载程序而不是串行引导顺序引导。但是我不认为你正在使用辅助引导加载程序的事实会导致无响应的行为，在所有的设备启动和fw运行之后，所以只要你有延长的睡眠，而不是(OTP_COPY_ON)设备应该保留fw。你也可以尝试通过调试器来调试这是附加为了还注意完全弗兰克-威廉姆斯的摊位和监控电力事故前后为了注意如果设备是睡觉和醒来或如果它已经陷入一个断言。
由于MT_dialog
你好,
通过调试器(RAM)运行fw，设备不会停止。我还检查了加载fw直接进入RAM通过booter，它工作良好。只有当它从flash启动时才会发生这个问题。
谢谢
嗨Wisilica，
上面提出的是在设备从Flash启动时附加兼容，此问题发生了，以便尝试和检查设备丢失并检查它是否有助于调试问题（只是启动等待insident。发生然后附加调试器 - 为了在“调试”选项卡中将调试器通过keil删除初始化文件，然后点击设置按钮，取消选中“连接后的”重置“。由于设备似乎卡住时的第二个引导加载程序运行时，可能遇到的是与该事实有关，也许这是辅助引导加载程序的问题，并且从OTP运行后它不会重置寄存器或类似的东西。设备睡眠休眠状态（尽管从RAM运行辅助引导加载程序和上面的案例和BLE_APP_PERITERAL配置的SPI引脚）运行辅助引导程序，但是设备可以直接从指定的引脚上直接从SPI闪存启动并运行它应该，我再也不能将辅助引导加载程序与设备摊位的事实相连。您还应该尝试将OTP标题刻录到启动特定的映射标志设置为您想要的引脚并检查设备是否操作。
由于MT_dialog
你好,
我们如何在运行时将调试器附加到电路板上？重新供电后，设备开始从闪存启动，然后在几秒钟后停止。我们什么时候需要启动调试会话？我想调试会话，将固件转化为RAM。那么，我们如何知道代码停止的点？
此外，应用程序编程标志1和2配置为YES，OTP DMA长度为1FC0和SWD使能标志作为在OTP标题中启用的JTAG。同一的快照附上（OTP标题智能片段）。请看看是否缺少任何配置。
同样，这个问题也不是一直发生。在某些运行相同的固件，没有观察到的问题，设备工作正常。请说明原因。
谢谢
嗨Wisilica，
使用相同的项目,你有使用为了构建.hex文件烧到flash,引导你通常做的从flash设备,然后遵循上面的指令我提供为了防止凯尔下载一个图像的设备,防止重置JTAG (为了通过Keil在“调试”选项卡中附加调试器，删除初始化文件，然后点击设置按钮，取消勾选“连接后重置”）.之后,只要按“启动/停止调试会话”,你将能够连接到自定义委员会(你不应该重置设备附加JTAG之前或让凯尔为你这么做,这就是为什么你应该首先准备以上设置,然后启动程序,例如,你点击“设置”jlink将重置设备，如果“连接后重置”被选中)。点击“停止”按钮以停止执行(或弗兰克-威廉姆斯可能已经停止),检查装配模式如果设备在你能看到的地方,通过映射文件你将能够看到设备已经停止的功能。
关于您对OTP的设置，由于设备能够从SPI正确启动镜像过程确定，因此只有在设备关闭SYSRAM时才能编程OTP DMA，因为它也仅在SYSRAM关闭时使用因此，OTP将不得不知道要在唤醒时复制多少数据（也是您所放置的值为580，其中有一个较小的OTP，但在任何情况下，这不应该对您所在的内容产生任何影响）．无论如何，还燃烧了一个585个设备，具有辅助引导加载程序并从指示的SPI引脚启动，设备再次运行，因为它应该没有问题。
如果该问题并非一致，那么这是否意味着即使在FW通过JTAG下划线时，也可能发生问题？因此，可能存在问题和通过闪存下载之间没有连接？
由于MT_dialog
你好,
到目前为止，我们还没有发现fw直接加载到RAM中的问题。另外，在构建代码时，各个内存段的大小如下:
程序大小:Code=20808 RO-data=2892 RW-data=600 ZI-data=8400
这和这个问题有什么关系吗?
现在，在单击start debug session选项卡，然后在停止它时，我无法查看程序集窗口。是否缺少任何设置?
谢谢
嗨Wisilica，
您已发布的是从keil生成的二进制文件的大小，不必为您所在的内容做任何事情。已发布的值是代码（20808）RO数据（2892）的大小是常量数据的大小，RW Data（600）是您的变量，Zi数据（8400）是零初始化变量的大小。请检查上面提到的内容，并尝试使用简单的BLE SDK示例，并检查是否发生了相同的问题。关于拆卸窗口，您必须启用它才能查看拆卸窗口，只需进入“视图”，然后单击“拆分窗口”。
由于MT_dialog
你好,
正如您所建议的，我尝试了ble_app_barebone项目。我所做的唯一更改是将默认睡眠模式设置为ARCH_EXT_SLEEP_ON。这个问题甚至在这个案例中也被观察到了。
现在，在重新启动单板以从flash启动之后，并单击start debug session选项卡之后，将显示拆卸窗口，并突出显示以下行(附带的快照)。
这是什么意思?
谢谢
你好,
此外，我已经附加的骨干项目十六进制文件，使用中卡住了。唯一的改变是将睡眠模式设置为扩展模式。
请尝试使用我已分享的固件，在可以从我之前描述的引脚启动的电路板中。
CLK - p0_1, cs - p0_1, di - p0_2, do - p0_3
谢谢
从keil图像，你附加的设备似乎没有停止(在反汇编窗口指示设备从内存加载一个地址)，我认为，如果你按下“运行”按钮，而附加的是你可以运行代码。
部分的代码,你看到在拆卸窗口是指令执行后恢复从睡梦中为了获取arch_resume_from_sleep()函数,这意味着该设备不停止,但代码继续执行时,设备将停止在这里附加调试器。所以在我看来，尽管你无法在电视上看到这个装置，但它仍然可以运行。
所以据我所知，设备是运行的，我们有唯一的线索是，当加载通过二级引导加载程序，然后flash后，几个广告字符串发射你不能看到任何广告了。下一步是检查设备的功耗，你可以从pro套件中为定制板供电，并使用功率分析器来检查设备的功耗，这将让我们知道设备是否真的发射广告字符串，由于某些原因，另一边的设备不能接收(例如，您的XTAL16可能是关闭的，您的传输不在相同的频率)，或者，如果由于某些原因，它丢失了BLE事件，并且没有执行广告就醒来了(由于某些原因，它醒来太晚了，栈取消了BLE活动)，您是否执行了任何温度测试并得到了该问题?你也应该检查一下电源是否有掉落。
测试的弗兰克-威廉姆斯上传并运行它从一个设备烧毁二级引导装载程序的OTP引导针表示,弗兰克-威廉姆斯正确引导广告没有问题,我可以正常连接,我假设你正在经历什么是由于h / w的问题,而不是由于引导加载程序或闪存的sw。
最后，值得在另一个板上尝试，使用“引导特定映射”字段而不是辅助引导加载程序。
由于MT_dialog