[参考译文] MSPM0G3507：&quot；Hard Fault&quot；运行由 GNU ARM 工具链构建的映像时

您好、Chris、

这似乎是编译器问题。

它是否复制在 SDK 示例工程中？

然后、我可以向 TI 团队报告以查看任何注释。 而固定值应该是一些取决于 ARM 工具链团队的东西。

我还没有安装这个 GNU 编译器。 我的建议如下：

因此、您能否在该 API 函数内部添加一些代码对齐、并查看它是否仍然出现硬故障。 如下所示：

    __NOP();
    
    // save CPUSS CTL state and disable the cache
    uint32_t ctlTemp = DL_CORE_getInstructionConfig();
    DL_CORE_configInstruction(DL_CORE_PREFETCH_ENABLED, DL_CORE_CACHE_DISABLED,
        DL_CORE_LITERAL_CACHE_ENABLED);
        
    __NOP();

    // populate SYSPLLPARAM0/1 tuning registers from flash, based on input freq
    SYSCTL->SOCLOCK.SYSPLLPARAM0 =
        *(volatile uint32_t *) ((uint32_t) config->inputFreq);
    SYSCTL->SOCLOCK.SYSPLLPARAM1 =
        *(volatile uint32_t *) ((uint32_t) config->inputFreq + (uint32_t) 0x4);
    
    __NOP();
    // restore CPUSS CTL state
    CPUSS->CTL = ctlTemp;
    
    __NOP();
    // set feedback divider QDIV (multiplies to give output frequency)
    DL_Common_updateReg(&SYSCTL->SOCLOCK.SYSPLLCFG1,
        ((config->qDiv << SYSCTL_SYSPLLCFG1_QDIV_OFS) &
            SYSCTL_SYSPLLCFG1_QDIV_MASK),
        SYSCTL_SYSPLLCFG1_QDIV_MASK);

也许您可以使用 TI ARM CLANG 编译器进行开发、我相信它不会有问题：

https://www.ti.com/tool/ARM-CGT?keyMatch=TI%20CLANG&tisearch=universal_search 

B.R.

Sal

尊敬的 Sal：

Unknown 说：

这是在 SDK 示例项目中复制的吗？

编号 我在 为定制硬件设计编写的固件中看到了这个问题。 我确实去了 Lengths 以确认我在上面写的内容、没有时间尝试使用其中一个 SDK 示例进行复制(它可能无法在我们的自定义硬件上运行 、无需进行大量更改)。

Unknown 说：

那么、您是否可以在此 API 函数内添加一些代码对齐、并查看它是否仍然存在硬故障。

我尝试过、问题就消失了。 不过：
我已经列出了解决上述问题的方法。 因此,我知道如何 解决 这个问题的具体实例或表现。

更有趣的问题 是：

1.为什么它首先发生?
2.您的 SDK 中是否还有其他地方(例如上面提到的 FreeRTOS 代码)也可能出现该情况？

在我看来、这表明 MSPM0+ MCU 本身存在一些问题！

 这一问题的两种表现似乎有共同点、那就是 核心时钟或与其密切相关的东西发生了变化。

第一种 表现形式改变了 SYSPLL 配置(这应该对核心时钟没有直接和/或直接影响,但仍然如此),而 第二种 表现形式  在 FreeRTOS 中通过执行汇编指令将 MCU 置于睡眠状态wfi。  正如我上面所说的,我还无法(还没有)精确定位触发硬故障的特定指令,但它是  wfi 在 freeRTOS 例程中执行汇编器指令周围  vPortSuppressTicksAndSleep()的某个位置。

可以解决此问题的方法表明、特定的(汇编器)运算序列与改变 内核 时钟( 或与之密切相关的内容)相结合会触发这种硬故障。

这是 我最关心的事情。  

Unknown 说：

也许您可以使用 TI ARM CLANG 编译器进行开发、我相信它不会有任何问题

它确实看到了针对 TI ARM CLANG 编译器的"FreeRTOS 问题"(请参阅上文)、但无法再重现该问题。 无论如何：
我们在  许多其他 产品中使用 GNU ARM 工具链,并不一定要从中转移。

此外：
我分析了 触发此 硬故障的汇编器代码、没有发现任何问题。 我附上了该文件供您参考。 它包含：

1. 硬故障中报告的 LR 和 PC 寄存器的值。
2. C 例程的快照 DL_SYSCTL_configSYSPLL()。
3、对应的汇编器代码与我的个人意见,以及这个 代码 与 C 代码的映射比较准确。

地址 0x00001342处出现硬故障。

e2e.ti.com/.../DL_5F00_SYSCTL_5F00_configSYSPLL_5F00_gcc_5F00_release.txt 

谢谢、
Chris。

您好、Chris、

正如在 SDK 中实现的、它禁用缓存、 然后 从闪存填充 SYSPLLPARAM0/1调优寄存器。 南 如果编译器为了代码优化而混乱、则会导致问题。 [这就是我在此处为测试添加代码对齐的原因。]

虽然显示指令已完成、但您能否查看 CPUSS->CTL、并查看在此汇编代码执行后它是否已更新。

B.R.

Sal

尊敬的 Sal：

Unknown 说：

So. 如果编译器为了代码优化而混乱

我认为很明显编译器没有"混乱"任何东西。  TI ARM CLANG 为该操作序列生成的(优化的)汇编代码并没有太大不同：

	ldr	r4, .LCPI0_2                Address of CPUSS->CTL into r4
	ldr	r5, [r4]
	movs	r6, #7
	ands	r6, r5                  uint32_t ctlTemp = DL_CORE_getInstructionConfig(); -> r6
	movs	r5, #5
	str	r5, [r4]                    DL_CORE_configInstruction(DL_CORE_PREFETCH_ENABLED, DL_CORE_CACHE_DISABLED, DL_CORE_LITERAL_CACHE_ENABLED);
	ldr	r5, [r0, #36]
	ldr	r7, [r5]
	str	r7, [r2, #32]               SYSCTL->SOCLOCK.SYSPLLPARAM0 = *(volatile uint32_t *) ((uint32_t) config->inputFreq);
	ldr	r5, [r5, #4]
	str	r5, [r2, #36]               SYSCTL->SOCLOCK.SYSPLLPARAM1 = *(volatile uint32_t *) ((uint32_t) config->inputFreq + (uint32_t) 0x4);
	str	r6, [r4]                    CPUSS->CTL = ctlTemp;

无论如何：

Unknown 说：

您能否查看 CPUSS->CTL、看看在执行此汇编代码后它是否更新。

考虑到我调试此问题的困难、这样做有点困难、即连接调试器时不会发生、我不确定如何在初始化过程的早期阶段确定此寄存器的实际值。 欢迎您提出任何建议。

不过：
如果我正确理解您、您说禁用指令缓存可能会延迟、因为此时仍处于启用状态？
如果是、最终导致硬故障的确切后果是什么？

此外、在我看来、代码(即 TI SDK 代码)负责确保避免使用类似的代码、并且我不确定 __NOP()上面建议的说明是否是一种可靠的方法。

在上面我指出的 FreeRTOS 代码中、我可以看到dsbisb CPU 进入睡眠状态之前和之后的指令、但即使仅使用 GNU ARM 工具链 v9.2.1、也仍然会出现类似的问题。

换言之：
 TI 提出的推荐方法是什么？

您好、Chris、

哦、我忘记在调试模式下不会触发该事件。 这使它很难 obersrve。

顺便说一下、如何发现以下指令触发调试模式下的硬故障？

"PC 在硬故障下报告、将 R5写入 R3+r7  SysCtl->SOCLOCK.SYSPLLPARAM0 ="

Unknown 说：

如果我正确理解您、您说禁用指令缓存可能会延迟、因为此时它仍处于启用状态？
如果是、最终导致硬故障的确切后果是什么？

这是我的怀疑。 这方面的一项信息是 MCLK 频率及其闪存等待状态是什么？

无论如何、让我将您的发现转发给我们的工具团队、以便在此处查看任何建议。

B.R.

Sal

Unknown 说：

顺便说一句、您如何找到以下指令触发调试模式下的无硬故障？

我意识到在某个时候可以连接调试器 之后 发生硬故障并收集相应的异常堆栈帧。 这为我提供了 lr和 pc值。 然后、允许使用编译器的汇编输出以及 调试器的反汇编输出来定位相应的代码。

Unknown 说：

这方面的一个信息是 MCLK 频率及其闪存等待状态是什么？

此时、MCU 内核仍由内部 SYSOSC 提供时钟。 稍后会切换到 HFCLK 和 SYSPLL。

 DL_SYSCTL_FLASH_WAIT_STATE_2不过、闪存等待状态已经重新配置为已经、因为我们  最终在80 MHz 处运行 MCLK 和 CPUCLK。 完整的系统初始化例程如下：

/*!
 * @brief   Initializes low-level MCU parameters and peripherals.
 *
 * This function configures system PLL and derived clocks, the flash wait states and the BOR threshold.
 */
static void sysctlInit(void)
{
    // Set the brownout threshold to the highest available level.
    // This is done to avoid that the application starts running too early.
    // TODO: Why does this happen here while DL_SYSCTL_activateBORThreshold() is invoked at the end? 
    DL_SYSCTL_setBORThreshold(DL_SYSCTL_BOR_THRESHOLD_LEVEL_3);

    // 2 flash wait states are required when running at MCLK and CPUCLK of 80 MHz.
    // 1 flash wait states could be used up to 48 MHz.
    // 0 flash wait states could be used up to 24 MHz.
    DL_SYSCTL_setFlashWaitState(DL_SYSCTL_FLASH_WAIT_STATE_2);

    // Configure the HFCLK source as HFXT oscillator (i.e. the 16 MHz oscillator on the THB).
    // The second argument specifies a "startup time" in steps of ~64us.
    // The third argument enables a "monitor" that makes sure that the HFXT oscillator is actually up and running.
    // NOTE: This routine would hang in an endless loop with the latter is not true!
    DL_SYSCTL_setHFCLKSourceHFXTParams(DL_SYSCTL_HFXT_RANGE_8_16_MHZ, 10, true);

    // Configure the system PLL. As a result, we're running with a CPUCLK of 80 MHz w/ the current configuration.
    DL_SYSCTL_configSYSPLL((DL_SYSCTL_SYSPLLConfig *) &lSYSPLLConfig);

    // Configure the ULPCLK divider. The ULPCLK is derived from the same source as CPUCLK and MCLK,
    // but provides an additional divider and drives the PD0 bus clock.
    // The maximum ULPCLK frequency is 40 MHz!
    DL_SYSCTL_setULPCLKDivider(DL_SYSCTL_ULPCLK_DIV_2);

    // Switch the MCLK source from the built-in system oscillator (SYSOSC) to the "high speed" clock (HSCLK).
    // NOTE: This macro expands to DL_SYSCTL_switchMCLKfromSYSOSCtoHSCLK
    DL_SYSCTL_setMCLKSource(SYSOSC, HSCLK, DL_SYSCTL_HSCLK_SOURCE_SYSPLL);

    // Enable the "external" clock, i.e. the output CLK_OUT, which may driven from all sorts of internal clocks.
    // In this case we're gating HFCLK to it, i.e. the 16 MHz oscillator on the THB which is also the input to
    // the system PLL. This is for debug/test/verification purposes only.
    DL_SYSCTL_enableExternalClock(DL_SYSCTL_CLK_OUT_SOURCE_ULPCLK, DL_SYSCTL_CLK_OUT_DIVIDE_DISABLE);

    // Configure the "Frequency Clock Counter" (FCC):
    // The FCC may be used to measure other clocks in the MCU. In this case we're gating SYSPLLCLK2X as the clock to
    // measure and are using to LFCLK (=32768 Hz clock) to trigger the measurement.
    // The measurement starts and ends with a rising edge of LFCLK (DL_SYSCTL_FCC_TRIG_TYPE_RISE_RISE) and lasts one
    // such period (DL_SYSCTL_FCC_TRIG_CNT_01).
    //
    // An actual measurement is started w/ DL_SYSCTL_startFCC().
    // DL_SYSCTL_isFCCDone() returns true when the measurement is done.
    // The result can be obtained using DL_SYSCTL_readFCC().
    //
    // This is for debug/test/verification purposes only.
    DL_SYSCTL_configFCC(DL_SYSCTL_FCC_TRIG_TYPE_RISE_RISE, DL_SYSCTL_FCC_TRIG_SOURCE_LFCLK, SYSCTL_GENCLKCFG_FCCSELCLK_SYSPLLCLK2X);
    DL_SYSCTL_setFCCPeriods(DL_SYSCTL_FCC_TRIG_CNT_01);

    DL_SYSCTL_activateBORThreshold();

    return;
}

在此之前、只会发生以下情况：

void hal_systemInit(void)
{
    DL_GPIO_reset(GPIOA);
    DL_GPIO_reset(GPIOB);

    DL_UART_Main_reset(UART_1_INST);

    DL_GPIO_enablePower(GPIOA);
    DL_GPIO_enablePower(GPIOB);

    DL_UART_Main_enablePower(UART_1_INST);

    // NOTE & TODO:
    // This is before reconfigurung the clocks. As such, we're presumably running at 32 (instead of 80) MHz here.
    // The #defines POWER_STARTUP_DELAY and VREF_READY_DELAY have been produced by TI's IDE.
    // I'm not sure which CPU clock speed it uses to calculate these numbers.
    // To be clarified and verified.
    delay_cycles(POWER_STARTUP_DELAY);

    sysctlInit();
    [...]

Unknown 说：

无论如何、请让我将您的调查结果转发给我们的工具团队、在此处查看任何建议。

谢谢！

您好、Chris、

感谢您提供的信息。  让我与团队核实一下。

B.R.

Sal

您好、Chris、

是否可以执行 快速测试？

这将涉及在 syscltInit()的开头禁用设备上的高速缓存、轮询直到成功禁用高速缓存。 只有这样、才会继续进行 SYSCTL 配置。 最后、您可以重新启用缓存。

想知道这是否可以解决您的问题,并可能指向某些 API 缺少 Sal 提到的关于缓存禁用的步骤,或者它不够稳健,无法进行优化。

您好 Henry：

Unknown 说：

您是否可以执行 快速测试？

没问题。  不过：

Unknown 说：

轮询直到缓存被成功禁用。

我该怎么做？

感谢您发送编修。

您好、Chris、

顺便说一下、请参阅 勘误表 https://www.ti.com/lit/er/slaz742b/slaz742b.pdf 中的缓存问题披露 

我认为这是导致它进入 hardfault 的根本原因。

B.R.

Sal

@Sal：

Unknown 说：

我认为这是导致它进入 hardfault 的根本原因。

听起来像这样、但 SDK 代码中提供了权变措施。 它使用 Arm GNU 工具链时无法按预期工作。

@Henry：

我仍在等待有关"轮询直到缓存被成功禁用"的反馈。
我不知道如何验证。

此致、
Chris。

您好、Chris、

我也在等待 Henry 更新。

也许您可以尝试以下方法：

    // save CPUSS CTL state and disable the cache
    uint32_t ctlTemp = DL_CORE_getInstructionConfig();
    DL_CORE_configInstruction(DL_CORE_PREFETCH_ENABLED, DL_CORE_CACHE_DISABLED,
        DL_CORE_LITERAL_CACHE_ENABLED);
        
    while((CPUSS->CTL & CPUSS_CTL_ICACHE_MASK) !=
           DL_CORE_CACHE_DISABLED) {
           ;
    }
    
    ...

我认为这应该起作用。

顺便说一句,你能帮助转发一个 minmom exmaple 项目与 ARM GNU 编译器,这可能重现你的问题? 然后、我认为更高效地深入研究这种情况。

B.R.

Sal

大家好！

我方面的反应迟缓、对此深表歉意。

当谈到我在谈论什么,你可以只是采取萨尔建议的开始,并把它在你的职能的开始。

然后、在功能结束时重新应用状态 、然后重新启用 CPUSS。

谢谢

Unknown 说：

在 syscltInit()的开头禁用设备上的缓存、轮询直到缓存成功禁用。 只有这样、才会继续进行 SYSCTL 配置。 最后、您可以重新启用缓存。

是的...解决了这个问题。 由于插入_NOP()指令(如 Sal 所建议)也解决了问题、因此这并不会让人感到意外。 当我  DL_SYSCTL_configSYSPLL()只调用前/后禁用/重新启用缓存时、问题也会消失。

我认为这确认了与上文 Sal 进一步指出的勘误问题 CPU_ERR_01  的关系(尽管提出的权变措施显然并不适用于所有情况)。

我可以忍受这种"更包罗万象"的权变措施、前提是 TI SDK 中不存在与此勘误表相关的其他问题。

为了满足我对 "在缓存被成功禁用前轮询"的好奇心：

TRM 不会指示读取CPUSS->CTL会返回  实际状态   相应的高速缓存。 因此,我不希望读回任何与 以前写过的内容不同的东西。 显然这不是真的。  TRM 还不详细说明当 禁用缓存或预取时会发生什么情况。

您能说明一下这方面的情况吗？还是请我参考其他支持此功能的文档？

有任何反馈意见、Sal 或 Henry？

尊敬的 Christian：

对此延迟的回复深表歉意。

使用的片段可确保 在禁用缓存之前阻止执行。

这将 有助于防止 您的应用程序由于勘误而运行到默认处理程序中。

添加一些进一步的上下文、但我们正在进行  轮询、以确保禁用该轮询点以外的任何进一步缓存。 很抱歉、我之前的回答导致了任何混淆。

尊敬的 Chirs：

我将暂时关闭该主题、因为一段时间内未收到您的反馈。

如果有其他问题、请随时回复重新打开该主题。

B.R.

Sal

尊敬的 Sal：

TRM 不会指示读取CPUSS->CTL会返回  实际状态   相应的高速缓存。 因此,我不希望读回任何与 以前写过的内容不同的东西。 显然这不是真的。  TRM 还不详细说明当 禁用缓存或预取时会发生什么情况。

您能说明一下这方面的情况吗？还是请我参考其他支持此功能的文档？

很抱歉耽误了时间、但我觉得上面的回答不是回答我的问题。 也许我误解了。

Polling 可以CPUSS->CTL返回 实际状态 二进制文件？
是否有一些 文档 详细说明了 禁用缓存或预取时会发生什么情况？ 如果是、在哪里？

此致、
Chris。