Hi,
我们正在使用自定义DA 14585董事会。来自Flash的电路板靴子，因为我们不使用默认的SPI引脚，我们已将次级引导加载程序编程到OTP中。睡眠模式延长（没有OTP副本）。我们面临的问题是：
1.扩展的代码启用了睡眠,当n flashed into the hw, shows inconsistent behaviour. It advertises for some time, and then enters a non responsive state.
2.相同的代码，睡眠禁用，当闪存到HW中时，工作正常
3.通过RAM运行时启用扩展睡眠的代码（使用Keil调试器），工作正常。
我们在我们的设计中包含32kHz和16MHz晶体。
什么可能是同样的原因？请建议。
谢谢
设备：
嗨Wisilica，
我无法弄清楚这种行为的任何明显，我可以提到一些事情，以便你测试。
如果在闪存中刻录SDK项目并启动该项目，您可以看到相同的行为吗？你能估计设备广告的时间吗？我会假设该设备在睡眠中保持清醒和摊位的同时宣传，因此尝试从FW切换到RCX而不是XTAL32。您可以尝试使用默认引脚（可能在Dev套件上）从Flash启动FW）并检查是否有任何区别？
在这篇文章中，我也错过了一些关于从特定的SPI引脚启动的东西https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-bl ...in the 585 besides burning the secondary bootloader in the OTP for booting from specific pins the 585 includes a mechanism in order to boot from specific pins and this can be defined in the Boot Specific mapping field of the OTP header, you will be able to find info in the Appendix G and in the datasheet of the 585 in the 4.3.1 OTP Header paragraph, although i dont think that the reason for the behaviour that you are observing is that you 've burned the secondary bootloader in the OTP.
谢谢mt_dialog.
Hi,
感谢你的及时回复。我试过了你提到的事情，结果如下：
1.而不是我们的应用程序FW，我已经编写了鞍骨项目，默认睡眠模式选择了延伸到闪存中。该行为保持不变，即设备广告约3-4个分组，然后进入非响应状态。
2.还尝试将CFG_LP_CLK设置为LP_CLK_RCX20，但问题仍然存在。
3.尝试使用Booter将固件直接加载到RAM中，然后设备正常通告。
4.在开发板中尝试了相同的固件（即SPI引脚的默认配置），设备工作正常。
我还配置了OTP标题，以便从SPI引脚引导如下：
SPI CLK = P0_0，SPI_EN = P0_1，SPI_DI = P0_2，SPI_DO = P0_3
boot =正常序列，唤醒命令代码= 00，串行速度选择0
配置中有什么不妥吗？
Also, in the secondary bootloader firmware, the only changes made was to define the SPI_FLASH_SUPPORTED and SUPPORT_AN_B_001, and to configure the SPI pins as per our schematic.
请建议上述问题的原因。
谢谢
嗨Wisilica，
由于您已表示从特定SPI引脚完成引导序列，则引导标志不应为0x00（正常序列）但0xAA（从特定位置的SPI端口引导）。此外，如果您已经刻录刻录，则OTP中的辅助引导加载程序仍将使用辅助引导程序和不是串行引导序列引导。但是，我不认为你使用的辅助引导加载程序的事实会导致无响应的行为，之后所有设备都启动和FW运行，所以只要您拥有延长的睡眠而不是（OTP_COPY_ON）设备保留FW。您也可以尝试调试此操作是通过调试器附加，以便意识到FW摊位的位置，并且在崩溃之前和之后监控电源，以便知道设备是否睡觉，而不是唤醒或者它陷入了断言。
谢谢mt_dialog.
Hi,
通过通过调试器（RAM）运行FW，设备不会停止。我还通过Booter将FW直接加载到RAM中，并且它效果正常。只有在Flash启动时才出现问题。
谢谢
嗨Wisilica，
上面提出的是在设备从Flash启动时附加兼容，此问题发生了，以便尝试和检查设备丢失并检查它是否有助于调试问题（只是启动等待insident。发生然后附加调试器 - 为了在“调试”选项卡中将调试器通过keil删除初始化文件，然后点击设置按钮，取消选中“连接后的”重置“。由于设备似乎卡住时的第二个引导加载程序运行时，可能遇到的是与该事实有关，也许这是辅助引导加载程序的问题，并且从OTP运行后它不会重置寄存器或类似的东西。设备睡眠休眠状态（尽管从RAM运行辅助引导加载程序和上面的案例和BLE_APP_PERITERAL配置的SPI引脚）运行辅助引导程序，但是设备可以直接从指定的引脚上直接从SPI闪存启动并运行它应该，我再也不能将辅助引导加载程序与设备摊位的事实相连。您还应该尝试将OTP标题刻录到启动特定的映射标志设置为您想要的引脚并检查设备是否操作。
谢谢mt_dialog.
Hi,
我们如何在运行时将调试器附加到电路板上？重新供电后，设备开始从闪存启动，然后在几秒钟后停止。我们什么时候需要启动调试会话？我想调试会话，将固件转化为RAM。那么，我们如何知道代码停止的点？
此外，应用程序编程标志1和2配置为YES，OTP DMA长度为1FC0和SWD使能标志作为在OTP标题中启用的JTAG。同一的快照附上（OTP标题智能片段）。请看看是否缺少任何配置。
Also, the issue does not happen consistently. In certain runs of the same firmware, the issue is not observed, and the device works correctly. Kindly suggest the reasons for the same.
谢谢
嗨Wisilica，
Use the same project that you have used in order to build the .hex file that you have burned into the flash, boot the device from flash as you normally do and then follow the instruction i 've provided above in order to prevent keil to download an image to the device and prevent the reset from the JTAG (要在“debug”选项卡中通过keil附加调试器，请删除初始化文件，然后点击设置按钮并取消选中“连接后的”重置“). After doing that just hit the "Start/Stop Debug Session" and you will be able to attach to the custom board (you should not reset the device before attaching the JTAG or let keil do that for you, that is why you should first prepare the above settings and then start the procedure, for example, of you hit the "Settings" the jlink will reset the device if the "Reset after Connect" is checked). The hit the "Stop" button in order to stop execution (or the fw might be allready halted) and check in assembly mode if the device is stuck somewhere you will be able to see this and via the map file you will able to see on which function the device has stopped.
关于您对OTP的设置，由于设备能够从SPI正确启动镜像过程确定，因此只有在设备关闭SYSRAM时才能编程OTP DMA，因为它也仅在SYSRAM关闭时使用因此，OTP将不得不知道要在唤醒时复制多少数据（也是您所放置的值为580，其中有一个较小的OTP，但在任何情况下，这不应该对您所在的内容产生任何影响）。无论如何，还燃烧了一个585个设备，具有辅助引导加载程序并从指示的SPI引脚启动，设备再次运行，因为它应该没有问题。
如果该问题并非一致，那么这是否意味着即使在FW通过JTAG下划线时，也可能发生问题？因此，可能存在问题和通过闪存下载之间没有连接？
谢谢mt_dialog.
Hi,
We have not observed the issue while loading the fw directly into RAM till now. Also, on building the code, the size of various memory sections is as follows:
Program Size: Code=20808 RO-data=2892 RW-data=600 ZI-data=8400
这与问题有什么关系吗？
Now, on clicking the start debug session tab, and then on stopping it, I am not able to view the assembly window. Are there any settings missing ?
谢谢
嗨Wisilica，
您已发布的是从keil生成的二进制文件的大小，不必为您所在的内容做任何事情。已发布的值是代码（20808）RO数据（2892）的大小是常量数据的大小，RW Data（600）是您的变量，Zi数据（8400）是零初始化变量的大小。请检查上面提到的内容，并尝试使用简单的BLE SDK示例，并检查是否发生了相同的问题。关于拆卸窗口，您必须启用它才能查看拆卸窗口，只需进入“视图”，然后单击“拆分窗口”。
谢谢mt_dialog.
Hi,
正如您所建议的那样，我尝试了BLE_APP_BAREBONE项目。我所做的唯一变更将默认休眠模式设置为ARCH_EXT_SLEEP_ON。即使在这种情况下，也观察到这个问题。
现在，重新重新计算机后从Flash启动后，并在单击“开始调试会话”选项卡后，显示“拆卸”窗口，并突出显示以下行（附加快照）。
这是什么意思 ？
谢谢
Hi,
此外，我已经附上了鞍骨项目十六进制文件，使用中途粘在一起。所做的唯一变更是将睡眠模式设置为扩展。
请尝试使用我已分享的固件，在可以从我之前描述的引脚启动的电路板中。
CLK - P0_0，CS - P0_1，DI - P0_2，DO - P0_3
谢谢
从您所附加的Keil图像似乎没有停止（拆卸窗口中的指令指示设备正在从内存加载地址），我想如果您在附加时按“运行”按钮您可以运行代码。
The portion of the code that you see in the disassembly window is the instruction executed right after resuming from sleep in order to fetch the arch_resume_from_sleep() function, that means that the device doesn't halt but the code keeps on executing and this is where the device will stop when attaching the debugger. So in my point of view the device still operates despite the fact that you are not able to see the device on the air.
So as far as i can tell the device is operating, and the only clue that we have is that when loaded via secondary bootloader and then the flash after a few advertising strings emmited you are not able to see any advertising anymore. The next step would be to check the power consumption of the device, you can power the custom board from the pro kit and use the power profiler in order to check the power consumption of the device, this will let us know if the device is actually emmiting advertising strings and for some reason the device on the other side isn't capable receiving (for example your XTAL16 perhaps is off and your dont transmit at the same frequencies), or if for some reason it looses the BLE events and just wakes up without executing the advertising (for some reason it wakes up too late and the stack cancels the BLE activity), are you performing any temperature tests and you get that issue ? Also you might wanna check the power source for any drops.
Tested the fw that you have uploaded and run it from a device with a burned secondary bootloader in the OTP booting from the pins that you have indicated, the fw properly booted advertised with no issue and i could properly connect on it, i suppose that what you are experiencing is due to a h/w issue, and not due to the bootloader or the sw that the flash has.
最后它值得在不同的板上尝试这个，并使用“引导特定映射”字段而不是辅助引导加载程序。
谢谢mt_dialog.