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. 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.
谢谢
Device:
嗨Wisilica，
我无法弄清楚这种行为的任何明显，我可以提到一些事情，以便你测试。
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-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,
谢谢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.尝试使用Booter将固件直接加载到RAM中，然后设备正常通告。
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 ?
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.
Please suggest the reasons fr the above issue.
谢谢
嗨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.
谢谢MT_dialog
Hi,
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.
谢谢
嗨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 (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"). 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
Does this have anything to do with the issue ?
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,
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 ?
谢谢
Hi,
Also, I have attached the barebone project hex file, used which stuck midway. The only change made is setting the sleep mode as extended.
请尝试使用我已分享的固件，在可以从我之前描述的引脚启动的电路板中。
CLK - P0_0, CS - P0_1, DI - P0_2, DO - P0_3
谢谢
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.
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.
最后它值得一试这在不同的板and use the "Boot specific mapping" field instead of the secondary bootloader.
谢谢MT_dialog