你好,
我试图通过UART上加载定制电路板在二级引导加载程序的应用报告。一切正常，我能看到的广告框架加载通过JTAG二次启动加载程序时（即没有OTP烧毁芯片。）。
不过烧的bootloader到OTP之后一切似乎正常工作：引导程序启动后，记者应用程序被下载并启动。事情是我没有得到任何广告架了。我敢肯定的reporter_fh应用开始正常运行，因为我得到的预期区间高电流值（650ms，但我也尝试了较长的时间间隔，我可以看到的变化）。我还可以看到16MHz的石英在此区间运行，以及。这就像我不能得到任何RF输出或有效的广告架了。
另一件事是，通过JTAG加载时的OTP被烧毁，代码没有得到加载后，但是当我停止debugguer的应用程序似乎冻结600μA记者的应用程序不工作了。
我猜记者是在寻找OTP数据，如果设置不当，它会破坏广告(甚至是JTAG加载的应用?)，但我一直在深入研究代码，找不到任何原因，因为似乎一切都是在编译时定义的。我使用的是reporter_fh示例，例如，刚刚从最后一个SDK(3.0.6)构建它，其中DEVELOPMENT_DEBUG定义为1。
我对OTP做了什么:
- 烧二次引导程序
—读取OTP报头
-设置两个应用程序标志都为true
- 设置OTP重新映射到0
- 设置DMA大小1FFF
——燃烧头
UniqueID仍然是0,JTAG是启用的。我根本没烧NVDS。
谢谢你的帮助。
卢瓦克
嗨Smarly,
当你说不再做广告的时候，你能试着测试下是没有RF包还是发错了包?
还有一分澄清的事情是，你把你的记者计划？你说没有点头。
谢谢！
问候！
PY
你好,
感谢您的回答！
我已经是一个次要的bootloader，看起来用于在UART数据，如果没有收到一段时间后进入深度睡眠。因此，应用程序将被复制到SysRam下载一次完全一样在二级引导程序的例子。当然，我已经有了一个微进我把二进制文件作为一个数组并传递在UART的应用。
总结:
da14580-01（引导程序）<----- ----- UART>微型（记者应用）
-引导加载程序从保留RAM启动和运行
- 引导程序通过UART并将其复制到Sysram接受记者的应用
—bootloader触发软复位
- 记者应用程序启动
出于调试的目的，我按照以下方式完成了所有过程:
- 微等待bootlader
-使用JTAG复制引导加载程序到da14580-01
-启动bootloader，复制报告程序并触发软复位
-广告框架
要做到这一点，我不得不修改的bootloader分散文件中这样写道：
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 + ZI）
.ANY(栈)
｝
｝
然后我回到普通的分散文件:
LR_IROM1 00000000 0x00008000 {;负荷地区size_region
ER_IROM1 0x00000000 0x00002000 {;加载地址=执行地址
*。o(重置,+第一)
* (InRoot $ $部分)
startup_CMSDK_CM0.o
system_CMSDK.o
｝
er_iro2 0x80000 0x2000 {
.ANY (+ RO)
.ANY（+ RW + ZI）
.ANY(栈)
｝
｝
并烧毁了OTP中的引导加载程序。
最终我得到:
- 微等待bootlader
-启动bootloader，复制报告程序并触发软复位
-广告框架KO但消费可以
我想看看是否有任何RF输出，但我需要插入射频分析仪将其视为突发似乎太短，不够强大经由天线出现。我会尽力在板上添加连接器。因为是说，我敢肯定，记者应用程序正在运行，但它像RF或广告被打破。
我发现与RF和在OTP avertising是：
-设备唯一ID(未烧毁，广告地址错误?)
-石英微调(从芯片读取和烧毁，错误的频率?)
但我不明白为什么它会作出任何区别看到我使用同一个记者应用程序烧我相信这是不读从OTP头的任何信息反正OTP之前（但愿我是错在这里..）。
希望它能澄清整个问题。我会在周一回答RF输出的问题。
再次感谢你的帮助。
我检查过了，根本没有RF输出。
注释以下一行:
#在da14580_config.h中定义CFG_NVDS
在记者的应用就是答案。我想我确实是起床时间，但一旦在app_adv_func功能没有什么事情的原委。你能否进一步解释一下这是如何与OTP关系吗？我没烧这头，但也许我应该有吗？
谢谢你的帮助。
嗨Smarly,
它的好，知道你找到答案。这可以解释。
因为报告应用程序将NVDS放在nvds_data_storage_area中，这是不可保留的。所以当你进入深度睡眠时，所有这些信息都会丢失。然后在app_adv_func中，当你试图检索这些信息时，你实际上得到的都是0。因此BLE内核将停止发送非法广告。如果您注释掉CFG_NVDS，那么就可以了。另一种选择是在报告程序中将NVDS信息放入保留内存。
常量结构nvds_data_struct nvds_data_storage __attribute __（（部分（ “retention_mem_area0”）））= {...}
或者您也可以将NVDS表刻录到OTP中，并且您需要自己处理内存分配。
希望这可以帮助！
问候！
PY
谢谢你的解释，这很有意义!我不明白的最后一件事是，当使用JTAG时，为什么应用程序还能工作，因为当时CFG_NVDS还在定义中?
问候
嗨Smarly,
是的它是行使。我手头没有外部MCU来做你的方式的测试。我将进一步研究代码，看看能否为您找到答案。请先使用你的作品。如果你有其他问题，请告诉我。
问候
PY
好吧，如果你把默认的记者例子，将其加载到开发工具包子板，它做工精细！CFG_NVDS定义和OTP是不被烧毁。
如果你能向我解释为什么这工作那么这是足够好的:-)。
谢谢
嗨Smarly,
我看着代码，并在这里尝试一些测试。
1.默认的proxr项目以扩展休眠模式运行，当然它可以在定义CFG_NVDS时运行，因为根本没有OTP镜像。
2.如果在深睡眠模式的proxr项目运行并还启用调试（DEVELOPMENT_DEBUG仍然是1为默认值），该代码也将与所定义CFG_NVDS运行，因为在此设置的系统RAM也将睡眠和OTP镜期间被保持将没有实现，因为OTP是空的..
3.如果proxr项目在深度睡眠模式下运行并禁用调试(DEVELOPMENT_DEBUG为0)，那么代码将不得不从OTP运行，而这不是我们所讨论的情况。
所以，回到你的问题，我就猜你编译使用第二设置你的proxr代码（你没有提到这个细节，但你说你用深睡眠，我认为第三设置将在你的情况没有工作，没有放引导加载程序在OTP也不RAM）。然后，如果你使用引导程序，从RAM向负载proxr，后来的场景将就像上面的第二种情况：OPT是空的，并从RAM中的所有代码运行。如果您刻录启动程序到OTP和使用bootloader加载proxr图像到RAM中，然后睡眠和唤醒后，OTP控制器将尝试从OPT获得的信息，因为OTP不为空（引导程序内），然后会有一些冲突。我还是不知道的唯一的事情是理论上的情况下，引导程序将OTP BLE唤醒之后被复制，那么它不应该再运行。但是，我没有你的整个环境，不能重复你的问题。
我之前不知道你的深度睡眠模式设置是什么。如果你真的像我猜的那样(既不是深度睡眠模式，也不是延长睡眠模式)，那么可能存在潜在的风险。我想建议你在使用辅助引导程序时选择扩展睡眠模式。
希望这对你有所帮助。
问候！
PY
你好,
我在OTP上刻录了二级引导加载程序，在Flash上刻录了ble_app_peripheral项目。但我不能用手机搜索这个设备。
BLE在我烧毁二级引导加载程序之前仍然工作。我按照辅助引导加载程序文档完成了这一操作。有什么设置我忘了吗?谢谢。
嗨梁云也好，
我猜想您不会尝试执行SUOTA过程，只是通过flash中的辅助映像进行引导，那么您是否在辅助引导加载程序项目中定义了SUPPORT_AN_B_001 ?既然您正在尝试从SPI启动，是否启用了SPI_FLASH_SUPPORTED ?您是否在您的flash中标记为可引导的图像，以便智能片段附加额外的头部?您还可以通过将映像刻录到SPI flash中来测试辅助引导加载程序，并通过keil下载secondary_bootloader项目并检查过程是否正确执行。
Thansk MT_dialog
您好，DMA长度的推荐值是多少?谢谢。
嗨梁云也好，
您可以将图像的任意长度，或者你可以在字段值1FC0意在字32512个字节燃烧。
由于MT_dialog
好的。谢谢。