**** BEGIN LOGGING AT Sat Mar 14 02:59:57 2009 Mar 14 03:18:04 * flyback needs to know if anyone knows of a quality brand of DVD-RAM he can buy in bulk Mar 14 03:55:18 http://www.liveleak.com/view?i=dc0_1232310806 <--- HELL YES! Mar 14 05:18:44 * flyback breaks down and builds a temp windows 2000 box tomarrow so he can move around some ntfs drive files Mar 14 10:26:52 any openocd devs around? i'm having a curious problem with a cortex m3 and breakpoints Mar 14 10:27:21 the target nearly immediately halts after a reset Mar 14 10:27:42 if i debug it with gdb, it appears the debug registers are filled with some junk data Mar 14 10:28:04 gdb can clear the debug registers (clearing the breakpoint), and then execution continues as normal Mar 14 10:40:18 you mean you don't want it to halt? Mar 14 10:40:26 no, Mar 14 10:40:44 it shouldn't be halting, i haven't set any breakpoints yet Mar 14 10:40:59 check the config, many of deault ones specify halt after reset Mar 14 10:41:24 otherwise enable debug tracing, maybe you can see some clues Mar 14 10:41:41 which config option do i look for? Mar 14 10:41:50 i have reset_config set to trst_and_srst Mar 14 10:42:11 no, that one comes later Mar 14 10:42:33 let me see if i can find it... Mar 14 10:43:04 thanks Mar 14 10:46:10 actually, looks like somebody else is having exactly the problem i'm having: Mar 14 10:46:10 http://forum.sparkfun.com/viewtopic.php?t=14603 Mar 14 10:47:44 hmm what if you do "reset run" instead of just "reset"? Mar 14 10:48:04 same thing Mar 14 10:48:17 looks like a bug then... Mar 14 10:48:29 do you get the same log? Mar 14 10:48:43 let me check Mar 14 10:49:47 it would appear so Mar 14 10:50:11 the PC at which it halts at is somewhat variable Mar 14 10:50:24 within a couple of instructions Mar 14 10:50:29 can you try increasing debug level? Mar 14 10:50:38 i'm at -d 3 Mar 14 10:50:46 Debug: 917 88269 cortex_m3.c:400 cortex_m3_debug_entry(): entered debug state in core mode: Thread at PC 0x2eee, target->state: halted Mar 14 10:50:46 Debug: 918 88269 target.c:696 target_call_event_callbacks(): target event 4 (early-halted) Mar 14 10:50:46 Debug: 919 88269 target.c:3054 target_handle_event(): event: 4 early-halted - no action Mar 14 10:50:46 Debug: 920 88269 target.c:696 target_call_event_callbacks(): target event 5 (halted) Mar 14 10:50:46 Debug: 921 88269 target.c:3054 target_handle_event(): event: 5 halted - no action Mar 14 10:50:46 i see Mar 14 10:50:48 User : 922 88269 target.c:959 target_arch_state(): target state: halted Mar 14 10:50:49 User : 923 88269 armv7m.c:473 armv7m_arch_state(): target halted due to undefined, current mode: Thread Mar 14 10:50:51 xPSR: 0x21000000 pc: 0x00002eee Mar 14 10:50:54 User : 924 88269 command.c:494 command_run_line(): Mar 14 10:52:47 as a workaround you could try adding a halt event handler Mar 14 10:53:16 http://openocd.berlios.de/doc/Target-Configuration.html Mar 14 10:53:50 have them clear out the debug registers and do a reset? Mar 14 10:54:33 just continue might work too Mar 14 10:58:23 okay, that looks okay Mar 14 10:58:26 i'll use that in the meantime Mar 14 10:58:41 any suggestions to dig into this further? i guess i'll file a bug Mar 14 11:00:01 yes, better post to ML Mar 14 11:00:19 i think a few people there were using m3 Mar 14 11:00:36 you can also try debugging it yourself :) Mar 14 11:02:18 :P Mar 14 18:45:09 * flyback back later Mar 14 20:29:24 * flyback be back tonight Mar 15 02:50:05 * flyback grumbles loudly as he loses a 16mb cf drive **** ENDING LOGGING AT Sun Mar 15 02:59:56 2009