完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
在处理嵌入 STM32G0B0CE (v13.0) 和 STM32G0B1RE (v9.2) MCU 系统内存中的 I2C 引导加载程序时,我们注意到一个奇怪的行为。
引导加载程序的 Write Memory (0x31) 和 No-Stretch Write Memory (0x32) 命令似乎不适用于至少 8 字节对齐的地址。在 4 字节对齐地址上发出的命令由引导加载程序确认(在最后一次 I2C 读取命令时收到 ACK 字节 (0x79)),但数据永远不会写入 记忆。操作的大小似乎并没有改变这种行为。例如,引导加载程序在 0x08000004 上确认写入内存命令,但从未真正将其写入闪存,即使它之前已被擦除。该地址上的读取内存命令 (0x11) 返回 0xFF 字节,这表明闪存尚未被编程。 另一方面,如果我们尝试使用 16 字节的有效负载对 0x08000000 执行写操作,则一切正常(因此,地址 0x08000004 也被写入)。 在非 4 字节或 8 字节对齐的地址(例如 0x08000002)上写入内存命令不起作用:命令的最后一次 I2C 读取失败,因为引导加载程序 NAK I2C 读取。我们无法获得此类命令的 ACK (0x79)、NAK (0x1F) 或 Busy (0x76) 字节。 在 Linux 上,stm32flash 可以使用以下命令行重现此问题:
传递给写入内存命令的地址是否有任何限制,或者这是引导加载程序中的错误? |
|
相关推荐
1个回答
|
|
根据结构,G0 Flash 只能用双字编程,如 RM 中所述:
“闪存一次编程 72 位(64 位数据加上 8 位 ECC)。” 更准确地说,它指的是 64 位对齐确实 <= 8 字节对齐。 I2C 引导加载程序协议不会为较小的缓冲区支持或最有可能未对齐的 _ 字节数据实现仿真。实际上,您无论如何都必须在地址 xxxxx0 到 xxxxxx4 处写一些东西,以便也将 xxxxx4 写到 xxxxxx8。编程 0xFFFF 也不会再被擦除状态,由于 ECC 代码,擦除数据和编程“..FFF..”不同 我将与 BL 开发团队合并,但我想这可能会解释您的问题。 内存线大小与产品无关,可能因系列而异,而 I2C BL 协议则不同。 |
|
|
|
只有小组成员才能发言,加入小组>>
请教:在使用UDE STK时,单片机使用SPC560D30L1,在配置文件怎么设置或选择?里面只有SPC560D40的选项
2738 浏览 1 评论
3241 浏览 1 评论
请问是否有通过UART连接的两个微处理器之间实现双向值交换的方法?
1810 浏览 1 评论
3650 浏览 6 评论
6039 浏览 21 评论
1339浏览 4评论
202浏览 3评论
对H747I-DISCO写程序时将CN2的st-link复用为usart1,再次烧录时无法检测到stlink怎么解决?
353浏览 2评论
STM32G474RE芯片只是串口发个数据就发烫严重是怎么回事?
444浏览 2评论
STM32处理增量式编码器Z信号如何判断中断是正转的还是反向转的?
275浏览 2评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-25 20:51 , Processed in 1.166516 second(s), Total 77, Slave 61 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号