你好
我试图通过自定义板上的UART加载辅助引导程序来加载报告应用程序。一切工作都很好，我能够看到广告框架时加载二级bootloader通过JTAG(即没有OTP烧伤在芯片。)。
然而，在将引导加载程序刻录到OTP中之后，一切似乎都工作正常:引导加载程序启动，报告应用程序被下载并启动。问题是我再也找不到广告画框了。我非常确定reporter_fh应用程序开始正常运行，因为我在预期的间隔(650ms，但我也尝试了更长的间隔，我可以看到变化)。我也可以看到16Mhz石英运行在这个间隔。这就像我不能得到任何射频输出或有效的广告框架。
另一件事是，报告应用程序不再工作，通过JTAG加载后OTP被烧毁，代码加载，但当我停止调试程序，应用程序似乎冻结到600µA。
我猜reporter正在寻找OTP数据，如果设置不当，它会破坏广告（甚至是JTAG加载的应用程序？），但我一直在深入研究代码，找不到任何原因，因为似乎所有内容都是在编译时定义的。我正在使用reporter\u fh示例，例如，ie只是从最后一个SDK构建它（3.0.6），开发调试定义为1。
我对OTP所做的：
- burn辅助引导加载器
-读取OTP头
-将两个应用程序标志都设置为true
—设置OTP remapped为0
-设置DMA大小为1FFF
-燃烧集管
所以UniqueID仍然是0，JTAG被启用。我根本没有烧掉NVD。
谢谢你的帮助。
卢瓦
你好，斯玛莉，
当你说不再做广告时，你能试着测试是否没有射频数据包或者只是发送了错误的数据包吗？
还有一件事要澄清的是你把你的记者项目放在哪里了?你说过不许点头。
谢谢你！
的问候!
派克
你好
谢谢你的回答!
我拥有的是一个二级引导加载程序，它在UART上查找数据，如果没有接收到数据，它将在一段时间后进入深度睡眠。因此，应用程序一旦下载，就会复制到SysRam中，这与辅助引导加载程序的示例完全相同。当然，我有一个micro，我把一个二进制文件作为一个数组，并通过UART传输应用程序。
总结如下：
da14580-01 (bootloader) <-----UART-----> Micro (reporter app)
-引导加载程序从保留RAM启动并运行
-引导加载程序通过UART接收报告应用程序并将其复制到Sysram
-引导加载程序触发软复位
-记者应用启动
出于调试目的，我以以下方式完成了所有过程：
Micro等待引导程序
-使用JTAG将引导加载程序复制到da14580-01中
-引导加载程序启动、复制报告程序应用程序并触发软重置
-广告框好吗
为了做到这一点，我必须以这样的方式修改引导加载程序分散文件:
LR_IROM1 0x2000000008000{；加载区域大小_区域
ER_IROM1 0x20000000 0x00002000 {;加载地址=执行地址
* .o（重置，+第一个）
*（在root$$节中）
启动\u CMSDK\u CM0.o
系统(CMSDK.o)
}
ER_IROM2 0x80000 0x2000 {
.any（+ RO）
.ANY (+ RW +子)
.任何（堆栈）
}
}
然后我回到了正常的散点文件：
LR_IROM1 0x00000000 0x00008000 {;负荷地区size_region
ER_IROM1 0x00000000 0x00002000{；加载地址=执行地址
* .o（重置，+第一个）
*（在root$$节中）
启动\u CMSDK\u CM0.o
系统(CMSDK.o)
}
ER_IROM2 0x80000 0x2000 {
.any（+ RO）
.ANY (+ RW +子)
.任何（堆栈）
}
}
并烧毁了OTP中的引导加载程序，如我在上一篇文章中所述。
最终我得到：
Micro等待引导程序
-引导加载程序启动、复制报告程序应用程序并触发软重置
-广告可以，但消费可以
我试图看看是否有任何射频输出，但我需要插入射频分析仪，以看到它的突发似乎太短，不够强大，以通过天线出现。我将尝试在板上添加一个连接器。就像我说的，我确定记者应用程序是运行的，但它就像RF或广告是坏的。
在OTP中，我发现RF和avering相关的是:
- 设备唯一ID（不烧，广告地址错误？）
-石英微调（从芯片读取并烧坏，频率错误？）
但我不明白为什么会有任何区别，看到我使用相同的报告应用程序之前燃烧的OTP，我相信这不是阅读任何信息从OTP头无论如何(让我们希望我在这里是错误的…)。
希望它能澄清整个问题。我将在周一尝试回答射频输出问题。
再次感谢你的帮助。
我检查过了，根本没有射频输出。
评论以下一行：
#define cfg_nvds在da14580_config.h中
答案就在记者的申请书里。我想我确实是准时醒来，但一旦在app_adv_func函数什么都没有发生。你能进一步解释一下这和OTP有什么关系吗?我没有烧这个头，但也许我应该烧?
谢谢你的帮助。
你好，斯玛莉，
很高兴知道你找到了答案。这是可以解释的。
因为reporter应用程序将NVD放在NVDS_数据_存储_区域，这是不可恢复的。因此，当您进入深度睡眠时，所有这些信息都将丢失。然后在app_adv_func中，当您尝试检索这些信息时，您实际上得到了所有0。因此BLE内核将停止发送非法广告。如果您对CFG_NVD进行注释，则n没问题。另一个选择是将NVDS信息放入reporter应用程序的保留内存中。
Const struct nvds_data_struct nvds_data_storage __attribute__((section("retention_mem_area0"))) ={…}
或者您也可以将NVDS表刻录到OTP，您需要自己处理内存分配。
希望这可以帮助!
的问候!
派克
谢谢你的解释，这很有意义！我最不明白的是，当使用JTAG时，应用程序为什么会工作，因为当时仍然定义了CFG_NVD？
当做
你好，斯玛莉，
是的，这是挥舞。我手头没有一个外部MCU以你的方式进行测试。我将进一步研究代码，看看是否能为你找到答案。请先使用你的工作。如果你有其他问题，请让我知道。
当做
派克
好吧，如果你拿默认报告器的例子，并将其加载到开发工具包子板，它确实工作得很好!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唤醒后，然后它应该不再运行。但我没有你的环境，不能重复你的问题。
我以前不知道您对深度睡眠模式的设置是什么。如果您真的按照我的猜测做了（实际上不是深度睡眠模式，也不是扩展睡眠模式），那么可能存在潜在风险。我建议您在使用辅助引导程序时选择扩展睡眠模式。
希望这对你有帮助。
的问候!
派克
你好
我在OTP上烧掉了第二个引导加载程序，在Flash上烧掉了ble_app_外围项目。但我无法从手机上搜索设备。
在我刻录二次引导加载程序之前，BLE仍然工作。我跟随次级引导加载程序文档来执行此操作。我忘了吗？谢谢。
嗨，梁云浩，
我假设您没有尝试执行SUOTA过程，只是通过辅助引导程序引导闪存中的映像，那么您是否在辅助引导加载程序项目中定义了SUPPORT_AN_B_001？既然您尝试从SPI引导，那么支持的SPI_flash_是否已启用？您是否已将闪存中的映像标记为可引导以用于智能Sn附加附加标头的ippets？您还可以通过将映像刻录到SPI闪存中并通过keil下载secondary_bootloader项目来测试secondary bootloader，并检查该过程是否正确执行。
坦斯克山对话
您好，DMA长度的推荐值是多少？谢谢。
嗨，梁云浩，
您可以放置图像的长度，也可以刻写值为1FC0(即32512字节)的字段。
谢谢你的对话
好啊谢谢