J-Flash ARM烧写Nor Flash时出错:PC of target system has unexpected value after programming

本文介绍了一种使用J-FlashARM工具烧写NorFlash时遇到的常见错误“PCoftargetsystemhasunexpectedvalueafterprogramming”的解决方法。通过对J-FlashARM的初始化序列进行调整,在复位后增加2毫秒的延迟,解决了烧写过程中的错误问题。
【已解决】J-Flash ARM烧写Nor Flash时出错:PC of target system has unexpected value after programming

【问题】

最近在用J-Flash ARM去烧写TQ2440板子上的Nor Flash,但是在烧写过程中,经常会出错:

PC of target system has unexpected value after programming

如图:


但是需要说明一点的是,在此之前,有段时间一直用此工具烧写Nor Flash的,都是很顺利,N多次,都没有任何出错的。

而现在出这样的错误的几率是9/10,即搞个好多次,才能偶尔又一次成功烧写的,搞得很是郁闷,严重影响心情和调试效率。

【解决过程】

1. 看着这现象,貌似是RAM不稳定或者没有初始化好,而导致J-Flash ARM运行有问题,没有正常烧写。

所以去尝试取消了RAM,即Options -> Project Settings -> CPU中,取消Use target RAM(faster)的话,好像是不会出错的,但是烧写起来,速度就太慢了,是一个一个字节烧写的,烧个200多K的u-boot.bin的话,估计得几十分钟,所以无法忍受。

还是需要用到Use target RAM(faster)来实现快速烧写的,这个只要一二十秒即可。

2.后来又去更改JTAG的工作频率,从很低的100KHZ到很高的4MHz,12MHz等,或者是Auto模式,都试了试,但是还是会出错。

3. 后来又去折腾,更改很多设置,看看是否有用。最后的最后,幸运地,终于找到解决办法了:

Options -> Project Settings -> CPU -> 'Use following init sequence:'中,默认只有一行:

0 reset 0 0ms reset and Halt target,

然后选中该行,点击Edit,修改Delay为2ms,确定,即可。

如图:


即在通过JTAG去reset重启目标开发板之后,再delay延迟个2毫秒,等待板子各种硬件都稳定了,然后再通过J-Flash ARM去烧写Nor Flash,此时就都一切正常了。

额外说句:

后来输入英文“PC of target system has unexpected value after programming”的时候,发现google上,也有对应的帖子的,只是自己之前没发现而已,惭愧啊。

不过刚去看其解决方法,倒是和我不太一样,其是把'Use following init sequence中的动作从默认的reset改为Halt,即使cpu暂停,使得CPU不会乱跑,然后接下来去烧写nor flash,也就正常了。而我此处的是reset后,等待2ms,目的也是等待系统稳定。目的相同,实现方法不同而已。

刚又看到别人讨论此现象的原因,说是可能是watchdog还在运行,导致系统reset,所以程序跑飞了,所以才出错的。

个人感觉不是很像,如果是watchdog还在运行导致出错,那么我们上面的reset后,多加的2ms的delay后,也还是会出错才对,但是我这里是可以解决问题,不会出错的,所以,感觉是系统reset后,需要一段时间,等稳定下来,继续操作,才正常的。

不过有空是可以尝试去设置关闭watchdog,看看是否能解决问题。

经过尝试,发现添加对应动作去在reset后,关闭watchdog:

0x53000000= 0x0; /* make sure bit5=0 to disable watchdog */

如图:


但是再去烧写nor flash,还是会出错,所以,可以确定不是watchdog的问题,而很可能是TQ2440在reset后,系统稳定性的问题,需要有个延迟以等待系统稳定。

【总结】

1.遇到问题,还是需要大胆地多去折腾折腾,最后往往会有效果的。即使没解决问题,也会有新的发现的。

【引用】

1.Solved: J-Flash ARM: PC of target system has unexpected value after 。。。

http://lesca.me/blog/2011/02/25/solved-j-flash-arm-pc-of-target-system-has-unexpected-value-after/

2. 使用J-Link下载程序到Nor Flash3650395344

http://blog.mcuol.com/User/Leo_lei/Article/36503_1.htm

在嵌入式系统中,擦除 Flash 扇区后目标系统的程序计数器(PC)出现意外值是一个严重的问题,通常与 Flash 操作的中断处理、中断向量表损坏或代码执行流的异常跳转有关。以下是对可能原因的分析以及相应的解决方案: ### 原因分析 1. **Flash 擦除操作中断了正常执行流** Flash 擦除是阻塞式操作,若在擦除过程中没有正确关闭中断或暂停任务调度,可能导致程序计数器跳转到非法地址。特别是在使用 RTOS 的系统中,任务切换与 Flash 操作冲突会引发不可预测的行为[^1]。 2. **中断向量表被擦除或覆盖** Flash 扇区中可能包含中断向量表,若擦除操作影响了该区域,系统在中断发生将跳转到无效地址,表现为 PC 值异常。这种情况常见于未对 Flash 扇区进行精细管理的系统中[^2]。 3. **堆栈指针(SP)或链接寄存器(LR)异常** 如果 Flash 操作过程中堆栈被破坏或函数调用未正确返回,可能导致程序计数器指向错误地址。这通常与 Flash 操作函数本身未正确实现或优化有关。 4. **未对 Flash 操作函数进行内存保护配置** 在擦除 Flash ,若未正确配置内存保护单元(MPU)或缓存(Cache)设置,可能导致代码执行异常,表现为 PC 值跳转到非法地址。 5. **硬件异常或看门狗复位** Flash 操作耗较长,若未及喂狗,可能触发看门狗复位,导致系统重启后 PC 指向复位向量,表现为“意外值”。 ### 解决方案 1. **确保 Flash 操作期间关闭中断** 在执行 Flash 擦除操作前,应关闭全局中断或屏蔽相关中断源,确保操作期间不会被中断打断。操作完成后恢复中断状态。 ```c __disable_irq(); flash_erase_sector(target_sector); __enable_irq(); ``` 2. **保护中断向量表所在扇区** 在设计 Flash 分区,确保中断向量表所在的扇区不会被意外擦除。可以将向量表固定在 Flash 起始地址,并在擦除操作前进行地址范围检查。 3. **使用独立的 RAM 函数执行 Flash 操作** 将 Flash 操作函数放置在 RAM 中执行,避免在 Flash 操作期间因读取指令失败而导致异常。通常通过链接脚本或编译器指令实现: ```c void __attribute__((section(".ram_code"))) flash_erase_sector(uint32_t sector); ``` 4. **检查堆栈与函数调用完整性** 在 Flash 操作前后插入堆栈指针检查逻辑,确保堆栈未被破坏。同,使用断言或调试器检查 LR 寄存器状态,确认函数调用链完整性。 5. **喂狗机制与异常处理** 在 Flash 操作期间定期喂狗,避免看门狗超复位。同,配置异常处理函数(如 HardFault_Handler)捕获 PC 异常跳转,辅助定位问题根源。 6. **启用 MPU 与缓存一致性管理** 若系统支持 MPU,确保 Flash 操作期间相关内存区域被正确映射为可执行与可。对于使用缓存的系统,执行 Flash 操作前应使缓存失效,操作后刷新缓存。 ### 总结 Flash 擦除后 PC 值异常通常是由于中断干扰、向量表破坏或执行流异常跳转所致。通过合理设计中断管理、Flash 分区策略以及内存保护机制,可以有效避免此类问题。在调试过程中,结合异常处理机制与调试器跟踪,有助于快速定位问题根源。 ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值