Committed.
The fix in the attached patch allows examination of
debug reason to succeed.... The "BUG:" have been
downgraded to "WARNING:"
This fixes problems with interpreting the reason why the
target was halted on arm926ejs. There are some MOE
values that are not well documented these are interpreted
as DBGRQ requests. Perhaps they should be interpreted
as "unknown"?
The generic arm7_9 code does not have any conditional
code based on the interpreted reason, unless dbgreq is
enabled(not default), so reporting the wrong debug reason
is relatively harmless when dbgrq is not enabled.
I have never used the dbgrq option. It's currently
only used by ti parts in the scripts that ship w/OpenOCD.
The dm6446 is an arm926ejs part.
i.MX27 works better now w/"reset run" + "halt" + "step"
sequence(other problems remain though).
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/arm926ejs.c
===================================================================
--- src/target/arm926ejs.c (revision 2477)
+++ src/target/arm926ejs.c (working copy)
@@ -360,20 +360,21 @@
* openocd development mailing list if you have hardware
* to donate to look into this problem....
*/
- LOG_ERROR("mystery debug reason MOE = 0xc. Try issuing
a resume + halt.");
+ LOG_WARNING("WARNING: mystery debug reason MOE = 0xc.
Try issuing a resume + halt.");
target->debug_reason = DBG_REASON_DBGRQ;
- retval = ERROR_TARGET_FAILURE;
break;
default:
- LOG_ERROR("BUG: unknown debug reason: 0x%x",
debug_reason);
+ LOG_WARNING("WARNING: unknown debug reason: 0x%x",
debug_reason);
+ /* Oh agony! should we interpret this as a halt request
or
+ * that the target stopped on it's own accord?
+ */
target->debug_reason = DBG_REASON_DBGRQ;
/* if we fail here, we won't talk to the target and it
will
* be reported to be in the halted state */
- retval = ERROR_TARGET_FAILURE;
break;
}
- return retval;
+ return ERROR_OK;
}
uint32_t arm926ejs_get_ttb(target_t *target)
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
