工具/软件:
您好:
只需确认执行编程/擦除操作时闪存模块的行为。 在 TRM 的第 7.2.1 节中、它指出同一存储体上的所有读取请求都会停止、直到操作完成:

但在第 7.3.1 节中、它指出对正在编程/擦除的同一闪存存储体的读取访问可能是不可预测的:

器件上实际发生的情况似乎是读取访问会暂停、直到命令完成。 我们能否证实这是预期的结果? 如果是、我们能否澄清 TRM 中的第二项陈述?
Munan
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:
您好:
只需确认执行编程/擦除操作时闪存模块的行为。 在 TRM 的第 7.2.1 节中、它指出同一存储体上的所有读取请求都会停止、直到操作完成:

但在第 7.3.1 节中、它指出对正在编程/擦除的同一闪存存储体的读取访问可能是不可预测的:

器件上实际发生的情况似乎是读取访问会暂停、直到命令完成。 我们能否证实这是预期的结果? 如果是、我们能否澄清 TRM 中的第二项陈述?
Munan
尊敬的 Munan:
我也认为 TRM 描述 有点混乱。
我更喜欢第二种语句、因为读取行为不是由闪存控制器控制的、闪存控制器主要控制写入/擦除/验证行为。 我想它没有阻止 CPU 访问的机制。
我们始终建议在使用闪存控制器操作单组器件时、确保操作在 SRAM 中完成(将部分代码加载到 SRAM 中)。 运行双存储体器件时、可以在处理另一个闪存存储体时将所有闪存控制器操作置于闪存存储体中。
B.R.
Sal
尊敬的 Munan:
对于在闪存中实现此闪存写入命令的客户、导致代码看起来正常工作的机制是什么?
现在、我们已经将这种闪存操作移动到 RAM(带有一个 while 循环以检查其状态)、因此它与闪存操作是独立的。
此外、最好在闪存操作期间禁用中断、因为中断例程是在闪存中执行的、如果没有将其特殊放入 RAM 中。 -这不是 SDK 解决方案的一部分,但我认为它会更安全。
B.R.
Sal