[参考译文] LP-MSPM0G3507：运行异常状态的 Lauchpad、如何复位

您是否尝试了 BSL 技巧？

1)按住 NRST 和 S1 (左侧)按钮

2) 2)释放 NRST、然后释放 S1

3)立即开始下载代码。 (我读取大约10秒的 BSL 超时)。

对我来说很有用。

重试、我仍然得到错误-6305

哦、这很有趣、进行低电平 CMSIS-DAP 连接、我无法连接到接入点0 (不存在)；但我可以连接到接入点1 (IDR = 0x002e0001)。 因此、如果我知道要写入什么地址的值、我就可以返回到它。

唉、接入点1通常是专有的、因此我猜只有 TI 知道它访问什么、以及您可以更改什么...

在 AP=1时、我可以读取大约0x1000000的寄存器、它看起来和我的代码不太一样、但是是从器件中读取的数字、这是一个很好的符号。 在假设下、这些是存储器地址(大假设)、提供 NONMAIN 存储器区域的地址以及0x00 -如果从存储器读取、这将解释为什么我不能引导...

如果它能帮助 TI 的任何人了解 AP=1下发生的情况、那么读取时的前几个寄存器会提供

0x1bb8802f
0x80c7ae2d
0x40000010
0x00000000
0x00000036
0x00000096

尊敬的 David：

MSPM0中的 AP=1是 CFG-AP、除了用于记录一些潜在错误之外、还提供一些基本的器件信息、包括会作为修整区域、BSL 或 BCR 配置区域的 CRC 故障关联的引导诊断错误。  

我没有解码器来了解该诊断错误是什么或它会放置在什么位置、但我正在检查它以查看我是否可以从您分享的内容中捕获任何内容。  

与此同时、您是否对 Non-main 进行了任何修改？  

此致、
布兰登·费舍尔

我发出了一条命令、其副作用是擦除闪存。 由于编码错误、它也会擦除 NONMAIN、或者至少是我怀疑发生了什么。 我将会写入 SWD 和 BSL 寄存器以启用它们、因此我怀疑这两个寄存器都一次性禁用了！

我所希望的是通过 AP=1、我可以重新开启 SWD、可能在另一次整体擦除之后。 然后、至少从 SWD 开始、我可以手动将正确的值键入到 NONMAIN 中、并使 LaunchPad 恢复运行。

如果无法通过 AP 重新打开 SWD、我怀疑是完全让机器变硬了。

再找点东西。 我可以访问 AP=1和 AP=2、其它所有 AP 不再存在。

猜猜猜、这个问题会出现在 AP=1还是 AP-2是否可以重命名 SWD？

另一个可能的方向是、在这种锁定模式下、是否要遵守 JTAG？ 我想48引脚 MSPM0G 有足够多的引脚来具有完整的 JTAG -只需检查这些引脚是什么以及它们的输出位置即可。 理论上、我有可用于 JTAG 的 FTDI 线缆、但之前从未使用过-但给出了另一个可能的方向。

因此从 TRM 的第26节来看、如果我可以写入 DEBUGSS 寄存器、尤其是 EXTRAC_AUTH @ 0x1200、我可以更改对 SWD 的访问。

现在、根据其外观、AP = 1访问0x1000000以上范围内的 AP 寄存器、而 AP = 2访问0x2000000及以上范围内的 AP 寄存器。

这就表明、只有 AP=0能够访问0x1200、并且 Special_AUTH 能够启用 SWD；而且由于我无法访问 AP=0、因此无法访问寄存器。

各行之间都有相当多的读数。 例如、CMSIS-DAP 接口正在显示的 AP 寄存器与 TRM 第26节中显示的 DEGUGSS 偏移相同。

以及今天我要介绍的内容。

我所做的也许是被一个编码错误擦除闪存的非主区域。

我将要擦除的关键变量(写入值0xffffffff)是 BOOTCFG0、BOOTCFG1、BOOTCFG2、BOOTCFG3 -有一串其他变量连接到 BSL、但应该没问题。 我的 CRC 可能是垃圾、也可能不是垃圾。

现在所有文档都说这样做完全关闭了 SWD-DAP 和 BSL、因此机器被严重惊吓了。

但是、连接到 CMSIS-DAP、虽然 AP = 0、3、4已关闭、但 AP = 1、AP = 2仍处于活动状态。 我无法确定 AP=2中的值、但 AP1似乎是64个字、值然后重复。 令人奇怪的是、AP=1和 AP=2仍然处于打开状态、文档中的所有内容都表示应该关闭-因此没有记录。

TRM 第26节指出、AP = 1是配置、AP = 2是调试邮箱。

为了启动 SWD (如果确实可行)、我需要做些什么、好做以下的原始写入等效操作：

  DEBUGSS->SPECIAL_AUTH|=DEBUGSS_SPECIAL_AUTH_SWDPORTEN_ENABLE
    |DEBUGSS_SPECIAL_AUTH_SECAPEN_ENABLE;

可以正常工作、我将*可以*作为在 SDK 中的只读、这表明该外设寄存器可能只报告状态、不能用于设置。

除此之外、我需要一种方法在非 main 中重写几个变量、这只能在 SWD 中发挥作用、因此有问题：是否有后门可用？

现在、slau887.pdf 引导加载程序用户指南的第3.2.4节指出了我可能能够使用 DSSM (调试子系统邮箱)启动引导加载程序- DSSM 处于 AP=2下、这是少数仍正常运行的 AP 之一。 现在、引导加载程序可能会拒绝启动、因为非主变量是垃圾；但这不清楚、选项也是如此。 如何使用 AP=2 (DSSM)来启动引导加载程序,我也不清楚... 另外、如何让 DSSM 通过 AP=2寄存器启动引导加载、我想也不清楚。

这种情况真的只剩下了、是否有一个后门处于 AP=1或 AP=2中、如果通过对非主程序执行 trashed、我就可以回到机器中、将校正值写入非主程序？

检查 MSPM0G 芯片数据表后发现、似乎从未提供 JTAG；它始终是 SWD 连接、SWD 连接取决于启动 ROM、所以它是软件提供的接口。

我今天早上的位置。

写入 DEBUGSS->SPECIFIC_AUTH 似乎不可行，或没有用处。 TRM 提供它的只读(通过约束、或者它只提供信息、但不控制行为)。

因此、这使得 DSSM AP=2非常有用。 很明显可以发送对 DSSM 有用的消息、TI 文档一直对此进行记录、有 DSSM 出厂复位(可能对我禁用)、DSSM 消息可以调用 BSL (可能无法为我启动)。 但对我来说有两个问题：

1. 如何从低级别的 AP=2寄存器访问 DSSM
2. 我可以发送哪些有用的消息

其中2是棘手的问题、即您可以向谁发送消息、谁侦听。 TI 文档中明确的一点是、您可以与它交谈的是从 ROM 运行的 TI 引导程序、这听起来大多数功能都在哪里。 唉,我没有找到任何文档,关于什么消息的引导 ROM 代码将作出反应.

不管怎样、如果我能弄清楚如何通过 AP=2发送消息、以及要发送什么消息到引导 ROM、那么可能有一个纤薄的希望。 此外、TRM 也希望完全锁定 NONMAIN 需要设置为只读、嗯、我的仍然是 RW、只是中的值错误。 因此、如果我可以通过 DSSM 消息获得一些东西来写入 NONMAIN、这可能是一种解决办法。

虽然听起来仍然没有希望,至少有两个未知数以上...

再多读一点、我可能需要做的是 DSSM 出厂重置-我想它通过 DSSM AP=2进行、我仍然在运行； 恢复出厂设置也将非主模式的寄存器设置为原始版本、这将使我恢复计算机的运行。

现在预计这里的 TI 人会告诉我 CCS 可以使用、所以我解雇了 CCS Theia。 它已被识别并且已插入 MSGM0G3507、但如何告知 CCS Theia 通过 DSSM 发送 DSSM 出厂复位？

尊敬的 David：

CCS Theia 没有我所知道的相关界面。 CCS Eclipse 会用到。

但是、您可以尝试使用 M0解锁 GUI、而不是为此下载 CCS、而是转至： https://dev.ti.com/gallery/view/TIMSPGC/DSSM_Unlock/ver/0.0.2/

如果 DSSM 出厂复位失败、它可能已禁用、这意味着 NONMAIN 可能已擦除、 您将被锁定。  

此致、
布兰登·费舍尔

Mo Unlock GUI 显示：

选择 MSPM0G3507
调用 GEL 函数：恢复出厂设置

但 MSPM0G3507不会重新启动、

以及：

pyocd> makeap 0
Error: no AP with APSEL=0 exists
pyocd> makeap 1
AP#1 IDR = 0x002e0001
pyocd> makeap 2
AP#2 IDR = 0x002e0000
pyocd> makeap 3
Error: no AP with APSEL=3 exists
pyocd> makeap 4
Error: no AP with APSEL=4 exists

因此 AP=0还没有启动。 但 AP=2 DSSM 消息仍然是这样。

现在 TRM 给出了一切都关闭的想法、但随着 DSSM 消息仍在发出、我可以清楚地向 ROM 引导发送消息。 那么、可以发送什么消息、ROM 引导将侦听什么消息、它执行什么操作、以及我必须发送什么 uint32_t？

我可以看到您可以发送：

#define DSSM_BC_FACTORY_RESET                           (0x020AU)
#define DSSM_BC_MASS_ERASE                              (0x020CU)
#define DSSM_BC_PW_AUTH                                 (0x030EU)
#define DSSM_DATA_EXCHANGE                              (0x00EEU)

但是如何发送这些代码、事件似乎没有这些信息。

是否有任何其他代码、显然有一个 TI 必须重置机器并进行诊断。

或者、您说的是任何意外执行批量擦除的人、也可能只是将 CPU 丢弃、因为它永远不会从 ROM 引导中退出、并且没有后门？

它看起来像 AP 寄存器0x2000000 = DSSM 寄存器 TX_DATA
AP 寄存器0x2000004 = DSSM 寄存器 TXCTL
AP 寄存器0x2000008 = RX_DATA
AP 寄存器0x200000A = RXCTL

不清楚 ROM 引导正在侦听消息。

在某处进行了解释。 位会存储在 TRM 中、但并非所有位。 ROM 引导是如何工作的、因此没有什么好说的。 我应该读些什么吗？

OK slaae29提供了一点更多信息。 早期启用 CFG-AP 和 SEC-AP。 实际上、我可以在 RESET 下访问、其中包含以下信息：

pyocd> initdp
pyocd> readap 1 0x1000000
AP register 0x1000000 = 0x1bb8802f
pyocd> readap 1 0x1000004
AP register 0x1000004 = 0x00000000
pyocd> readap 1 0x1000008
AP register 0x1000008 = 0x40000010
pyocd> readap 1 0x100000c
AP register 0x100000c = 0x00000000
pyocd> readap 1 0x1000010
AP register 0x1000010 = 0x00000000
pyocd> readap 1 0x1000014
AP register 0x1000014 = 0x00000055
pyocd> readap 1 0x1000018
AP register 0x1000018 = 0x00000000
pyocd> readap 1 0x100001c
AP register 0x100001c = 0x00000000
pyocd> readap 2 0x2000000
AP register 0x2000000 = 0x00000000
pyocd> readap 2 0x2000004
AP register 0x2000004 = 0x00000000
pyocd> readap 2 0x2000008
AP register 0x2000008 = 0x00000000
pyocd> readap 2 0x200000c
AP register 0x200000c = 0x00000000

紧随 RESET 被释放后的信息更改

pyocd> initdp
pyocd> readap 1 0x1000000
AP register 0x1000000 = 0x1bb8802f
pyocd> readap 1 0x1000004
AP register 0x1000004 = 0x80c7ae2d
pyocd> readap 1 0x1000008
AP register 0x1000008 = 0x40000010
pyocd> readap 1 0x100000c
AP register 0x100000c = 0x00000000
pyocd> readap 1 0x1000010
AP register 0x1000010 = 0x00000036
pyocd> readap 1 0x1000014
AP register 0x1000014 = 0x00000096
pyocd> readap 1 0x1000018
AP register 0x1000018 = 0x00000000
pyocd> readap 1 0x100001c
AP register 0x100001c = 0x00000000
pyocd> readap 2 0x2000000
AP register 0x2000000 = 0x00000000
pyocd> readap 2 0x2000004
AP register 0x2000004 = 0x00000000
pyocd> readap 2 0x2000008
AP register 0x2000008 = 0x00000000
pyocd> readap 2 0x200000c
AP register 0x200000c = 0x00000000

寄存器0x2000000显然是 DSSM TX_DATA -我可以写入它、0x2000004变为0x1、因此0x2000004看起来是 DSSM TXCTL。 这里显示我已经将数据写入 TX_DATA、而 CPU (在发送中断的地方)还没有读取这些数据。 实际上、TXCTL 永远不会从0x1变为其他值、因此引导 ROM 永远不会读取该消息。

结论。 CFG-AP 可能告诉我该机器的状态、但如何读取这些数字尚不清楚。 找不到任何描述它们的信息。

SEC-AP/DSSM 上的消息格式除几位外不清楚、这些位的打包方式也不清楚。 消息虽然不相关、但只能发送到 CPU、并且引导 ROM 不会读取这些消息。

结论是 MSP 去世了。 LaunchPad 现在只有一个小小的 MSP432在工作、可用作通用 SWD 接口；但除此之外、电路板也可能会被丢弃。

这可能会由于(意外)批量擦除而发生令人难过-但这就是它的样子。 如果我得到更换、我会吸入空气。 MSPM0 SDK 是一个很好的接口、我喜欢其中的代码(在获取代码时)。 但 MSPM0关于其有用器件的信息不够。 它确实需要一个大贴纸上说不要大规模擦除,这将看起来丑,但然后又是丑.

σ。 哦，好吧……

Edit -只是从在线恢复出厂设置中获得了更多信息、它确实成功连接到了 SEC-AP 端口、并将数字0x2000004写入 AP 寄存器0x20b -很有意思-我读出的是 TXCTL、这是允许我写入的、 有趣的是、它与我在上面找到的0x20a 不同。

但似乎证实了我只是将这些原始数字写入相关端口。 因此、如果我有一个新的板、我可以检查一下这个。

我跟 Brandon Fisher94 通过私人信息跟进-他是很好的关于它,所以它被赞赏。

不管怎样,布兰登已经安静了一个星期左右,猜他是在度假或其他事情。

那么让我来总结(从我的角度而言)发生了什么以及为什么。

我之前使用的是"pyocd"命令(我知道这不是 TI 支持的命令、但它对我来说很有用、因为它在命令行中工作、并且可以放入 make 文件-因此我可以使用 make 从命令行进行完全编译)。

我发出"pyocd"命令"unlock "-我没有意识到这是一个批量擦除,这在 pyocd 网站上的其他地方被记录。 有些 Arm cortex M 器件具有批量擦除功能、允许访问器件、这就是"pyocd"具有"unlock"命令的原因。 我@和 pyocd 作者 Chris Reed 的 ARM 讨论了-他是另一个好人,关心他做什么;并开发 pyocd 作为一个通用的皮层单层接入设备,它很棒,它提供"gdb"访问 CPU ,所以可以做断点等. 现在、"解锁"的问题在于它可以解锁某些 ARM cortex 器件、但对于 TI MSPM0系列、它通过清除 NONMAIN 存储器区域来致命地砖化机器。 Chris Reed 承认这一点、并会查看围绕这一点的方法。

但有什么明确之处是、虽然几乎所有其他 ARM cortex 器件进行批量擦除是安全的、但对于 TI MSPM0器件来说不是如此、这样会关闭 BSL 复位、并且还会关闭 CMSIS-DAP 下所需的 AP=0通用接口。 确实、复位 MSPM0器件的唯一安全方法没有详细记录、您可以收集信息、但它很难找到。 具体来说、唯一的安全复位选项是"出厂复位"、通过向 AP=2地址0x2000000或0x2000004写入0x20a 或0x20b 来完成-此处必须模糊、因为我无法使用砖型器件测试这些选项。 另外需要明确的是、这是一种 TI 重置电路板的方法、具体而言不是 ARM cortex 器件的通用方法、仅适用于这组特定的器件。

这是值得去看看 pyocd 是如何工作的,为什么它没有做任何错误。 pyocd 的工作原理是使用 CMSIS-DAP 包、此 TI 确实支持、尤其是： http://software-dl.ti.com/msp430/esd/MSPM0-CMSIS/keil/latest/exports/TexasInstruments.MSPM0G_DFP.1.1.0.pack

值得在以下文件中查看用于对这些器件进行编程的代码：TexasInstruments.MSPM0G_DFP.PDSC：

                <!-- *************************  Device MSPM0G3507  ***************************** -->
                <device Dname="MSPM0G3507">
                    <memory     name="IROM1" access="rx"  start="0x00000000" size="0x00020000" startup="1" default="1"/>
                    <memory     name="IROM2" access="rx"  start="0x00400000" size="0x00020000" default="0" alias="IROM1"/>
                    <memory     name="IRAM1" access="rwx" start="0x20000000" size="0x00008000" default="0"/>
                    <memory     name="IRAM_Parity" access="rwx" start="0x20100000" size="0x00008000" default="0" alias="IRAM1"/>
                    <memory     name="IRAM_No_Parity" access="rwx" start="0x20200000" size="0x00008000" default="1" alias="IRAM1"/>
                    <memory     name="IRAM_Parity_Code" access="rwx" start="0x20300000" size="0x00008000" default="0" alias="IRAM1"/>
                    <memory     name="NonMain_ECC" access="r"  start="0x41C00000" size="0x00000200" default="1"/>
                    <memory     name="NonMain_noECC" access="r"  start="0x41C10000" size="0x00000200" default="0" alias="NonMain_ECC"/>
                    <memory     name="Factory_ECC" access="r"  start="0x41C40000" size="0x00000080" default="1"/>
                    <memory     name="Factory_noECC" access="r"  start="0x41C50000" size="0x00000080" default="0" alias="Factory_ECC"/>
                    <compile    define="__MSPM0G3507__"/>
                    <debug      svd="03_SVD/MSPM0G350X.svd"/>
                    <algorithm  name="02_Flash_Programming/FlashARM/MSPM0G_MAIN_128KB.FLM" start="0x00000000" size="0x00020000" RAMstart="0x20200000" RAMsize="0x00008000" default="1"/>
                    <algorithm  name="02_Flash_Programming/FlashARM/MSPM0G_NONMAIN.FLM" start="0x41C00000" size="0x00000200" RAMstart="0x20200000" RAMsize="0x00008000" default="0"/>
                </device>

您可以看到它是如何描述部分存储器的、甚至给出了代码*。FLM 来写入这些区域。 该软件包还包含这些 FLM 文件-它们只是 ARM 可执行文件、我可以看到它们链接到许多标准 TI 库。 需要注意的重要位是"DEFAULT"标志-在 CMSIS-DAP 标准中、这意味着 DEFAULT=0表示可以使用此段、但可以被另一个段取代、DEFAULT=1表示此段*必须*用于写入该区域。 因此您可以看到、电池组明确表示您应该 通过存储器的 ECC 区域进行写入/读取。

现在、有趣的位是在算法标签中、MAIN 存储器具有 default=1、而 NONMAIN 具有 default=0。 这意味着、写入 MAIN 存储器时必须使用 MSPM0G_MAIN_128KB.FLM 算法、对于 NONMAIN、*可以*使用 MSPM0G_NONMAIN_FLM。

这就是 pyocd 有问题的地方、它使用了 MSPM0G_NONMAIN.FLM 算法、清除了0x41c00000存储器区域、因此它遵循"May"指令。

我心目中的潜在问题是、CMSIS-DAP 包未指定执行 NONMAIN 批量擦除 会使器件砖化、实际上、我不清楚您如何指定这一点。 也许 MSPM0G_NONMAIN.FLM 应该拒绝对 NONMAIN 执行批量擦除、因为在 MSPM0器件上、您永远不应该整体擦除存储器区域-这没有意义。 在最好的情况下,你可能*非常*只有写入几位。 [例如、MSPM0G_NONMAIN/FLM 中的算法 EraseSector 和可能的 EraseChip 拒绝擦除 NONMAIN 存储器错误、而是返回 STATUS=1、因此更改字节的唯一方法是 ProgramPage 命令、擦除则是将0xff 写入字节]。

另一个 odity 是：MSPM0G_NONMAIN.FLM 中包含非主闪存的默认值。 它们位于 nonMainDefaultBCR @ 0x564和 nonMainDefaultBSL @ 0x6e4 -但尚未在汇编语言中找到此参考。 但确实建议、NonMain 算法的确知道在写入闪存的这个区域时需十分小心。

现在、使用将访问 BSL 和 CMSIS-DAP 端口的字作为0xFFFF、可以保障批量擦除安全。 然后任何位闪烁仍会锁定器件(这是 TI 的设计要求)、但批量擦除会使机器保持打开状态、似乎没有任何安全漏洞。 但 TI 选择了另一个字、意思是让 CMSIS_DAP 和 BSL 保持开路。

那么、这里的结论是什么呢。 MSPM0器件在 NONMAIN 和器件锁定方面与我认为所有其他 ARM Cortex 器件都有很大不同、因此必须是一个特殊情况。 哦、这门课程不能帮助机器返回、但解释了这些设备是如何工作的。

我想在讨论 CMSIS-DAP 包时、一个值中存在一个小错误、我想值得指出、因此可以在下一个版本中更新。 具体而言、代码明确测试版本号大于或等于1；例如、它不适用于开发板。 但是、如果你看看描述 LaunchPad 的位：

    <boards>
        <board vendor="TexasInstruments" name="LP-MSPM0G3507" salesContact="">www.ti.com/.../contact.tsp">
            <description>MSPM0G3507 LaunchPad</description>
            <mountedDevice    deviceIndex="0" Dvendor="Texas Instruments:16" Dname="MSPM0G3507"/>
            <compatibleDevice deviceIndex="0" Dvendor="Texas Instruments:16" Dfamily="MSPM0G Series" DsubFamily="MSPM0G350X"/> 
            <debugInterface adapter="XDS110-ET" connector="XDS110-ET Onboard Emulator"/>  
            <debugInterface adapter="SWD" connector="10-pin Cortex Debug Connector (0.05 inch connector)"/>
            <feature type="USB" n="1" name="USB Device,  Micro-B receptacle"/>
            <feature type="Button" n="3" name="reset and two user push-buttons"/>
            <feature type="LED" n="4" name="LEDs for user interaction, including 1 RGB LED"/> 
            <feature type="ConnOther" n="2" name="40 pin BoosterPack Connector and support for 20 pin BoosterPacks"/>
            <feature type="TempSens" n="1" name="Temperature sensor circuit"/>
            <feature type="LightSens" n="1" name="Light sensor circuit"/>
            <feature type="SensOther" n="1" name="External OPA2365 for 4MSPS ADC evaluation"/>
            <feature type="XTAL" n="48000000"/>
            <feature type="Other" name="EnergyTrace technology available for ultra-low-power debugging"/>
            <feature type="Other" name="32kHz crystal"/>
        </board>
    </boards>

它清楚地表明它有一个48MHz 晶体、这在开发板上是正确的、但该板的生产版本有一个40MHz 晶体。 这需要更新。

尊敬的 David：

很抱歉错过了这件事, 谢谢你再次对我拍了一下。 这似乎是我之前标记这个关闭 后,我们转移到私人消息,没有看到你以前的帖子,而我在外面。

关于涉及振荡器频率的第二个问题、我已经在内部提交了错误报告。 这应该 很容易校正。

您所发现的 pyocd 问题还不是我们最后遇到的问题、我相信此时我们只在 Keil 上使用了我们的 CMSIS-PACK。 我们还在研究支持 openOCD、尽管我的理解是、这还不是很远。  

但在 Keil 中、您必须手动添加非主闪存编程算法(请参见此处： https://software-dl.ti.com/msp430/esd/MSPM0-SDK/1_00_01_03/docs/english/tools/keil_ide_guide/doc_guide/doc_guide-srcs/keil_ide_guide.html#erasing-nonmain-for-mspm0)、这使得实现不 成问题。 没有使用 pyocd ,我不知道在那个界面中有什么等价的,但从你的描述来看,它似乎很清楚,它添加了这个算法本身。  

我心目中的潜在问题是、CMSIS-DAP 包未指定执行 NONMAIN 批量擦除 会使器件砖化、实际上、我不清楚您如何指定这一点。 也许 MSPM0G_NONMAIN.FLM 应该拒绝对 NONMAIN 执行批量擦除、因为在 MSPM0器件上、您永远不应该整体擦除存储器区域-这没有意义。 在最好的情况下,你可能*非常*只有写入几位。 [例如、MSPM0G_NONMAIN/FLM 中的算法 EraseSector 和可能的 EraseChip 拒绝擦除 NONMAIN 存储器错误、而是返回 STATUS=1、因此更改字节的唯一方法是 ProgramPage 命令、擦除则是将0xff 写入字节]。

[/报价]

MSPM0中的 NONMAIN 实际上只有512个字节、因此对 NONMAIN 的任何擦除操作都需要在任何编程之前完成、都会擦除整个 NONMAIN (MSPM0中的最小擦除分辨率为1个扇区)。非 MAIN 中的 BOOTCRC 值也必须有效、 因此我们的期望是、如果对任何非主控进行编程、程序员应该知道所有非主控值并 将它们全部重新编程、以避免 由于无效的 BOOTCRC 而锁定器件。

现在、使用将访问 BSL 和 CMSIS-DAP 端口的字作为0xFFFF、可以保障批量擦除安全。 然后任何位闪烁仍会锁定器件(这是 TI 的设计要求)、但批量擦除会使机器保持打开状态、似乎没有任何安全漏洞。 但 TI 选择了另一个字、意思是让 CMSIS_DAP 和 BSL 保持开路。

[/报价]

我不确定是否存在只能擦除非主器件的情况、在这种情况下、将较高的访问状态设置为擦除状态会产生问题。 无论从内部还是外部、您都不是第一个提供反馈的人。 最终决定、从安全角度来看、最好使用0xAABB 等值或其他并非全部为1或0的值、因为当  定义限制性较低的状态的值并非全部为高电平或低电平时、更难干扰或创建安全漏洞。  

理想情况下、我们应该只有当 工具链或其描述与使用出现问题时才会遇到这样的问题、遗憾的是、在将我们的 CMSIS-Pack 与 pyocd 配对时遇到了这种问题。  

此致、
布兰登·费舍尔

[/quote]

Keil 和 pyocd 都是从 mbed 演变而来的、mbed 是一种 ARM 开发技术、用于支持 ARM 器件以及支持任何制造商的器件。 我想 CMSIS Pack 也是从 ARM 演变而来、这可能就是 Keil 使用 CMSIS 包的原因、以及它为什么能很好地描述 ARM 硬件以及如何对其进行编程。

Pyocd 当被移动,成为独立的手臂,但我认为,主要参与其中的人都是基于手臂。 Pyocd 是一个基于芯片调试器的 python、并由 ARM ITS 专门针对 ARM 器件开发；与 openocd 不同、后者则广泛得多。 Pyocd 有一个比 openocd 更友好的界面- openocd 是非常普遍的,和可怕的隐秘,它早于 CMSIS 包可能15年! 但现在支持他们我贝雷埃夫,我不知道有多好。 开发出的 pyocd 基于 CMSIS 软件包-调试器工作时需要使用这些软件包-它知道与什么通信。

我想我要强调的主要问题是、TI 是否同意很难描述 CMSIS Pack 中的 MSPM0硬件、特别是不应该擦除 NONMAIN。 这是如何在 Pack 中这样说的、没有真正的方法。

是的、您可能是对的、仅512个字节的 NONMAIN 需要完全擦除才能重写一个字节、但我想 MSPM0G_NONMAIN_FLM 中的算法应该知道这一点、因此当您使用 ProgramPage 命令时、它知道如何执行该操作。 pyocd、我预计也知道闪存存在于扇区中、需要了解这一点才能知道如何向扇区写入字节-我预计 pyocd 已经正确了、因为现在这些闪存器件都可以正常工作。

因此、pyocd 的问题是、当你尝试执行芯片擦除时、它使用一个明确的命令来执行此操作、但是当一个像这样的命令运行时、pyocd 的功能就是-擦除芯片、正如 CMSIS 软件包中描述的那样。 关键是 pyocd 不读文件,只读 CMSIS 包,应该怎么做.

是的、TI 文档、可能在您可以执行芯片擦除的任何地方(并且在很多地方可以执行擦除)文档中确实会给出警告、即在复位之前需要重写 NONMAIN。

那么、认为问题是、TI 有什么话要说吗？ @我要做的可能是把一个错误报告放到 CMSIS people 的 ARM 中、可能需要有一种方法来指定一个存储器区域、虽然它是可写的、但这应该非常小心。 例如、芯片擦除不是安全的操作。 CMSIS 软件包当前不了解这一点、但了解其 MSPM0的运行情况。

尊敬的 David：

我想我要强调的主要问题是、TI 是否同意很难描述 CMSIS Pack 中的 MSPM0硬件、特别是不应该擦除 NONMAIN。 这是如何在 Pack 中这样说的、没有真正的方法。

[/报价]

根据我的观察结果、在 CMSIS-PACK 中无法在编程算法中描述这一点。 对于 Keil、默认定义就足够了。 基于该线程、我们的软件团队正在将 pyocd 兼容性添加到我们的列表中、因此在某个时候、他们无论如何都得尝试一下。 目前、我认为最简单的权变措施是删除 NONMAIN 算法引用以防止这种情况发生。 它不理想、但应该能正常工作。  

所以问题是、TI 有什么话可以说吗？ @我要做的可能是把一个错误报告放到 CMSIS people 的 ARM 中、可能需要有一种方法来指定一个存储器区域、虽然它是可写的、但这应该非常小心。 例如、芯片擦除不是安全的操作。 CMSIS 软件包当前不理解这一点，但它的 MSPM0操作。

同时、如果您收到有关这方面的任何反馈、可以随时更新此主题。 目前,我唯一能看到这一功能的方法是,解决它的某种笨拙。

此致、
布兰登·费舍尔

[/quote]