YunTu Forum

如下调试打印的函数：

1 int board_uart_putc(uint8_t c) 2 { 3 REG32(LINFLEXD3_UART_DATA0_8) = c; 4 5 while ((REG32(LINFLEXD3_UARTSR) & 0X02) == 0X0); 6 7 REG32(LINFLEXD3_UARTSR) |= 0X02; 8 return 0; 9 }

会不会存在一种情况，数据发送出去了，但是一直卡在循环 while ((REG32(LINFLEXD3_UARTSR) & 0X02) == 0X0);
我调试的时候发现的：
2026-06-02_22-04.png

可以看到 2 实际已经发送出来了，但是还是卡在 while 循环这里。

void lin_frame_rx_handler(uint32_t hwInst, void param)
{
else if(state->activeFrame->frameType == LIN_FRAME_TYPE_DIAG)
{
/ diag frame need copy to rx queue */
if((linState->rxSize) != state->activeFrame->bufLen)
{
state->frameStatus.errorInResp = l_true;
lin_tp_handle(inst, LIN_TP_RX_ERROR);
}
else
{
state->frameStatus.succTransfer = l_true;
#ifdef LIN_USE_UART
state->frameStatus.frameId=lin_id_to_pid(state->id);
#else
state->frameStatus.frameId=lin_id_to_pid(state->frameBuf.id);
#endif
}
}

函数里的上面代码段，似乎有bug。rxSize是准备接收的长度，是通过 LIN_UART_DRV_RecvFrmData()函数调用传入设置的。 而传入的参数是获取自 activeFrame->bufLen。 把这两个参数进行比较永远相等，无意义。

1fa9d0e41859e840b8d93b7f9242bab9.png ef1dbf4c5febed334aae1bfeed7fcd44.jpg

如上是程序提示图片，帮忙看看是啥问题

用Ozone打开存在FreeRTOS的工程时候，会提示如下窗口，选择Apply ：
280e5731-5d4c-4334-9c55-0b1935c848b1-image.png

然后就可以看到这个窗口：
41f6a0a1-1afe-4256-ab81-dfa027abc90c-image.png

可以双击各个task，查看每个任务的的 call stack：
d998c7a7-0157-4859-9779-a82bbfaa0cff-image.png

在YTM32Bx系列MCU中，可通过EFM模块ADDR_PROT寄存器对内部Flash进行写保护，ADDR_PROT寄存器中的每个bit被设置为0时，其对应的Flash区域即被写保护。MCU上电后ADDR_PROT寄存器值仅允许从1变为0，而不允许从0变为1，即MCU允许过程中Flash一旦被写保护，则本次运行期间不能被取消写保护。

EFM模块中ADDR_PROT寄存器的初始值来自于MCU内部CUS_NVR Flash中指定位置（详见MCU参考手册），用户可根据自身需求通过写CUS_NVR Flash设置该寄存器的默认值，需注意，若该寄存器默认值被设置为0，则MCU上电后对齐的Flash即被写保护，后续将无法通过JTAG或软件内部的Flash driver对被写保护的Flash进行擦除或编程操作。

此时如果需要解锁被写保护的Flash，则只能通过重置ADDR_PROT寄存器初始值，即擦除重写CUS_NVR Flash中对应位置的值。若MCU内部所有Flash均被写保护，则该MCU无法在向Flash中下载任何程序，此时若需修改ADDR_PROT寄存器初始值，则需新建一个工程用于擦除CUS_NVR Flash，并将该工程所有代码放在RAM中运行.

下面以YTM32B1MD14为例介绍实现过程：

1.在YCT工具中新建工程，并配置YT-LINK模块，删除该模块中Flash中配置的所有sector信息，并在RAM中创建.text段以及.rodata段，用于存储代码及const类型数据。
85fb3330-3100-4864-9c0c-4c98873fe6bc-image.png

2.在main.c中通过如下代码实现CUS_NVR擦除。

uint32_t TestCnt=5; void Test_CusterNvrErase(void) { EFM->CUS_KEY = 0x4dff32; EFM->CMD = 0U; EFM->STS = EFM_STS_FAIL_MASK | EFM_STS_ACCERR_MASK | EFM_STS_UNRECOVERR_MASK | EFM_STS_RECOVERR_MASK | EFM_STS_DONE_MASK; EFM->NVR_ADDR = 0x10000400U; EFM->CMD_UNLOCK = 0xfd9573f5; EFM->CMD = 0x41U; while ((EFM->STS & EFM_STS_DONE_MASK) == 0U) { } if(((EFM->STS&EFM_STS_ACCERR_MASK) != 0)||((EFM->STS&EFM_STS_FAIL_MASK) != 0)) { while(1) {} } } /* USER CODE END 0 */ /** * @brief The application entry point. * @retval int */ int main(void) { /* USER CODE BEGIN 1 */ /* USER CODE END 1 */ Board_Init(); /* USER CODE BEGIN 2 */ Test_CusterNvrErase(); /* USER CODE END 2 */ /* Infinite loop */ /* USER CODE BEGIN WHILE */ while (1) { TestCnt++; if(TestCnt>1000) { TestCnt = 0; } /* USER CODE END WHILE */ /* USER CODE BEGIN 3 */ } /* USER CODE END 3 */ } static void Board_Init(void) { } 通过调试工具将代码下载至MCU运行，然后reset MCU即可完成Flash写保护解锁。

4.注意示例代码中写入的CUS_KEY为MCU默认值，若MCU CUS_KEY被修改，则需根据实际情况写入KEY值。
Erase_CUSNVR.zip

我现在的问题是DMA已经生效了，我给了一个6000的buffer让DMA去搬到GPIOC->PDOR。实际测到的频率只有8MHz，我需要升到32MHz，应该怎么配置呢？

云途 FAE 文档 MCP 已开放，可在 ClaudeCode/CodeX/Cursor 等 AI 助手中连接使用。连接地址与配置说明见：https://account.ytmicro.com/mcp
MCP 地址：https://account.ytmicro.com/auth/mcp（连接后需 Casdoor OAuth 验证）

IDE 里已有 SDK/MCAL 源码，适合查 API 和例程；AI-FAE 则检索 RM、DS、论坛，更适合解决源码里不容易一次找全的复杂问题：

系统级联调 — 时钟树、低功耗、DMA+中断+多外设协同，配置顺序与依赖 能力边界 — 区分「芯片硬件不支持」还是「SDK 尚未封装」 复杂外设深配 — CAN/LIN 等过滤器、时序、状态机与寄存器约束（不止默认 MCAL 路径） 封装与 Pinmux — 同封装多外设同时启用时的引脚复用与冲突 跨型号迁移 — Flash/RAM/外设差异、boot 与 option 变更点 疑难排查 — 对照 RM errata 与论坛已知案例，定位「例程看起来对但仍异常」的问题

使用建议：问题中写清芯片型号（如 YTM32B1ME0x）；适合日常开发中交互查文档，不适合大批量自动化检索。

你好，客户想将 Secure Boot 固件验签流程移植到升级验签环节，请问有 Secure Boot 固件验签流程实现的代码参考

把调试引脚定义为了gpio导致调试器连接不上怎么解决

7c431718-88f5-415c-bce4-a60f76a7439d-image.png
开启了SSP使用带BRS的CANFD还是会有位错误
6aafc972-4faa-4ec9-891c-6e1225f9f62a-image.png

737de6f5-5f89-4a93-8d40-cc3a0bda7200-image.png
8885c18d-af34-40fc-b723-33306e96ec72-image.png
点击此文件下载报错其他文件都没有问题

e06edfc6-9ad5-4ec1-8f16-5a72648acae7-c7fffae406bf7800093ef1aaca75218.png 180787ac-3c62-4eae-83ab-bd1b1079943b-492edde4902f31635542be03c8131c6.png
如图，为什么keil中Dflash地址从0x2001000开始

15618afa-9768-42c8-8dd5-3755f0960fcd-image.png
有大佬能讲解一下为什么第二种写法为什么不行吗

063cc0a0-2ab5-42ff-bbde-dfdf25dcd654-image.png
UartBuffCheck函数现在调整为10ms调用一次，测试接收6字节数据正常，可以进入(event == UART_EVENT_TIMEOUT)，测试主机发送144字节，FEIE和BOIE置位，但不进串口接收中断回调函数
239bf9b4-1686-4b85-8566-da2c71835898-image.png
84c083c4-8ab7-415d-8432-bccb55a2e6b0-image.png
UART_RX_SIZE定义为450，最大需接收的字节
900f6370-55c7-4910-acf9-307066dc2569-image.png
de9486a5-ac6d-4302-88e2-94bcfa1feeb6-image.png

如题：请问SDK1.4.1版本的中间件有计划什么时候更新发布吗？如MD14（1.4.1版本）的UDS相关中间件。
目前客户还是使用的uds_can_fbl_md14_release_20250530 demo(SDK1.3.1)版本的先做开发。

谢谢答疑

c969802e-7612-43ba-811c-9fe54492f63f-50f3e61a6e9f6f8c18ffb0074d4479d4.png

e6b61582-1b72-49dc-8d0a-85d4de5b92b2-d64c193f94c6ac5182bbe594126e18de.png

和给的spi 从机demo对比过了，没感觉哪有不一样的
965badca-f1a3-431f-826e-25aa1ca83976-image.png
程序一直卡在从机等待返回中，主机的可以正常返回，可以麻烦帮我看一下哪里配置的不对吗
程序上初始化了2f275046-921f-4ea3-bf6e-a685bed28a8a-image.png
代码
port_control.zip

7f715f77-0f94-4579-a357-ebbffac68ddd-image.png b8de2902-2e44-49c3-b28d-1c60e3085623-image.png d047102f-c338-4ffe-a10e-0658624f3cbd-image.png
SPI2和SPI0中断也配置了b63b8377-eb05-4c09-928f-0c347a7d2b60-image.png
port也对应配置了
主机SPI2除了miso都配置的输出
从机SPI0处了mosi都配置的输入

YTM32B1MC03的RAM故障和EEPROM故障，分别读取哪个寄存器可以获取故障标志？

介绍

YTM32B1HA01 是云途第一款搭载 Cortex-M7 的芯片，开始引入 Cache。本文旨在简单介绍 Cache，以及 MPU。

Cache

随着工艺和设计的演进，CPU 计算性能其实发生了翻天覆地的变化，但是DRAM存储性能的发展没有那么快。

所以造成了一个问题，存储限制了计算的发展。

容量与速度不可兼得。

如何解决这个问题呢？可以从计算访问数据的规律入手。

我们随便贴段代码:

for (j = 0; j < 100; j = j + 1) for( i = 0; i < 5000; i = i + 1) x[i][j] = 2 * x[i][j];

可以看到，由于大量循环的存在，我们访问的数据其实在内存中的位置是相近的。

换句专业点的话说，我们访问的数据有局部性。

我们只需要将这些数据放入一个小而快的存储中，这样就可以快速访问相关数据了。

总结起来，Cache是为了给CPU提供高速存储访问，利用数据局部性而设计的小存储单元。

Cache 按照数据类型可划分为 I-Cache 与 D-Cache。其中I-Cache负责放置指令，D-Cache负责放置数据。两者最大的不同是D-Cache里的数据可以写回，I-Cache是只读的。

Cache 工作原理

873854f5-4f0d-45c4-b52a-42b90dfc5bfa-image.png
CPU 和 Cache 是 word 传输的，而 Cache 到主存是以块传输的，一块大约 64Byte 。

其中 I-Cache 缓存指令，D-Cache 缓存数据。

当 CPU 访问Cache过的 Memory 时，由于 Cache 可以缓存 Memory 的内容，这样 CPU 访问 Memory 就会变成访问 Cache，CPU 访问 Cache 的速度远大于访问 Memory 的速度，以此提成 CPU 的性能。

Cache 找数据

在讲 Cache 的读取或写入之前，先谈一下 Cache 的数据。

Cache 的数据由 Tag 与 Memory 内的数据组成，当 CPU 希望通过 Cache 访问 Memory 时，会先比对 Cache 中的 Tag。

若成功，又称命中 (hit)，CPU 会直接操作 Cache 中的数据；

若失败，又称缺失 (miss)，则 Cache 会缓存这块 Memory。

例如，当 CPU 第一次访问 Memory 时，Cache 内未缓存该 Memory，则 CPU miss，此时 Cache 会缓存 Memory；当 CPU 紧接着又访问该 Memory 时，Cache 内正好缓存着 Memory，则 CPU hit。

Cache 写数据

Cache 毕竟是个临时缓存，如果 CPU 往 Cache 中写数据，则会造成 Cache 中数据与 Memory 数据不匹配，为保证写数据的统一，通常会设置 Memory 的 Cache Write 属性。

若 CPU hit: Write through: CPU 向 Cache 中写入数据时，同时向 Memory 也写一份，使 Cache 和 Memory 的数据保持一致。优点是简单，缺点是每次都要访问 Memory，速度比较慢。 Write back: CPU 更新 Cache 时，只是把更新的 Cache 区标记一下，并不同步更新 Memory 。只是在 Cache 区要被新进入的数据取代时，才更新 Memory。这样做的原因是考虑到很多时候 Cache 存入的是中间结果，没有必要同步更新 Memory。优点是CPU执行的效率提高，缺点是实现起来技术比较复杂。 若 CPU miss: Write allocate: 先把要写的数据载入到 Cache 中，写 Cache，然后再通过flush方式写入到 Memory 中。 No write allocate：直接把要写的数据写入到 Memory 中。 Cache 读数据

CPU 读取 Cache 中数据时，也分 hit 与 miss 的情况。

若 CPU hit: CPU 直接从 Cache 中读取数据。 若 CPU miss: Read through: CPU 直接从 Memory 中读取数据。 Read allocate: Cache 先缓存当前 Memory，CPU 再从 Cache 中读取数据。 Cache 示例

下面以一个简单的例子来展示 Cache 的工作原理。

uint16_t x[8] = {0}; uint8_t i = 0; uint8_t j = 0; for (j = 0; j < 50; j = j + 1) for( i = 0; i < 8; i = i + 1) x[i] = x[i] + j; 当没有 Cache 时，x 数组置于 SRAM 上，每次修改 x[i] 时，CPU 会先访问 x[i] 所在的地址，并读取该值，做完加法运算后，把运算结果回写至 x[i] 所在的地址，至此完成一次 x[i] 的赋值，共需执行400次这样的操作。 当有 Cache 时，x 数组置于 SRAM 上。 CPU 第一次去访问 x[i] 时，Cache 内没有 x 数组的内容，此时会缓存 x 数组所在的 SRAM，当前 Cache 内 x 数组值为全零。 每次修改 x[i] 时，会读取 Cache 中 x[i] 的值，做完加法后，若此时为 Write-Back 策略，则CPU将结果再写回 Cache 中，不会同步更新到 x[i] 所在的真实 SRAM 地址的值。 中间的运算以及访问都会在 Cache 中，当 Cache 中内容要被新数据取代时，Cache 会将计算结果回写至 x[i] 所在的真实 SRAM 地址。 Cache 操作 Invalidate

Invalidate 操作主要是针对 cache line中的 valid bit（有效位）进行操作。通过对有效位进行清零，从而使cache line中的数据失效，达到清除数据的目的。比如在上电或者重置操作后，cache 中的内容是未定义的，此时它的valid bit为0。

Clean

Clean 操作主要针对cache line 中的 dirty bit（脏位）

某个cache line中的dirty bit为1，说明该line中的数据与内存中的数据不一致，我们就可以对该cache line描述为变“脏”了。

清除cache或cache line意味着将标记为“脏”的cache line内容写入下一级缓存或主内存，并清除cache line中的脏位。这使得当前的cache line中的数据与下一级缓存，或主存中的的内容相同。此操作仅适用于写回策略 (WB)的数据缓存 (data-cache)。

Flush

每条cache line 先clean，再invalidate.

Cache APIs Enable Cache void SCB_EnableICache (void); void SCB_EnableDCache (void); Disable Cache void SCB_DisableICache (void); void SCB_DisableDCache (void); Invalidate Cache void SCB_InvalidateICache (void); void SCB_InvalidateICache_by_Addr (volatile void *addr, int32_t isize); void SCB_InvalidateDCache (void); void SCB_InvalidateDCache_by_Addr (volatile void *addr, int32_t dsize); Clean Cache void SCB_CleanDCache (void); void SCB_CleanInvalidateDCache (void); void SCB_CleanDCache_by_Addr (volatile void *addr, int32_t dsize); void SCB_CleanInvalidateDCache_by_Addr (volatile void *addr, int32_t dsize); Cache Tips

Cache 一致性是 Cache 中遇到的比较麻烦的一个问题。

实际使用过程中，Memory 不仅仅只有 CPU 或 Cache 访问，一些外设也可以去读写 Memory，例如 DMA，下面列举了常见的 Cache 使用场景。

CPU访问，外设改写

如果CPU先读了一块内存，接下来要DMA/其他硬件要访问这块内存，无需clean. DMA/其他硬件改写了这段DDR后，要将这段cache置为invalid,这样后续如果CPU访问这段内存，就不会使用cache中的数据。

外设访问，CPU改写

如果CPU先写了一块内存，接下来要DMA/其他硬件要访问这块内存，要先clean，确保DMA/其他硬件访问到的DDR数据是准确的。DMA/其他硬件改写了这段DDR后，要将这段cache置为invalid,这样后续如果CPU访问这段内存，就不会使用cache中的数据。

MPU

YTM32B1HA01 使用的是 ARM-v7 架构，MPU 版本也是 ARM-v7 的 MPU。

ARM-v7 的 MPU 与 ARM-v8 的 MPU 实现的功能基本类似，本篇主要介绍 MPU 的属性配置。

Region 地址与大小

MPU 设置的每个 Region 为基地址与 region size。其中基地址要求 region size 对齐，即要求 Base_address % Region_size == 0。Region size 要求为 2 的幂次，最小为 32 Bytes，最大为 4GB。

MPU 属性 XN

XN 为 Execute Never encoding 的缩写，表示当前 Region 能否执行指令。

XN Description 0 Execution of an instruction fetched from this region permitted 1 Execution of an instruction fetched from this region not permitted AP

AP 为 Access permissions field encoding 的缩写，表示当前 Region 的访问权限。

AP[2:0] Privileged access Unprivileged access Notes 000 No access No access Any access generates a permission fault 001 Read/write No access Privileged access only 010 Read/write Read-only Any unprivileged write generates a permission fault 011 Read/write Read/write Full access 100 UNPREDICTABLE UNPREDICTABLE Reserved 101 Read-only No access Privileged read-only 110 Read-only Read-only Privileged and unprivileged read-only 111 Read-only Read-only Privileged and unprivileged read-only

其中 UNPREDICTABLE 为不可预知的，不能设置成该属性。

TEX，S，C，B

TEX 与 C，B 共同控制 Memory 属性，S 表示 Shareable，根据不同的内存属性有着不同的作用域。

设置shareable表示该存储块可以被多个主设备访问，当配置 Shareable 时，
该区域的数据是不会使用cache的，效果跟write through一样。

如果 Non-shareable,一般指被本地CPU访问。

TEX C B Memory type Description, or Normal region Cacheability Shareable? 000 0 0 Strongly-ordered Strongly ordered Shareable 000 0 1 Device Shared device Shareable 000 1 0 Normal Outer and inner Write-Through, no write allocate S bit 000 1 1 Normal Outer and inner write-back, no write allocate S bit 001 0 0 Normal Outer and inner Non-cacheable S bit 001 0 1 Reserved Reserved Reserved 001 1 0 IMPLEMENTATION DEFINED IMPLEMENTATION DEFINED IMPLEMENTATION DEFINED 001 1 1 Normal Outer and inner write-back; write and read allocate S bit 010 0 0 Device Non-shared device Non-shareable 010 0 1 Reserved Reserved Reserved 010 1 X Reserved Reserved Reserved 011 X X Reserved Reserved Reserved 100 0 0 Normal Non-cacheable S bit 101 0 1 Normal Write-Back, write and read allocate S bit 110 1 0 Normal Write-Through, no write allocate S bit 111 1 1 Normal Write-Back, no write allocate S bit

S bit 表示当前配置下，S=0 为 Non-Shareable，S=1 为 Shareable

SRD

SRD 为 Subregion Disable 的缩写。

一个 Region 可以分成8个 sub region，每个 sub region 大小为母 region 的 1/8。

8块 Sub region 由8个比特单独控制，设 0 表示使能 sub region，设 1 表示禁止 sub region。例如，若设置 MPU->RASR.SRD = 0b10101010，表示当前 Region 的第 0 块 Sub region 使能，第 1 块 Sub region 禁止......第 6 块 Sub region 使能，第 7 块 Sub region 禁止。

若禁止某块 Sub region，则该块 Sub region 与母 Region 属性不一致，其为默认属性。

优先级

当两个 Region 的区域重叠时，这块儿重叠区域的属性是后面的 Region，例如某一块 Memory 既在 Region 10 内，又在 Region 8 内，此时这块 Memory 属性为 Region 10 中所设置的属性。（注：ARM-V8 不支持 Region 区域重叠）

MPU 控制 PRIVDEFENA

MPU->CTRL 里有 PRIVDEFENA 比特位：

当设置成 0 时，禁止默认的 Memory Map，访问未被 MPU 定义的区域会产生错误 当设置成 1 时，使能默认的 Memory Map，但仅特权模式 (privileged) 能访问未被 MPU 定义的区域。且默认的 Memory Map 可当作 Region 为 -1，即优先级为最低。

ARMv7 默认的 Memory Map 属性如下

Address Name Device type XN? Cache Description 0x00000000-0x1FFFFFFF Code Normal - WT Typically ROM or flash memory. 0x20000000-0x3FFFFFFF SRAM Normal - WBWA SRAM region typically used for on-chip RAM. 0x40000000-0x5FFFFFFF Peripheral Device XN - On-chip peripheral address space. 0x60000000-0x7FFFFFFF RAM Normal - WBWA Memory with write-back, write allocate cache attribute for L2/L3 cache support. 0x80000000-0x9FFFFFFF RAM Normal - WT Memory with Write-Through cache attribute. 0xA0000000-0xBFFFFFFF Device Device, shareable XN - Shared device space. 0xC0000000-0xDFFFFFFF Device Device, Non-shareable XN - Non-shared device space. 0xE0000000-0xFFFFFFFF System - XN - System segment for the PPB and vendor system peripherals

注：

WB：Write back WT：Write through WA：Write allocate 该 Memory Map 为 ARM 定义的 Memory Map，芯片实际的 Memory Map 会不太一样，但默认属性是一致的。 HFNMIENA

Core 内部有一些异常中断，例如 Hard Fault，Bus Fault，Usage Fault，NMI...这些均为不可屏蔽的中断。

MPU->CTRL 里有 HFNMIENA 比特位：

当设置成 0 时，产生类似 Hard Fault，NMI 错误，或开启 FAULTMASK 后，MPU 设置的属性会失效 当设置成 1 时，Memory 在上述情况下仍使用 MPU 配置的属性

注：当未使能这个比特时，产生 HardFault 后，MPU 对 Memory 配置的属性会失效，例如对 RAM 配置的 non-cacheable 属性，会恢复为默认 cacheable，此时需要注意 Cache 的同步问题；或者使用 “cpsid if” 来关闭全局中断后，MPU 的属性也会失效。("cpsid i" 不影响 MPU）

FAQ

下面会介绍，在 YTM32B1HA0 上可能遇到的与 Cache 一致性有关的应用场景。

Cache 与 Flash 的读写擦

Flash 无法被 Cache 擦写，主要是 Flash 的读操作。

若 Flash 被 Cache 缓存了，当用户操作 EFM 模块修改 Flash 内容后，例如擦除某个扇区，或某块空 Memory 进行编程，并不会修改 Cache 中的内容，若此时 CPU 去读取这段被修改的 Memory，则会读取 Cache 中的结果，即被修改前的 Memory 的值。

所以需要在用户修改完 Flash 中的内容后，对 Cache 进行 Invalidate 操作，让 Cache 重新读取同步 Flash。

当前 SDK 有对该场景进行配置，用户调用 SDK 操作 Flash 是正常的。

同样的，Fee(EEPROM) 也需要类似的操作。

Cache 与 DMA

Cache 与 DMA 均无法修改 Flash 的值，但均可以修改 SRAM 里的值。

当 SRAM 被 Cache 缓存后，

若 DMA 去修改 SRAM 里的值，则需要对 Cache 进行 Invalidate 操作，让 Cache 重新读取同步 SRAM； 若 CPU 通过 Cache 去修改 SRAM，而 DMA 需要搬运这块 SRAM，那么在 DMA 搬运之前，需要对 Cache 进行 Clean 操作，把 Cache 中的数据回写到 SRAM 中。

其余能操作 SRAM 的外设均类似。

Cache 与调试 Debug

YTM32B1HA0 调试总线是经过 Cache，所以在调试时，用户添加在 Watch 窗口的值大多为 Cache 中的值，当 DMA 修改完这个值后，调试窗口里的值不一定会改变。

在调试过程中，当出现调试窗口里的值不是预期的结果，有可能会是这个问题。

当然，同样的，如果在调试过程中，用户通过 Memory 窗口，修改 SRAM 值，DMA 再去搬运，有可能搬运的是修改前的值。

调试时，用户对 SRAM 进行的读写操作与 CPU 类似，可参考上一条。

HardFault or FAULTMASK

MPU->CTRL 的 HFNMIENA 未使能时，开启 FAULTMASK 或 HardFault 等异常置起时，需要注意数据同步。

while(1) { A++; __asm volatile ("cpsid if"); B = A; __asm volatile ("cpsie if"); }

例如上述代码，A，B 变量均在 MPU 配置的 non-cache 的 RAM 上，A++ 对A变量的读取以及回写不会经过D-Cache，开启 FAULTMASK 后，MPU配置属性失效，A与B变量所在的 RAM 恢复为 cacheable，第一次 B 读取 A 变量会先过 D-Cache，由于 D-Cache 未 hit 过 A，所以会从 RAM 中加载真实的值。关闭 FAULTMASK 后，MPU 配置会重新生效，A，B 恢复为 non-cache 。A++ 对A变量的读取以及回写依旧不会经过D-Cache；第二次 B 读取 A 变量，由于 A 变量已经被 D-Cache hit 过，所以会直接从 Cache 中读取 A 变量。但 A 变量的变化不经过 Cache，直接刷写 RAM，会导致 Cache 与 RAM 数据不同步，显示 B 的值始终保持不变。

解决方法可以使用 "cpsid i" and "cpsie i" 来关闭全局中断，与恢复全局中断，这个不会影响 MPU 。

发现如果不SuspendAllInterrupts ，调用FLASH_DRV_EraseSector会进入hardfault.
SCB信息如下：
Expression Value Location Type
mySCB 0xE000'ED00 0x1fff'2278 SCB_Type *
CPUID 1'091'555'860 0xe000'ed00 uint32 volatile const
ICSR 3 0xe000'ed04 uint32 volatile
VTOR 536'805'376 0xe000'ed08 uint32 volatile
AIRCR 4'194'639'872 0xe000'ed0c uint32 volatile
SCR 0 0xe000'ed10 uint32 volatile
CCR 513 0xe000'ed14 uint32 volatile
SHPR <array>"" 0xe000'ed18 uint8 (volatile)[12]
SHCSR 65'540 0xe000'ed24 uint32 volatile
CFSR 65'536 0xe000'ed28 uint32 volatile
HFSR 0x4000'0000 0xe000'ed2c uint32 volatile
DFSR 2 0xe000'ed30 uint32 volatile
MMFAR 0x2000'ff1c 0xe000'ed34 uint32 volatile
BFAR 536'936'220 0xe000'ed38 uint32 volatile
AFSR 0 0xe000'ed3c uint32 volatile
ID_PFR <array> 0xe000'ed40 uint32 (volatile const)[2]
ID_DFR 2'097'152 0xe000'ed48 uint32 volatile const
ID_AFR 0 0xe000'ed4c uint32 volatile const
ID_MMFR <array> 0xe000'ed50 uint32 (volatile const)[4]
ID_ISAR <array> 0xe000'ed60 uint32 (volatile const)[6]
CLIDR 0 0xe000'ed78 uint32 volatile const
CTR 2'147'532'800 0xe000'ed7c uint32 volatile const
CCSIDR 0 0xe000'ed80 uint32 volatile const
CSSELR 0 0xe000'ed84 uint32 volatile
CPACR 15'728'640 0xe000'ed88 uint32 volatile
NSACR 0 0xe000'ed8c uint32 volatile
RESERVED7 <array> 0xe000'ed90 uint32[21]
SFSR 0 0xe000'ede4 uint32 volatile
SFAR 0 0xe000'ede8 uint32 volatile
RESERVED3 <array> 0xe000'edec uint32[69]
STIR 0 0xe000'ef00 uint32 volatile
RESERVED4 <array> 0xe000'ef04 uint32[15]
MVFR0 269'549'601 0xe000'ef40 uint32 volatile const
MVFR1 285'212'689 0xe000'ef44 uint32 volatile const
MVFR2 64 0xe000'ef48 uint32 volatile const
RESERVED5 <array> 0xe000'ef4c uint32[1]
ICIALLU 0 0xe000'ef50 uint32 volatile
RESERVED6 <array> 0xe000'ef54 uint32[1]
ICIMVAU 0 0xe000'ef58 uint32 volatile
DCIMVAC 0 0xe000'ef5c uint32 volatile
DCISW 0 0xe000'ef60 uint32 volatile
DCCMVAU 0 0xe000'ef64 uint32 volatile
DCCMVAC 0 0xe000'ef68 uint32 volatile
DCCSW 0 0xe000'ef6c uint32 volatile
DCCIMVAC 0 0xe000'ef70 uint32 volatile
DCCISW 0 0xe000'ef74 uint32 volatile
BPIALL 0 0xe000'ef78 uint32 volatile