你好,
我正在尝试通过自定义板上通过UART加载辅助引导程序上的报告器应用程序。一切正常工作，我能够通过JTAG加载辅助引导加载程序时看到广告帧（即芯片中没有OTP烧焦）。
然而，在将引导加载程序刻录到OTP时，一切似乎工作正常：引导加载程序启动，Reporter应用程序下载并开始。这是我不再得到任何广告框架了。我很确定报告_FH应用程序开始正常运行，因为我在预期的间隔处获得高电流值（但是我也尝试了更长的间隔，我可以看到更改）。我也可以看到此间隔的16MHz Quartz。这就像我无法再收到任何RF输出或有效的广告框架。
另一件事是报告申请在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。
谢谢你的帮助。
lo
嗨Smarly,
当你说不再做广告的时候，你能试着测试下是没有RF包还是发错了包?
还有一个澄清的是你把记者计划的地方？你说没有点头。
谢谢！
问候！
PY
你好,
感谢您的回答！
我所拥有的是一个辅助引导加载程序，它在UART上查找数据，并在没有收到的情况下稍后深入睡眠。因此，一旦在辅助引导程序示例中完全下载，应用程序将复制到Sysram中。当然，我有一个微型文件，我将二进制文件作为数组，并将应用程序转移到UART上。
总结:
DA14580-01（Bootloader）<----- UART -----> Micro（Reporter App）
-引导加载程序从保留RAM启动和运行
- Bootloader通过UART接收报告器应用程序并将其复制到Sysram
—bootloader触发软复位
- Reporter App开始
出于调试的目的，我按照以下方式完成了所有过程:
- 微量等待引导者
-使用JTAG复制引导加载程序到da14580-01
-启动bootloader，复制报告程序并触发软复位
-广告框架
为此，我必须以这样的方式修改引导加载程序分散文件：
LR_IROM1 0x20000000 0x00008000 {;负荷地区size_region
ER_IROM1 0x20000000 0x00002000 {;加载地址=执行地址
* .o（重置，+第一个）
* (InRoot $ $部分)
startup_CMSDK_CM0.o
system_CMSDK.o
｝
ER_IROM2 0x80000 0x2000 {
.any（+ Ro）
.any（+ rw + zi）
.ANY(栈)
｝
｝
然后我回到普通的分散文件:
lr_irom1 0x00000000 0x00008000 {;负荷地区size_region
ER_IROM1 0x00000000 0x00002000 {;加载地址=执行地址
* .o（重置，+第一个）
* (InRoot $ $部分)
startup_CMSDK_CM0.o
system_CMSDK.o
｝
ER_IROM2 0x80000 0x2000 {
.any（+ Ro）
.any（+ rw + zi）
.ANY(栈)
｝
｝
并烧毁了OTP中的引导加载程序。
最终我得到:
- 微量等待引导者
-启动bootloader，复制报告程序并触发软复位
-广告框架KO但消费可以
我试图看看是否有任何RF输出，但是我需要插入RF分析仪，以便在突发似乎太短而且不够强大以通过天线出现。我会尝试在电路板上添加一个连接器。据说，我确信报告申请正在运行，但它就像射频或广告一样被打破了。
我发现与RF和OTP中的倾向倾向于：
- 设备唯一ID（不烧，广告地址错误？）
-石英微调(从芯片读取和烧毁，错误的频率?)
但是我没有得到为什么会有任何区别，看到我在刻录我认为没有从OTP标题中读取任何信息之前的OTP之前使用相同的报道器应用程序（让我们希望我错了..。）。
希望它能澄清整个问题。我会在周一回答RF输出的问题。
再次感谢你的帮助。
我检查过了，根本没有RF输出。
注释以下一行:
#define cfg_nvds在da14580_config.h中
在记者申请是答案。我想我确实按时醒来，但是在app_adv_func函数中，没有什么发生的。你能进一步解释一下这与OTP有关吗？我没有烧这个标题，但也许我应该有吗？
谢谢你的帮助。
嗨Smarly,
很高兴知道你找到了答案。这可以解释。
因为报告应用程序将NVDS放在nvds_data_storage_area中，这是不可保留的。所以当你进入深度睡眠时，所有这些信息都会丢失。然后在app_adv_func中，当你试图检索这些信息时，你实际上得到的都是0。因此BLE内核将停止发送非法广告。如果您注释掉CFG_NVDS，那么就可以了。另一种选择是在报告程序中将NVDS信息放入保留内存。
const struct nvds_data_struct nvds_data_storage __attribute __（（部分（“retention_mem_area0”）））= {...}
或者您也可以将NVDS表刻录到OTP中，并且您需要自己处理内存分配。
希望这可以帮助！
问候！
PY
谢谢你的解释，这很有意义!我不明白的最后一件事是，当使用JTAG时，为什么应用程序还能工作，因为当时CFG_NVDS还在定义中?
问候
嗨Smarly,
是的它是行使。我手头没有外部MCU来做你的方式的测试。我将进一步研究代码，看看能否为您找到答案。请先使用你的作品。如果你有其他问题，请告诉我。
问候
PY
好吧，如果你拍摄默认记者榜样并将其加载到DEV套件子板中，它确实正常工作！定义了CFG_NVDS，OTP不会刻录。
如果你能向我解释为什么这有效，那就足够了:-)。
谢谢
嗨Smarly,
我调查了代码，在这里尝试一些测试。
1.默认的proxr项目以扩展休眠模式运行，当然它可以在定义CFG_NVDS时运行，因为根本没有OTP镜像。
2.如果Proxr项目在Deep Sleep模式下运行并启用调试（Development_debug仍为默认为1），则代码也将使用CFG_NVDS定义，因为此设置中的系统RAM也将在睡眠期间保留，OTP镜像将保留不实现，因为OTP是空的..
3.如果Proxr项目在深度休眠模式下运行并禁用调试（Development_debug为0），则代码将不得不从OTP运行，这不是我们谈论的情况。
所以回到你的问题，我会猜测你使用第二个设置编译你的proxr码（你没有提到这个细节，但你说你使用深睡眠，我认为第3个设置在你的情况下不起作用，既不放置OTP和RAM中的引导程序）。然后，如果将引导加载程序从RAM从RAM加载到加载Proxr，则之后场景将类似于上面的第二个案例：OPT为空，所有代码从RAM运行。如果将Bootloader刻录到OTP并使用引导加载程序将Proxr图像加载到RAM中，则睡眠和唤醒后，OTP控制器将尝试从OPT获取信息，因为OTP不为空（引导程序内），那么将有一些冲突。我唯一不确定的是理论上，在你的情况下，Boot加载程序将在BLE唤醒之后从OTP复制，然后不再运行。但我没有你的整个环境，不能重复你的问题。
我之前不知道你的深度睡眠模式设置是什么。如果你真的像我猜的那样(既不是深度睡眠模式，也不是延长睡眠模式)，那么可能存在潜在的风险。我想建议你在使用辅助引导程序时选择扩展睡眠模式。
希望这对你有所帮助。
问候！
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
好的。谢谢。