I don't see any attachments, so I can't evaluate how it differs from the
previous script I submitted (and use). The one currently in the
repository needs a few updates (such as removing the halt, and using
reset-start and reset-end, and using arm7_9 fast downloads).
I've attached my current v
using GDB.
Regards,
Ethan Eade
# lpc3250 config
#
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME lpc3250
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTA
>> This fixes the same problem on our iMX35 (Cogent CSB732).
>> GDB breakpoints didn't work properly in the previous versions and do
>> work now.
>>
>
> Thanks for the confirmation!
>
> When you say "in the previous versions" ... roughly which versions?
>
Breakpoints were working on the
this works on other ARM1136 targets.
>
This fixes the same problem on our iMX35 (Cogent CSB732).
GDB breakpoints didn't work properly in the previous versions and do
work now.
Thanks,
Ethan Eade
> - Dave
> ___
> Openocd-developmen
Attached is the board config I've written for the CSB732, including
basic clocking and SDRAM initialization.
Single stepping and burst writing work correctly. I haven't tried flashing.
Regards,
Ethan
# The Cogent CSB732 board has a single i.MX35 chip
source [find target/imx35.cfg]
# Determine
With the following reset config:
reset_config srst_only srst_pulls_trst
...revisions beyond 2620 could not load code to the i.MX35. Revision
2621 fixes the logic for srst/trst, so I tried messing around with that
part.
Changing my config to:
reset_config trst_and_srst combined
...makes every
While doing a regression binary search on OpenOCD revisions, I noticed
only by chance that ./configure was issuing a warning about my libftdi
version (I had 0.12, it wants 0.16). I then upgraded the version,
eliminating the warning.
What are the consequences of the version mismatch? Should th
Øyvind Harboe wrote:
arm11 code is broken in 2046->2047 ref:
https://lists.berlios.de/pipermail/openocd-development/2009-September/010644.html
I've looked at this and it is a pretty hellish problem to
figure out from a code inspection point of view.
Agreed; I went the route of instrumenting
is platform). This could
be a problem with RAM initialization caused by other errors.
Looking at svn diff -c 2047, I see several changes in jtag/jtag.c that
replace global variable 'cmd_queue_end_state' with function argument
'state'.
Any suggestions?
Thanks,
Ethan Eade
