Hi,
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.扩展的代码启用了睡眠,当n flashed into the hw, shows inconsistent behaviour. It advertises for some time, and then enters a non responsive state.
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.
如果在闪存中刻录SDK项目并启动该项目，您可以看到相同的行为吗？你能估计设备广告的时间吗？我会假设该设备在睡眠中保持清醒和摊位的同时宣传，因此尝试从FW切换到RCX而不是XTAL32。您可以尝试使用默认引脚（可能在Dev套件上）从Flash启动FW）并检查是否有任何区别？
在这篇文章中，我也错过了一些关于从特定的SPI引脚启动的东西https://support.dialog-semiconductor.com/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. Tried loading the firmware directly into RAM using booter, and then the device advertises properly.
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.
请建议上述问题的原因。
Thanks
Hi wisilica,
由于您已表示从特定SPI引脚完成引导序列，则引导标志不应为0x00（正常序列）但0xAA（从特定位置的SPI端口引导）。此外，如果您已经刻录刻录，则OTP中的辅助引导加载程序仍将使用辅助引导程序和不是串行引导序列引导。但是，我不认为你使用的辅助引导加载程序的事实会导致无响应的行为，之后所有设备都启动和FW运行，所以只要您拥有延长的睡眠而不是（OTP_COPY_ON）设备保留FW。您也可以尝试调试此操作是通过调试器附加，以便意识到FW摊位的位置，并且在崩溃之前和之后监控电源，以便知道设备是否睡觉，而不是唤醒或者它陷入了断言。
谢谢mt_dialog.
Hi,
通过通过调试器（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.
谢谢mt_dialog.
Hi,
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.
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.
Thanks
Hi 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的设置,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 ?
谢谢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 ?
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".
谢谢mt_dialog.
Hi,
正如您所建议的那样，我尝试了BLE_APP_BAREBONE项目。我所做的唯一变更将默认休眠模式设置为ARCH_EXT_SLEEP_ON。即使在这种情况下，也观察到这个问题。
现在，重新重新计算机后从Flash启动后，并在单击“开始调试会话”选项卡后，显示“拆卸”窗口，并突出显示以下行（附加快照）。
这是什么意思 ？
Thanks
Hi,
此外，我已经附上了鞍骨项目十六进制文件，使用中途粘在一起。所做的唯一变更是将睡眠模式设置为扩展。
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图像似乎没有停止（拆卸窗口中的指令指示设备正在从内存加载地址），我想如果您在附加时按“运行”按钮您可以运行代码。
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.