你好，
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. The code in which extended sleep is enabled when run through RAM(using keil debugger), works fine.
We have included both 32khz and 16Mhz crystals in our design.
What might be the reason for the same ? Please suggest.
Thanks
Device:
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.
If you burn an SDK project in the flash and boot that project do you see the same behaviour ? Can you estimate how long the device advertises ? I would assume that the device advertises while it stays awake and stalls when goes to sleep, so try to switch to the RCX instead of the XTAL32 from the fw. Can you try to boot your fw from flash using the default pins (perhaps on the dev kit) and check if that makes any difference ?
Also something i ve missed to mention in this post regarding booting from specific SPI pinshttps://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl...在585中，除了从特定引脚启动的OTP中刻录的辅助引导加载程序外，585还包括一个机制，以便从特定引脚引导，这可以在OTP标题的引导特定映射字段中定义，您将能够找到附录G和4.3.1 OTP标题段落中的585的数据表中的信息，尽管我不认为您观察到的行为的原因是您在OTP中刻录了辅助引导加载程序。
Thanks MT_dialog
你好，
Thanks for your prompt reply. I have tried the things you had mentioned, and the results are as follows :
1. Instead of our application fw, I had programmed the barebone project, with default sleep mode selected as extended, into the flash. The behaviour remains the same, ie, the device advertises around 3 - 4 packets, and then enters a non responsive state.
2. Also tried setting CFG_LP_CLK as LP_CLK_RCX20, but still the issue persists.
3. Tried loading the firmware directly into RAM using booter, and then the device advertises properly.
4. Tried the same firmware in the development board(ie, default configuration of SPI PINS), and the device worked fine.
I also configured the OTP header in order to boot from SPI pins as follows :
SPI CLK = P0_0, SPI_EN = P0_1, SPI_DI = P0_2, SPI_DO = P0_3
Boot = Normal sequence , Wakeup command code = 00, Serial speed selection 0
Is there anything wrong in the configuration ?
此外，在二级引导加载程序固件中，所做的唯一更改是定义SPI_FLASH_SUPPORTED和SUPPERT_AN_B_001，并根据我们的原理图配置SPI引脚。
Please suggest the reasons fr the above issue.
Thanks
Hi wisilica,
Since you have indicated that the booting sequence should be done from specific SPI pins then the Boot flag should not be 0x00 (Normal sequence) but 0xAA (boot from SPI port at a specific location). Also in case you have allready burned the secondary bootloader in the OTP the device will still boot using the secondary bootloader and not the serial booting sequence. But again i dont think that the fact that you are using the secondary bootloader would result in an unresponsive behaviour, after all the device is booting and the fw runs, so as long as you have the extended sleep and not (OTP_COPY_ON) the device should retain the fw. What you can also try to debug this is to attach via the debugger in order to be aware where exactly the fw stalls and also monitor the power before and after the crash in order to be aware if the device is sleeping and not waking up or if it has stuck in an assertion.
Thanks MT_dialog
你好，
By running the fw through debugger(RAM), the device doesn't halts. I also checked with loading fw directly into RAM via booter, and it worked fine.The issue occurs only when it boots from 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.
Thanks MT_dialog
你好，
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重置（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"）。在这样做只是点击“开始/停止调试会话”而且您将能够附加到自定义板（在附加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 ?
Thanks MT_dialog
你好，
我们在直接将FW加载到RAM中，我们没有观察到这个问题。此外，在构建代码时，各种内存部分的大小如下：
程序尺寸：码= 20808 RO-DATA = 2892 RW-DATA = 600 ZI-DATA = 8400
Does this have anything to do with the issue ?
现在，单击“开始调试会话”选项卡，然后在停止它时，我无法查看“装配”窗口。有没有任何设置缺失？
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".
Thanks MT_dialog
你好，
As you have suggested, I tried with the ble_app_barebone project. The only change I made is set the default sleep mode to ARCH_EXT_SLEEP_ON. The issue was observed even in this case.
Now, after repowering the board to boot from flash, and after clicking the start debug session tab, the disassembly window was displayed, and the the following line was highlighted(attached snapshot).
What does this mean ?
Thanks
你好，
Also, I have attached the barebone project hex file, used which stuck midway. The only change made is setting the sleep mode as extended.
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
From the keil image that you attached doesn't seem that the device has stopped (the instruction in the disassembly window indicates that the device is loading an address from the memory), i suppose that if you hit the "Run" button while attached are you able run code.
您在拆卸窗口中看到的代码的部分是从睡眠中恢复后执行的指令，以便获取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.
最后它值得一试这在不同的板and use the "Boot specific mapping" field instead of the secondary bootloader.
Thanks MT_dialog