On Tuesday 22 December 2009, Dirk Behme wrote: > I did some additional tests: > > * I updated to 0.4.0-rc1-dev-00001-g4e2b15f (2009-12-23-08:09) > > * I have Beagle A4 and C1. > > * Both show above sticky errors after board "cold" start. I.e. power > up the board, let it wait at U-Boot prompt and then start > > openocd -s lib/openocd/ -f interface/flyswatter.cfg -f > board/ti_beagleboard.cfg > > will result in above sticky errors. > > * With a OpenOCD "warm" re-start (i.e. don't touch Beagle power, just > exit OpenOCD and restart it) I don't get above sticky errors.
Interesting. That means that something isn't yet handling some of the after-powerup state properly. I'd expect that to be somewhat straightforward to track down, if tedious, by working backwards from the first failure report. I've never seen it come up OK from power-up, myself. > Instead I get > > -- cut -- > ... > RCLK - adaptive > Warn : omap3530.dsp: huge IR length 38 > RCLK - adaptive > trst_only separate trst_push_pull > Info : RCLK (adaptive clock speed) not supported - fallback to 1000 kHz > Info : TAP omap3530.jrc does not have IDCODE > Warn : JTAG tap: omap3530.jrc UNEXPECTED: 0x00000000 (mfg: 0x000, part: > 0x0000, ver: 0x0) > Error: JTAG tap: omap3530.jrc expected 1 of 1: 0x0b7ae02f (mfg: 0x017, part: > 0xb7ae, ver: 0x0) > Error: Trying to use configured scan chain anyway... > Warn : Bypassing JTAG setup events due to errors > -- cut -- > > which can be "fixed" by manual 'reset halt': And that's the sequence I'm used to seeing. From here on, after "reset halt", everything works "fine" for me. > * Regarding above question "What was it trying to access when it got > those [sticky] errors?" I enabled --debug and got stuff below [1]. > Does this help? I'd have to look in more detail at that code, which I don't have time for just now. These aren't errors I've seen. However, I do know that when a "sticky" error crops up, it doesn't seem to disappear for a while. Which is why I've suspected there's not just something going wrong to trigger such errors in the first place ... but also something going wrong in its cleanup. (Though of course it could just be repeats of the initial error.) - Dave > Best regards > > Dirk > > [1] Output of > > openocd -s lib/openocd/ -f interface/flyswatter.cfg -f > board/ti_beagleboard.cfg --debug > > regarding sticky errors reported above: > > ... > Debug: 578 133 arm_adi_v5.c:960 ahbap_debugport_init(): > > Debug: 579 141 arm_adi_v5.c:1005 ahbap_debugport_init(): AHB-AP ID > Register 0x14770001, Debug ROM Address 0xffffffff > Debug: 580 156 cortex_a8.c:1502 cortex_a8_examine_first(): cpuid = 0x411fc082 > Debug: 581 156 cortex_a8.c:1503 cortex_a8_examine_first(): ctypr = 0x80048004 > Debug: 582 156 cortex_a8.c:1504 cortex_a8_examine_first(): ttypr = 0x00202001 > Debug: 583 156 cortex_a8.c:1505 cortex_a8_examine_first(): didr = 0x15141012 > Info : 584 156 arm_dpm.c:874 arm_dpm_setup(): omap3530.cpu: hardware has 6 > breakpoints, 2 watchpoints > Debug: 585 156 cortex_a8.c:518 cortex_a8_bpwp_disable(): A8: bpwp disable, cr > 54011140 > Debug: 586 158 arm_adi_v5.c:243 swjdp_transaction_endcheck(): swjdp: > CTRL/STAT error 0xf0000021 So *both* sticky error bits are set, after trying to mem_ap_write_atomic_u32() to zero that 0x54011140 control register address. Maybe a few more things needed to be turned on? > Error: 587 158 arm_adi_v5.c:254 swjdp_transaction_endcheck(): AHBAP > Cached values: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0x54011140 > > > Error: 588 158 arm_adi_v5.c:259 swjdp_transaction_endcheck(): SWJ-DP > STICKY ERROR > Debug: 589 160 arm_adi_v5.c:267 swjdp_transaction_endcheck(): swjdp: > status 0xf0000001 > Error: 590 161 arm_adi_v5.c:273 swjdp_transaction_endcheck(): Read > MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 > Debug: 591 161 cortex_a8.c:518 cortex_a8_bpwp_disable(): A8: bpwp > disable, cr 54011144 > Debug: 592 163 arm_adi_v5.c:243 swjdp_transaction_endcheck(): swjdp: > CTRL/STAT error 0xf0000021 > Error: 593 163 arm_adi_v5.c:254 swjdp_transaction_endcheck(): AHBAP > Cached values: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0x54011140 > > > ... repeats for other addresses deleted ... That looks like the "make sure all breakpoint and watchpoint units are disabled when OpenOCD starts" loop is hitting errors. Which I certainly have not seen. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
