[参考译文] LAUNCHXL-CC1312R1：如果未在 UARTAutoBaud 上连接、UART2会崩溃

尊敬的 Lode：

这不是软件错误、但更像是 CC1312启动进入串行引导加载程序模式： https://www.ti.com/lit/an/swra466e/swra466e.pdf

这可能意味着引导加载程序触发引脚已启用、或者您下载到器件的闪存映像无效。

您是否正在尝试运行 OAD (无线下载)项目？ 您尝试使用的示例是什么？

此致、

Arthur

不需要 AOD 或任何特定于引导加载程序的东西。
这只是从空示例创建的一个基本工程。  
我将查看是否可以使用提供的文档解决该问题。

确保在 SysConfig 中检查您的 CCFG 配置、如下所示：

此致、

Arthur

Arthur、

引导加载程序(和后门)、其中确实未启用。  
但是、这不能解决问题。  重新连接后、我仍然得到相同的 UARTAutoBaud 错误

如果未启用引导加载程序、则仅保持打开无效闪存映像选项。

如果您使用 CCS 或 UNIFLASH 检查以下寄存器：IMAGE_VALID_CONF、有什么结果？

另外、我还需要您的 Launchpad 图片、以及您正在使用的芯片标记以及 SDK 版本。

此致、

Arthur

无需使用 SDK 版本、因为您已经对其进行了修改。

此致、

Arthur

感谢您的快速回复！

存储器/引导加载程序是否确实存在问题？

不确定我应该能够在 CCS 中从哪里读取这些寄存器？  
这对我来说是未知的地形、所以我应该再次刷写引导加载程序吗？  
这是否也是存储器映射问题。

尊敬的 Lode：  

我看不到图片,但它肯定是。

您是否曾任意选择过 CC1312R1项目、而不是 CC1312R7项目？

此致、

Arthur

尊敬的 Arthur：

几天之后,我就离开了
SysConfig 中的电路板类型似乎正确、targetConfigs 只有一个[活动] CC1312R1B3.ccxml
我记得在此板上试用 NVS 驱动程序、这可能会使闪存无效？  

重新启动 UniFlash 后、我现在似乎可以访问前面提到的闪存地址 0x1FEC (将得到)
584604D019F80A0000FB0BF0000A4FEA

这告诉我什么？ 开始闪存扇区、然后什么...  

这很可能与 NVS 相关。我看到驱动程序仍处于配置和使用状态、可能区域基地址是罪魁祸首？

尊敬的 Lode：

为了知道该信息、需要检查您的 MEMORY .map 文件。 答案当然就在这里。

此致、

Arthur

您好、Arthur、  

我把它放在一个 gist 如果这有帮助吗?
https://gist.github.com/h3lpd3sk/2971a0219c7df92881de9da1d0edec27

和 NVS 配置

尊敬的 Lode：

关于 NVS、您能在 SysConfig 中向我展示其配置吗？ 我们可能确实做到了一点。

此致、

Arthur

好的、不需要、我现在可以看到图片了。  

我想我可以看到这个问题。
 

您是否按照 SysConfig 的建议修改了链接器脚本？

此致、

Arthur

我没有、现在才注意到警告这是手动配置。  
我已将链接器文件添加到 gist FYI 中。  
我将介绍一下之前提到的新功能

那么如何进行呢？  
我已重新配置要使用的 NVS
区基地址0x0
区大小为0x2000

在 cmd 文件中：
#define FLASH_BASE        0x2000

这是否应该计入 NVS 细分市场？  

我还看了 nvsinternal 示例、该示例也没有产生任何解决方案

电路板无法自主运行并卡在自动波特模式下的主要问题仍然存在。

尊敬的 Lode：

NVSinterval 示例自述文件实际说明了以下过程： README.html


顺便说一下、我在链接器文件中看不到您在 GitHub gist 中共享的任何 NVS 段。 用户应按照 README 中所示或示例中的链接器文件中添加它：

e2e.ti.com/.../cc13x2_5F00_cc26x2_5F00_freertos.lds

但是您是否认为 nvsinternal 示例存在相同的问题？ 您应该会看到以下内容：

此致、

Arthur

感谢您指出自述文件部分(我漏掉了该部分)、将显示内容。  
和后续示例文件。  

我更新了要点、以反映我当前的设置。

我只注意到 simplelink 自1月起更新为、也会更新。  

尊敬的 Athur：

这是一个非常严峻的问题。  
我从 SimpleLink 8.30.01.01 tirtos7 clang 中尝试了一个新的内部示例。  
可以按预期运行、包括复位(独立)。  

当我将 RegionBase 从0x10000更改为0x0000时、它会按照我自己的发现崩溃。  
因此区域基础似乎至关重要。  
但我不知道如何算出最好的地区?  

我知道 clang 编译器与 GCC 兼容、但这并不意味着它实际上是 GCC？  
clang 示例在 cmd 文件段中没有.NVS。
自述文件(您指出)中建议的.NVS 段配置无法编译。  
可以解决、但可能应该修复？

MEMORY
{
	NVS (RX)   : origin = 0x0, length = 0x2000
    FLASH (RX) : origin = 0x2000, length = FLASH_SIZE
    // ...
}

SECTIONS
{
    //...
    .nvs   			:   > NVS, type = NOLOAD, ALIGN(0x2000)
    .ccfg           :   > FLASH (HIGH)
    //...
}

很好的是内存可以配置,但它似乎什么,但直接?

嗨乐道、

正如您在之前的 SysConfig 屏幕截图中分享的那样、0x56000是一个不错的屏幕截图(这是闪存中最新的块之一)、具体取决于您要保存的数据量(我们对 Amazon Sidewalk 制造数据使用相同的区域)。

说到 ticlang、这是基于 LLVM 的不同编译器、因此实际上不是 GCC。 在 ticlang 中、NVS 配置考虑了 SysConfig 值、因此链接器文件中缺少段。 然后、您无需将其添加到链接器文件中。

此致、

Arthur

当我在复位后使用区域基地址0x56000 (大小为0x2000)时、nvsinternal 也会发生自动波特率崩溃
SimpleLink 8.30.01.01
链接器文件中没有 GCC 部分。  

0x10000正常复位

那么、解决这个问题的正确方法是什么？ 仍然没有错误？

尊敬的 Lode：

在这两种情况下、它都与 CCFG (器件配置寄存器)有关(器件用户手册的第11章)。

我们来 看看 gcc 链接器文件：

MEMORY
{
    FLASH (RX)      : ORIGIN = 0x00000000, LENGTH = 0x00057fa8
    /*
     * Customer Configuration Area and Bootloader Backdoor configuration in
     * flash, 40 bytes
     */
    FLASH_CCFG (R)  : ORIGIN = 0x00057fa8, LENGTH = 0x00000058
    SRAM (RWX)      : ORIGIN = 0x20000000, LENGTH = 0x00014000
    GPRAM (RWX)     : ORIGIN = 0x11000000, LENGTH = 0x00002000
    /* Explicitly placed off target for the storage of logging data.
     * The data placed here is NOT loaded onto the target device.
     * This is part of 1 GB of external memory from 0x60000000 - 0x9FFFFFFF.
     * ARM memory map can be found here:
     * developer.arm.com/.../about-the-memory-map
     */
    LOG_DATA     (R) : ORIGIN = 0x90000000, LENGTH = 0x40000
    LOG_PTR      (R) : ORIGIN = 0x94000008, LENGTH = 0x40000
}

REGION_ALIAS("REGION_TEXT", FLASH);
REGION_ALIAS("REGION_BSS", SRAM);
REGION_ALIAS("REGION_DATA", SRAM);
REGION_ALIAS("REGION_STACK", SRAM);
REGION_ALIAS("REGION_HEAP", SRAM);
REGION_ALIAS("REGION_LOG", LOG_DATA);
REGION_ALIAS("REGION_ARM_EXIDX", FLASH);
REGION_ALIAS("REGION_ARM_EXTAB", FLASH);

并分析这两种故障情况及其后果：

1. NVS 置于0x000
   1. 我们将使 IMAGE_VALID_CONF 无效、因为我们损坏了闪存矢量表。 因此、我们将以串行引导加载程序模式启动。
2. NVS 放置在0x56000处、或升级最后一个闪存块。
   1. 这一次、我们损坏了与我们的应用程序链接的 CCFG 配置、因为它位于闪存的最末端(0x57fa8)。
   2. 这意味着该区域被复制到实际的 CCFG 寄存器、但 IMAGE_VALID_CONF 现在无效、我们也最终会进入串行引导加载程序。

此致、

Arthur