你好，
We are working on a custom DA 14585 board. The board boots from flash, and since we are not using the default SPI pins, we have programmed the secondary bootloader into the OTP. The sleep mode is extended(without OTP copy). The issues we are facing is :
1.启用扩展睡眠的代码，当闪烁到HW中时，显示不一致的行为。它发布了一段时间，然后进入非响应状态。
2. The same code, with sleep disabled, when flashed into the hw, works fine
3.通过RAM（使用keil调试器）运行时启用扩展睡眠的代码工作正常。
我们的设计中包括了32khz和16Mhz晶体。
为什么会这样？请建议。
Thanks
设备：
Hi wisilica,
I am not able to figure out anything obvious for that behaviour, i can mention a few things in order for you to test.
如果您在flash中烧录一个SDK项目并启动该项目，您会看到相同的行为吗？你能估计一下这个设备的广告时间吗？我假设这个设备在保持清醒的时候会做广告，在进入睡眠状态时会暂停，所以试着从fw切换到RCX而不是XTAL32。你能试着用默认的pin（也许在dev工具包上）从flash启动你的固件并检查这是否有什么不同吗？
在这篇文章中，我还漏掉了一些关于从特定SPI引脚引导的内容https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl...在585中，除了从特定引脚启动的OTP中刻录的辅助引导加载程序外，585还包括一个机制，以便从特定引脚引导，这可以在OTP标题的引导特定映射字段中定义，您将能够找到附录G和4.3.1 OTP标题段落中的585的数据表中的信息，尽管我不认为您观察到的行为的原因是您在OTP中刻录了辅助引导加载程序。
谢谢你的对话
你好，
谢谢你的及时回复。我试过你提到的东西，结果如下：
1.我没有使用我们的应用程序fw，而是将barebone项目编程到flash中，默认睡眠模式选择为extended。行为保持不变，即，设备播发大约3-4个数据包，然后进入无响应状态。
2.还尝试将CFG\u LP\u CLK设置为LP\u CLK\u RCX20，但问题仍然存在。
3. Tried loading the firmware directly into RAM using booter, and then the device advertises properly.
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引脚。
请说明上述问题的原因。
Thanks
Hi wisilica,
既然您已经指出引导序列应该从特定的SPI引脚完成，那么引导标志就不应该是0x00（正常序列），而是0xAA（从特定位置的SPI端口引导）。另外，如果您已经在OTP中烧掉了辅助引导加载程序，那么设备仍将使用辅助引导加载程序而不是串行引导序列进行引导。不过，我也不认为使用辅助引导加载程序会导致无响应的行为，毕竟设备正在引导，固件正在运行，所以只要您有延长的睡眠时间，而不是（OTP\u COPY\u ON），设备就应该保留固件。您还可以尝试调试的是，通过调试器进行连接，以便知道fw到底在哪里暂停，并在崩溃前后监视电源，以便知道设备是否正在睡眠而没有醒来，或者是否已卡在断言中。
谢谢你的对话
你好，
通过调试器（RAM）运行fw，设备不会停止。我还检查了通过booter将fw直接加载到RAM中的方法，它工作得很好，只有从flash引导时才会出现问题。
Thanks
Hi wisilica,
What i ve proposed above is to attach the debbuger while the device has booted from flash and the issue has occured in order to try and check where exactly the device stalls and check if this will help debugging the issue (just boot wait for the insident to occur and then attach the debugger - In order to attach the debugger via Keil in the "Debug" tab remove the initialization file and then hit the settings button and uncheck the "Reset after Connect"). Since the device appears to stuck when the seconday bootloader runs, perhaps what you are experiencing is related to that fact, perhaps this is an issue of the secondary bootloader and after running from OTP it doesn't reset a register or something similar and when the device goes to sleep it stalls (although i ve tested running the secondary bootloader from RAM and the SPI pins configured like the case above and having the flash bunred with the ble_app_peripheral the device could directly boot from the SPI flash on the specified pins and run as it should, so again i am not able to connect the secondary bootloader with the fact that the device stalls). You should also try to burn the OTP header with the Boot specific mapping flag set to the pins that you would like and check if the device operates that way.
谢谢你的对话
你好，
How do we attach the debugger to the board while it is running ? After re-powering the board, the device begin to boot from flash, and then after few seconds it halts. When do we need to start the debug session ? I suppose the debug session, dumps the firmware into RAM. So, how do we know the point where the code halts ?
Also, the Application programmed flags 1 and 2 are configured as YES, OTP DMA length as 1FC0 and SWD enable flag as JTAG enabled in the OTP header. The snapshot of the same is attached herewith(OTP header smart snippets). Kindly see if any configuration is missing.
此外，问题不会一致。在某些运行相同的固件中，未观察到该问题，设备正常工作。请暗示它的原因。
Thanks
Hi wisilica,
使用您使用的相同项目来构建已刻录到Flash的.hex文件，根据您通常执行的，从闪存启动设备，然后按照上面提供的指令，以防止Keil下载设备的图像并防止JTAG重置（为了在“调试”选项卡中通过Keil连接调试器，请删除初始化文件，然后点击设置按钮并取消选中“连接后重置”）。在这样做只是点击“开始/停止调试会话”而且您将能够附加到自定义板（在附加JTAG之前，您不应该重置设备，或者让Keiil为您做这一点，这就是您应该首先准备的原因上述设置然后启动过程，例如，当检查“连接后”时，jlink将重置设备。击中“停止”按钮以停止执行（或FW可能已停止）并在装配模式中检查如果设备粘在某个地方，您将能够看到此问题和通过地图文件，您将能够查看哪个功能停止了。
关于OTP的设置,since the device is able to boot properly from the SPI the mirroring procedure is ok, there is no need to program the OTP DMA as it is used only when the device switches off the sysram as well, so the OTP will have to know how much data to copy upon wake up (also the value that you have placed is for the 580 which has a smaller OTP, but in any case this should not have any effect to what you are experiencing). Anyway, also burned a 585 device with a secondary bootloader and booted from the indicated SPI pins, again the device is operating as it should with no issue.
If that issue doesn't happen consistently, does that mean that the issue is likely to occur even when the fw is downloded via JTAG ? So perhaps there is no connection between the issue and downloading via the flash ?
谢谢你的对话
你好，
我们在直接将FW加载到RAM中，我们没有观察到这个问题。此外，在构建代码时，各种内存部分的大小如下：
程序尺寸：码= 20808 RO-DATA = 2892 RW-DATA = 600 ZI-DATA = 8400
这跟这个问题有关系吗？
现在，单击“开始调试会话”选项卡，然后在停止它时，我无法查看“装配”窗口。有没有任何设置缺失？
Thanks
Hi wisilica,
What you be 've posted is just the size of the binary generated from keil, doesn't have to do anything on what you are experiencing. The values that you have posted is the size of the Code (20808) RO data (2892) is the size of constant data, RW data (600) are your variables and ZI data (8400) is the size of your zero initialized variables. Please check what i ve mentioned above and also give it a try with a simple BLE SDK example and check if the same issue occurs. Regarding the disassembly window, you will have to enable it in order to see the Disassembly window, just go in "View" and click on the "Disassenbly Window".
谢谢你的对话
你好，
正如你所建议的，我尝试了ble\u app\u barebone项目。我所做的唯一更改是将默认睡眠模式设置为ARCH\u EXT\u sleep\u ON。即使在这种情况下，也观察到了这个问题。
现在，在重新启动电路板以从flash引导之后，在单击startdebug session选项卡之后，将显示反汇编窗口，并高亮显示下面的行（附加的快照）。
这是什么意思？
Thanks
你好，
此外，我还附加了barebone项目十六进制文件，用于卡住中途。唯一的改变是将睡眠模式设置为延长。
Please try using the firmware I have shared, in a board which can boot from the pins I have described earlier.
CLK-P0 0，CS-P0 1，DI-P0 2，DO-P0 3
Thanks
从您附加的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”字段而不是辅助引导加载程序。
谢谢你的对话