# Problem with ARM926EJS **URL:** \ **Category:** MicroMod\ **Tags:** arm-lpc\ **Created:** [September 4, 2007, 12:50pm UTC](https://community.sparkfun.com/t/problem-with-arm926ejs/5201 "2007-09-04T12:50:22Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![ricard](https://avatars.discourse-cdn.com/v4/letter/r/3bc359/32.png) [@ricard](https://community.sparkfun.com/u/ricard)\ **Post date:** [September 4, 2007, 12:50pm UTC](https://community.sparkfun.com/t/problem-with-arm926ejs/5201/1 "2007-09-04T12:50:22Z")
Hi, I’m doing some development on a chip containing an ARM926EJS core, trying to use openocd for debugging. I’ve successfully built OpenOCD from svn r203, configured to use a Xilinx DLC7 (Xilinx Parallel Cable IV), which at least as far as OpenOCD is concerned seems identical to the DLC5 (Xilinx Parallel Cable III) which OpenOCD supports out of the box. I’ve gotten the basic configuration to work (target set to arm926ejs, scan chain configured), and I seem to be able to do some basic operations (halt, resume, reg) when the CPU is running with the MMU off. However, the goal is to set up a debugging environment for a running Linux system, and when I try to halt the processor when Linux has started, I run into one (or both) of two failure modes. I’ve run openocd with the --debug flag to get some info on what’s going on. 1. First of all, In most cases, the following output is given, and openocd terminates, when I give the ‘halt’ command to openocd: … Debug: arm926ejs.c:328 arm926ejs\_examine\_debug\_reason(): internal debug request Debug: arm7\_9\_common.c:1047 arm7\_9\_debug\_entry(): target entered debug from ARM state Debug: arm7\_9\_common.c:1073 arm7\_9\_debug\_entry(): target cpsr is 0x2fa68, core mode 0x8 Error: armv4\_5.c:187 armv4\_5\_mode\_to\_number(): invalid mode value encountered Error: arm7\_9\_common.c:1077 arm7\_9\_debug\_entry(): cpsr contains invalid mode value - communication failure Error: target.c:1157 handle\_target(): couldn’t poll target, exiting (additional debug texts added by me to print out the values that causes opneocd to fail). The actual cpsr value varies; sometimes it is 0. 1. If the above doesn’t happen , then I get the symptom that (most often, though not always) when halting the CPU with Linux running, the PC is 0x00000000. When resuming, the processor seems to run from there, which is the boot up process, although it doesn’t seem to reboot the system, possibly due to incorrect hardware initialization at this point, and just ends up in an endless loop waiting for some hardware event to occur. In any case, I see the following when I type resume: Debug: arm926ejs.c:105 arm926ejs\_catch\_broken\_irscan(): caught ARM926EJ-S invalid Capture-IR result after CP15 access Sometimes (very seldom), openocd will hang when I gi ve the halt command. The odd time I have been able to halt and resume a booting Linux system, at least a couple of times. I read in a post here [http://www.embeddedrelated.com/groups/l … /24076.php](http://www.embeddedrelated.com/groups/lpc2000/show/24076.php) about a problem with the ARM926EJS when accessing the CP15 register, but that was a while ago (r141) and surely the patch must have made it into the svn repository by now; indeed the message from arm926ejs\_catch\_broken\_irscan() above indicates that the workaround mentioned in the post has been implemented. I’ve tried setting jtag\_speed to 100 to slow things down, but it doesn’t seem to make a difference. (Mostly I’ve been using jtag\_speed 10). The fact that I only seem to have problems while Linux is running - I can successfully halt and resume prior to this point - leads me to believe it has something to do with the MMU. Does anyone have any ideas? I can’t see that there is really anything else to configure that may be target implementation-specific, or ARM926EJS-specific but of course I could be very wrong. I’ve got more debugging output if anyone’s interested. /Ricard ---
**Author:** ![ricard](https://avatars.discourse-cdn.com/v4/letter/r/3bc359/32.png) [@ricard](https://community.sparkfun.com/u/ricard)\ **Post date:** [September 26, 2007, 9:31am UTC](https://community.sparkfun.com/t/problem-with-arm926ejs/5201/2 "2007-09-26T09:31:41Z")
Figured out the problem after a lot of headaches. Turned out the watchdog was enabled in the Linux kernel, so once the debugger stopped, the watchdog would bite soon afterwards. Disabling the watchdog cured the problem, and it now works like a charm. Cheers! /Ricard ---
**Author:** ![omissam1972](https://avatars.discourse-cdn.com/v4/letter/o/439d5e/32.png) [@omissam1972](https://community.sparkfun.com/u/omissam1972)\ **Post date:** [November 17, 2007, 6:59pm UTC](https://community.sparkfun.com/t/problem-with-arm926ejs/5201/3 "2007-11-17T18:59:25Z")
> ricard: > Figured out the problem after a lot of headaches. Turned out the watchdog was enabled in the Linux kernel, so once the debugger stopped, the watchdog would bite soon afterwards. Disabling the watchdog cured the problem, and it now works like a charm. > > Cheers! > > /Ricard hello, I have the same problem when I try of re-flashing: > \> flash write\_binary 0 c:\uboot\uboot.bin 0x0 > > failed writing file c:\uboot\uboot.bin to flash bank 0 at offset 0x00000000 > > can’t work with this flash while target is running > > wrote 458884 byte from file c:\uboot\uboot.bin to flash bank 0 at offset 0x0000 > > 0000 in 0s 15625us (28680.250000 kb/s) you can give some indication to me in more? Mine cpu is one marvell feroceon 88f5181. thanks