你好，
我试图通过自定义板上的UART加载辅助引导程序来加载报告应用程序。一切工作都很好，我能够看到广告框架时加载二级bootloader通过JTAG(即没有OTP烧伤在芯片。)。
然而，在将引导加载程序刻录到OTP中之后，一切似乎都工作正常:引导加载程序启动，报告应用程序被下载并启动。问题是我再也找不到广告画框了。我非常确定reporter_fh应用程序开始正常运行，因为我在预期的间隔(650ms，但我也尝试了更长的间隔，我可以看到变化)。我也可以看到16Mhz石英运行在这个间隔。这就像我不能得到任何射频输出或有效的广告框架。
另一件事是，报告应用程序不再工作，通过JTAG加载后OTP被烧毁，代码加载，但当我停止调试程序，应用程序似乎冻结到600µA。
我想报道，记者正在寻找OTP数据，如果没有正确设置它，它会破坏广告（甚至是JTAG加载的应用程序？），但我一直挖掘代码并找不到任何原因，因为看起来一切都是如此在编译时定义。我正在使用报道_FH示例，例如，只需将其从最后的SDK（3.0.6）与development_debug定义为1。
我用OTP完成了什么：
- burn辅助引导加载器
- 阅读OTP标题
- 将应用程序标志设置为true
—设置OTP remapped为0
-设置DMA大小为1FFF
- 烧伤标题
所以Usidid仍然是0并且启用了JTAG。我根本没有烧伤NVDS。
谢谢你的帮助。
卢瓦
嗨，嗨，
当你说不再获得广告时，你可以试图测试是否没有射频数据包或者只是发出错误的数据包？
还有一件事要澄清的是你把你的记者项目放在哪里了?你说过不许点头。
谢谢你！
的问候!
PY
你好，
谢谢你的回答!
我拥有的是一个二级引导加载程序，它在UART上查找数据，如果没有接收到数据，它将在一段时间后进入深度睡眠。因此，应用程序一旦下载，就会复制到SysRam中，这与辅助引导加载程序的示例完全相同。当然，我有一个micro，我把一个二进制文件作为一个数组，并通过UART传输应用程序。
总结：
da14580-01 (bootloader) <-----UART-----> Micro (reporter app)
- Bootloader从Retention RAM开始并运行
-引导加载程序通过UART接收报告应用程序并将其复制到Sysram
- Bootloader触发软复位
-记者应用启动
有关调试目的，我完成了以下所有过程：
Micro等待引导程序
- 使用JTAG将引导加载程序复制到DA14580-01中
- 引导加载程序启动，复制报告器应用程序并触发软复位
- 广告框架正常
为了做到这一点，我必须以这样的方式修改引导加载程序分散文件:
lr_irom1 0x20000000 0x00008000 {;加载区域size_region.
ER_IROM1 0x20000000 0x00002000 {;加载地址=执行地址
*．o(重置,+第一)
*（Inroot $$部分）
startup_cmsdk_cm0.o.
system_cmsdk.o.
}
er_iro2 0x80000 0x2000 {
.ANY (+ RO)
.ANY (+ RW +子)
.any（堆栈）
}
}
然后我回到正常的分散文件：
LR_IROM1 0x00000000 0x00008000 {;加载区域size_region.
ER_IROM1 0x00000000 0x00002000 {;加载地址=执行地址
*．o(重置,+第一)
*（Inroot $$部分）
startup_cmsdk_cm0.o.
system_cmsdk.o.
}
er_iro2 0x80000 0x2000 {
.ANY (+ RO)
.ANY (+ RW +子)
.any（堆栈）
}
}
并如前一篇文章中所述刻录OTP中的引导加载程序。
最终我得到了：
Micro等待引导程序
- 引导加载程序启动，复制报告器应用程序并触发软复位
- 广告框架Ko但消费好
我试图看看是否有任何射频输出，但我需要插入射频分析仪，以看到它的突发似乎太短，不够强大，以通过天线出现。我将尝试在板上添加一个连接器。就像我说的，我确定记者应用程序是运行的，但它就像RF或广告是坏的。
在OTP中，我发现RF和avering相关的是:
-设备唯一ID(未烧毁，广告地址错误?)
- 石英修剪（从芯片读取并烧伤，错误的频率？）
但我不明白为什么会有任何区别，看到我使用相同的报告应用程序之前燃烧的OTP，我相信这不是阅读任何信息从OTP头无论如何(让我们希望我在这里是错误的…)。
希望它澄清整个问题。我会在星期一回答RF产出问题。
再次感谢你的帮助。
我检查了，根本没有RF输出。
评论以下行：
#在da14580_config.h中定义CFG_NVDS
答案就在记者的申请书里。我想我确实是准时醒来，但一旦在app_adv_func函数什么都没有发生。你能进一步解释一下这和OTP有什么关系吗?我没有烧这个头，但也许我应该烧?
谢谢你的帮助。
嗨，嗨，
很高兴知道你找到了答案。这是可以解释的。
因为报告管理程序将NVDS放在NVDS_DATA_STORAGE_AREA中，所以不会重新保留。因此，当您进入深度睡眠时，所有这些信息都将丢失。然后在app_adv_func时尝试检索这些信息时，您实际上得到所有0.所以BLE Kernal将停止发送非法广告。如果您注释出CFG_NVDS，那么它就没问题了。另一种选择是将NVDS信息放入报告应用程序中的保留内存。
Const struct nvds_data_struct nvds_data_storage __attribute__((section("retention_mem_area0"))) ={…}
或者您也可以将NVDS表刻录到OTP，并且您需要处理您自己的内存分配。
希望这可以帮助!
的问候!
PY
谢谢你的解释，这是有道理的！我不明白的最后一件事就是在使用JTAG时，应用程序正在运行的原因，因为CFG_NVDS仍然在时间定义？
问候
嗨，嗨，
是的，它是掌握的。我没有一个外部MCU以便在您的方式进行测试。我会看看更多的代码，看看我是否能找到你的答案。请先使用您的工作。如果你得到其他问题，请告诉我。
问候
PY
好吧，如果你拿默认报告器的例子，并将其加载到开发工具包子板，它确实工作得很好!CFG_NVDS已定义，OTP未燃烧。
如果你能向我解释为什么这是可行的，那就足够了:-)。
谢谢
嗨，嗨，
我研究了代码并在这里进行了一些测试。
1.默认Proxr项目以扩展睡眠模式运行，肯定可以使用CFG_NVDS定义，因为根本没有OTP镜像。
2.如果proxr项目还在深度睡眠模式和运行启用调试(DEVELOPMENT_DEBUG仍然是1为默认),代码也将与CFG_NVDS定义,因为系统内存中运行此设置也将保留在睡眠和OTP镜子不会实现,因为OTP是空的…
3.如果proxr项目在深度睡眠模式下运行并禁用调试(DEVELOPMENT_DEBUG为0)，那么代码将不得不从OTP运行，而这不是我们所讨论的情况。
回到你的问题，我猜你是用第二种设置来编译你的proxr代码的(你没有提到这个细节，但是你说你用的是深度睡眠，我认为第三种设置在你的情况下不会工作，既不把引导加载程序放在OTP或ram中)。然后，如果你使用bootloader从ram加载代理程序，之后的场景将像上面的第二种情况:OPT是空的，所有代码从ram运行。如果您将bootloader烧录到OTP中，并使用bootloader将代理镜像加载到ram中，然后在睡眠和唤醒后，OTP控制器将尝试从OPT获取信息，因为OTP不是空的(bootloader在里面)，然后会有一些冲突。我仍然不确定的唯一一件事是，理论上，在您的情况下，引导加载程序将从OTP复制BLE唤醒后，然后它应该不再运行。但我没有你的环境，不能重复你的问题。
我之前没有意识到以前的深度睡眠模式的设置是什么。如果你真的做了我猜到的（这不是深度睡眠模式，也没有延长睡眠模式），那么也许有潜在的风险。我想建议您在使用辅助引导程序时选择扩展睡眠模式。
希望这可以帮助你。
的问候!
PY
你好，
我在闪光灯上刻录了OTP上的次级引导加载程序和刻录BLE_APP_PLEWELIAL项目。但我无法从我的手机搜索设备。
BLE在我烧毁二级引导加载程序之前仍然工作。我按照辅助引导加载程序文档完成了这一操作。有什么设置我忘了吗?谢谢。
嗨，梁云浩，
我想你不是在尝试做Suota过程，只需通过闪存中的次级映像启动，所以您在辅助引导加载程序中定义了support_an_b_001？由于您尝试从SPI启动的是启用SPI_FLASH_SUPPORTED？您是否将闪光灯中的图像标记为可引导，以便智能片段附加其他标题？您还可以通过将图像刻录到SPI闪存并通过efferic_bootloader项目下载并检查程序是否正确执行该过程来测试辅助引导加载程序。
Thansk mt_dialog.
嗨，DMA长度的推荐值是什么？谢谢。
嗨，梁云浩，
您可以放置图像的长度，也可以刻写值为1FC0(即32512字节)的字段。
谢谢mt_dialog.
好的。谢谢。