[参考译文] LAUNCHXL-F280049C：FAPI 能否写入或擦除扇区内的块？

尊敬的 GI：

您提到了上述闪存 API 的4个问题。

我先谈谈第一个问题。

关于方框： 您能否用地址示例说明问题并解释您无法完成的任务？

谢谢。此致、
Vamsi

chen chen2 说：

您能否提供地址示例并说明您无法完成的任务？

FAPI 无法擦除单个块大小为128、256、512、1024、2048字节的数据块。 FAPI 扇区擦除在扇区内只有起始地址、没有结束地址。 这是 FSM 或 FAPI 的限制吗？

某些问题是由于 F021库与 pu16DataBuffer 输入数据位于不同的 LSRAM 地址空间中所导致的。 此外(.data)段与 F021库的地址空间或#pragma 控制数据不同。 如果 F021库位于与 pu16DataBuffer 输入数据不同的 LSRAM 部分、则不会将任何内容编程到闪存扇区起始地址或任何其他递增起始地址。

放置 F021库 RAMGS0_A 地址空间的结果类似、因为用于调用 F021库函数程序模式缓冲数据的#pragma 永远不会输入。 这些问题与64位对齐无关、应该添加到常见问题解答和用户 PDF 中。  

您好，Vamsi

因此、如果 FSM 控制器不起作用、我们无法通过自定义 C 代码访问闪存？  奇怪的是、我们可以通过定制 C 代码写入 LSRAM、但不能通过闪存写入 。  

尊敬的 GI：

没有 FSM 我们就不能做–这是正确的。

如您所知、闪存是一种非易失性存储器、因此它涉及一系列的电事件来擦除或编程。  该操作由 FSM 控制。

如果您没有关于这个特定主题的更多问题、我将关闭此主题。  对于其他问题、您可以打开单独的帖子-这可以帮助我们更好地跟踪问题并帮助您。

谢谢。此致、
Vamsi

尊敬的 Vamsi：

然而、我们可以通过定制 C 代码读取闪存、而无需访问 FSM 控制。 这并不能说明较早的 TM4C MCU 类和其他 ARM Cortex MCU 类自定义 C 代码有多大的时间可以访问闪存地址空间以写入扇区、而较新的 C2000 x49c 则不能访问闪存地址空间。  FSM 之外的内容会阻止这一点的实现吗？ 我曾提到 TM4C 类(flash.c)可以将缓冲器数据作为小于扇区大小的块写入闪存。

 在我看来、如果更新了代码以处理扇区对齐的64/128位内的较小写入、FAPI 似乎可以写入块。 您能否向管理部门核实何时允许更新此类 FAPI 代码？ 提出这一请求的原因显而易见、即阻止扇区中闪存单元随时间的推移而发生软件降级。

此致、

尊敬的 GI：

您能说明一点吗：您是否尝试在不进行擦除的情况下对已编程的位置进行编程？  或者、您是否正在尝试对某个扇区中的未编程位置进行编程、该扇区中还有一些其他位置已编程？

谢谢。此致、
Vamsi

chen chen2 说：

您能否澄清一件事：您是否尝试在不擦除的情况下对已编程的位置进行编程？  [/报价]

否、块均为扇区中的 FFFF。 我确认了 TM4C 能够以128KB 甚至256KB 的块级写入闪存、并首先擦除该块、而不是扇区中的所有块。 应用程序通过使用块的程序数据第一个字作为指针来索引块、添加1以增加到下一个空闲块。 现在我必须做一些奇特的补丁来跳过15个 块到下一个要擦除的扇区的开始。   

很好的一点是、我保存了这个项目、因为它只是在上一个 PM 进行的、它在断电前一直工作得很好。 疯狂 NMI 异常停止了调试中无效的代码、从蓝色部分开始执行此操作。 因此，我修改了在函数中用于验证扇区块校验和是否有效的 cast 指针(unit16_t ) into array[]缓冲区*名称。 我认为 CPU 在环路计算快速块校验和方面有问题、导致运行时 NMI、但不能调试。 因此、我将闪存读取等待状态从5提升到6、在缓冲铸字指针之前、这些代码段没有区别。 在移除目标电源后仍然无法工作、但在每次关闭 DEBUG 和 CCS 后都会复位。 这个问题让我感到困惑、有什么想法为什么甚至在4环路中增加延迟并没有帮助？

Fullscreen

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

#pragma CODE_SECTION(FlashPBIsValid, ".fapi.ramfunct");

#pragma FUNCTION_OPTIONS (FlashPBIsValid, "--opt_level=0 --opt_for_speed=0")

static bool

FlashPBIsValid(uint16_t *pui16Offset)

{

static uint32_t ui32Idx;

static uint32_t ui32Sum;

uint16_t uc16Offset[0]; // stops debug NMI

*uc16Offset = *pui16Offset; // stops debug NMI

//

// Check the arguments.

//

ASSERT(pui16Offset != (void *)0);

//

// Loop through the bytes in the block, computing the checksum.

//

for(ui32Idx = 0, ui32Sum = 0; ui32Idx < g_ui16FlashPBSize; ui32Idx++)

{

ui32Sum += uc16Offset[ui32Idx];

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#pragma CODE_SECTION(FlashPBIsValid, ".fapi.ramfunct");
#pragma FUNCTION_OPTIONS (FlashPBIsValid, "--opt_level=0 --opt_for_speed=0")
static bool
FlashPBIsValid(uint16_t *pui16Offset)
{
    static uint32_t ui32Idx;
    static uint32_t ui32Sum;
    uint16_t uc16Offset[0]; // stops debug NMI
    *uc16Offset = *pui16Offset; // stops debug NMI

    //
    // Check the arguments.
    //
    ASSERT(pui16Offset != (void *)0);

    //
    // Loop through the bytes in the block, computing the checksum.
    //
    for(ui32Idx = 0, ui32Sum = 0; ui32Idx < g_ui16FlashPBSize; ui32Idx++)
    {
        ui32Sum += uc16Offset[ui32Idx];

    }
       //
    // The checksum should be zero, so return a failure if it is not.
    //
    if((ui32Sum & 255) != 0)
    {
        return(0);
    }

    //
    // If the sum is equal to the size * 255, then the block is all ones and
    // should not be considered valid unless is the first block to write.
    //
    if((g_ui16FlashPBSize * 255) == ui32Sum)
    {
        return(0);
    }


    //
    // This is an invalid parameter block keep searching.
    //
    return(1); //
    
}

   

尊敬的 GI：

您是否在寄存器中检查了 NMI 的原因？

谢谢。此致、
Vamsi

尊敬的 Vamsi：

读取最后一个帖子、它总结了上面的校验和代码导致闪存 NMI 异常的原因以及原因。 同时尝试 Fletcher 校验和实用程序来替换上述函数的 sum 部分。 将报告是否已取得任何进展。

LAUNCHXL-F280049C：_C_Int00 ()之后的所有闪存寄存器均为0x0 - C2000微控制器论坛- C2000 ︎ 微控制器- TI E2E 支持论坛

由于 Fletcher 校验和具有与上述代码 snip 相同的调试 NMI、因此没有进度。 似乎读取扇区在它出现故障之前有一个总和。 这是4个闪存随机读取等待状态、其中3个等待在 F6中出现故障的时间要快得多、因为 F7的步骤跳转到 NMI 异常。 然而、3个等待状态会导致返回错误的校验和、并且很少出现 NMI 异常。

奇怪的是 、只有在 FAPI 对具有155KB 写入字节的扇区256KB 块进行编程后才会发生足够的 ECC 错误。 执行任何类型校验和的应用程序都会导致闪存 NMI。 闪存初始化等待状态值无法停止 ECC 错误导致的 NMI 异常、因为扇区起始地址仅在 FAPI 对扇区进行编程后才会损坏。

3.4.7 DCSM 安全代码复制复位(SCCRESET)
该器件具有一个双区域代码安全模块(DCSM)、用于阻止对闪存某些区域的读取访问。 为了方便 CRC 检查和 CLA 代码复制、TI 提供了 ROM 函数来安全访问这些内存区域。 为防止安全漏洞、在调用这些函数之前必须禁用中断。 如果在安全复制或 CRC 函数中发生向量获取、DCSM 会触发复位。 该安全复位(SCCRESET)与 SYSRS 类似。 但是、安全复位也会重置调试逻辑以拒绝对潜在攻击者的访问。 一个安全复位后、RESC 内的 SCCRESETn 位被置位。

其中是 RESC 寄存器所在的位置、不在 DCSM 寄存器视图中。

您好 Vansi：

FAPI 似乎在 Fletcher 校验和期间启用 ECC。 尽管我在闪存初始化后禁用了 ECC、因此 Fletcher 校验和不应默认使用 ECC？

已尝试在 Fletcher 校验和之前禁用 ECC、并在多处启用 After。 虽然类似的策略并不停止 NMI 复位、但当应用程序检查先前编程的具有空白空间的块中的相同扇区空闲空间时。 当任一扇区的启动为 FFFF (65535)时、区域安全只允许校验和或者其它空白测试。 原因似乎是 DCSM 安全勘误条件。 当闪存区被解锁时、DCSM 只允许将该扇区从起始地址编程一次、不会添加数据中块、甚至可能会添加到扇区的末尾。 当区域安全中断读取数据时、会发生 ECC 错误。   

//调用闪存初始化以设置闪存等待状态。 这个函数必须
//存储在 RAM 中。 它确实存在 LSRAM2_3段(.TI.ramfunc)
FLASH0CTRL_base、FLASH0ECC_BASE、5)；

/*禁用 ECC 模式*/
FLASH_disableECC (FLASH0ECC_BASE)；

尊敬的 GI：

Fletcher 校验和未启用 ECC。

谢谢。此致、
Vamsi

尊敬的 Vamsi：

同意但足够有趣的是 FAPI 初始化 似乎启用了 ECC。 我可以在 Fletcher 运行之前禁用 ECC、但 SUM 永远不会完成、因为 DCSM 驱动 NMI、看门狗停止器件篡改。 因此在运行时、当任一方法校验和有效时、MCU 会复位。 校验和在头155个字节被写入第一个块后在空闲空间内启动中块、这个块中新的空闲空间不在64位边界上、并且可能是 NMI 的原因。  

尊敬的 GI：

FAPI 初始化不启用 ECC。

driverlib 的闪存初始化函数用于启用 ECC。  我敢肯定、您早就应该看到过该代码了、因为该代码可用了。

谢谢。此致、
Vamsi

尊敬的 Vamsi：

我在上面发布的代码片段显示了 ECC 在闪存初始化后被强制禁用。  FAPI 设置活动闪存组或 FAPI 初始化在禁用 ECC 后重新启用 ECC。 在 Fletcher 校验之前禁用 ECC 有些因素对于在调试步进时停止 NMI 仅读取第一个扇区块中间的闪存地址空间没有什么影响。

请注意、TOO FAPI 在初始化后立即选择校验和 FAPI 设置激活的闪存组。 我没有使用 OPT ROM、尽管 FAPI ECC 程序空间也是如此、OTP 校验和可能会导致 DCSM 安全问题、Vivek 也提到了这一点。 我似乎放错了位置、认为应用程序没有触及 ROM、在解锁 DCSM 的任何部分中、它都不应该是问题。  POR 或硬复位 NMI 异常会停止 SCI 以打印502错误消息。 也许、OPT 校验和在那时导致了非法异常、无法由 CCS 调试、因为它仅在运行时发生。   

尊敬的 GI：

没有任何闪存 API 函数启用 ECC。  NMI 复位可以启用它。

闪存 API 会读取不安全的 TI-OTP 以确保闪存修整完好无损(通过校验和)。  如果您使用 ROM 闪存 API (您吗？ 请确认)、则 ROM 闪存 API 也不安全。  因此、在安全性方面、ROM 闪存 API 读取 TI-OTP 应该不会有任何问题。

即使不使用 ROM 闪存 API、闪存 API 读取不安全的 TI-OTP 也不应导致任何问题。

谢谢。此致、

Vamsi

我没有使用 ROM 闪存 API。  使用 F021_F32_eabi 库加载到 LSRAM 中。 我注释掉了 FAPI 集活动闪存组、在 POR 后仍无法引导。 在注释掉通过 Flecher 检查有效阻止的调用后、猜测 OTP 校验已完成。 然而、MCU 不会复位或 POR 引导、除非在闪存初始化到 LSRAM 后在 HAL 中注释掉调用以加载 FAPI 模块。

尊敬的 GI：

您从何处获得 F021_Float32_eabi 库？  这到底有什么作用？  您是否生成了它？  如果需要、您是如何生成  F021_Float32_eabi 库的？

请澄清。

谢谢。此致、

Vamsi

Vamsi、F021 float32库并非全名称、尽管它似乎通过 pu16DataBuffer 支持浮点 pinot 数据类型。 如果不确定、可能您使用的 FAPI 版本不包含 F021 float32库文件。 我之前向您询问过这个库、但从未回答过为什么它是 API 的一部分。

chen chen2 说：

即使您未使用 ROM 闪存 API，闪存 API 读取不安全的 TI-OTP 也不会导致任何问题。

OTP 校验和会通过高速 PLL (100MHz)失败、但通过 UniFlash 10MHz PLL 成功。 由于 OTP 校验和无故障、UniFlash 可以通过软件复位 MCU。 相似、以通知 FAPI 程序模式似乎已在闪存组0链路指针存储器空间中写入随机字节。 DCSM 链接指针大于1个字节、并且不属于的链接指针在较高的地址范围内存在垃圾字节。  

这可能发生了自动 ECC 程序模式、期望它递增 pu16DataBuffer、而设计人员不需要提供递增的指针4循环。 对我来说、字长可以推断应用程序输入缓冲区长度、而使用8的示例是任意值8个字。 TM4C 应用程序具有 while (1)循环、no 4循环。 FAPI 不应该知道他的库对齐(.bss)段是 align (4)而非 align (8)。 该 FAPI 代码 C2000ware v4.1在设计时存在风险、需要在其编程模式中添加保护频带。 也许 XDC110会对 DCSM 链路指针闪存地址进行128位写入、而不是64位写入。 奇怪的是、足够的程序起始地址位于组1中、而不是组0中、其中 FAPI 损坏了空链接指针存储器。

读取 OTP 和闪存扇区校验和时存在其他间歇性故障、勘误表中未列出。 在100MHz PLL 速度下、两个 F021库中的任何一个都生成相同的结果、即 OTP 校验和随机故障。 通过 UniFlash 无法检测到这个问题、因为每次以10MHz PLL 速度通过 OTP 校验和时都不会生成 NMI。

直到本周、我才可能使用 UniFlash、有人可能已经提到它具有 DCSM 实用程序。 我知道这个名称、但我相信它只是一个像 DFUprog 这样的命令行固件闪存实用程序。 CCS 调试功能不像 UniFlash 那样具有 DCSM 区域的寄存器阵容。

chen chen2 说：

Float32标记在编译此库期间启用意味着该库可以嵌入在启用了 float32标记进行编译的项目中。

奇怪的是，这两个库仍然可以使用命令(--float_support=fpu32)进行嵌入式编译。   

chen chen2 说：

您是否说 PLL 只能锁定10MHz？  请澄清。

是的、UniFlash 根据 settings/utils 选项卡设置 PLL 10MHz、而 CCS 调试不会设置。 并且 ROM 引导在停止调试后工作、硬复位会运行 FAPI 设置活动的闪存组、直到第一次 POR、然后它会中断。

尊敬的 GI：

1)当你说"两个图书馆"时,这两个是什么? 请澄清。

2) CCS 闪存插件和 Uniflash 使用相同的配置-应该没有任何区别。  我没有单独开发它们-两个都使用相同的代码库。  Uniflash GUI 设置 显示它使用10MHz INTOSC2作为时钟源 -它不是 SYSCKOUT。  与 CCS 闪存插件相同- CCS 闪存插件 GUI 也显示了相同的内容。   

谢谢。此致、
Vamsi

chen chen2 说：

1)当您说"两个库"时，这两个是什么？ 请澄清。

F021 eabi 库、而不是 F021 ROM 库。 在编译期间似乎没有任何区别、F32开关是有争议的。

chen chen2 说：

与 CCS 闪存插件相同- CCS 闪存插件 GUI 也显示了相同的内容。   [/报价]

实际上、CCS 调试 HAL 正在为 SYSCLK 100MHz 设置 PLL、可以 通过 寄存器视图确认。 XDC110在调试中设置为5.8MHz。

当(.data)放置在 RAMGS0_A 中时、Fletcher 校验和通常会溢出(长) 256KB 块的校验和有156个存储的字、块的其余部分为 FFFF。 当(.data) 放置在 LSRAM2_3和 F021 eabi 库(LSRAM0_1)中时、块校验和更一致、因为禁用源步进 ISR 会在调试选项中设置为禁用源步进。 详见下文，例如：

当设置为禁用调试选项时、CCS 调试断点运行会话会启用 ISR 源步进。 当(.data)置于 RAMGS0_A 步进模式(F5、F6、F7)时的工作原理基本符合预期、而在 LSRAM2_3中为(.data)时、禁用源步进 ISR、步进变得非常慢、甚至有时会停止。 一个新发布将说明(静态)指针>>如何在 F7步进中移动变量值以返回到抢占式 ISR 步骤。

因此、函数的前一个声明指针>>值移位。 示例：Fletcher 校验和之前声明的指针地址0x0009C000、当优先处理 ISR 时、(F7)返回 Fletcher、相同的静态 指针现在为0x000000C0。 注意：CPU IP 位于 ISR 函数的开头、F7会将远低于22位的指针数据移位、这些数据远低于编译器指针限制。 C2000编译器禁止分配易失性指针、但静态函 数通常用于 ARM Cortex。

尊敬的 GI：

在开始讨论 Fletcher 校验和之前、您能否告诉我、这篇帖子的原始问题是否已得到解答？  

如果是、让我们在另一篇文章中开始 Fletcher 校验和问题。

谢谢。此致、
Vamsi