We time out looking for a pattern from OpenOCD. When debugging OpenOCD setup, sometimes you have to enable debug mode. This can be done by using the command-line option '-d' (which we can't do with Cortex-Debug) or in a config script by doing a 'debug_level 3'
The trouble is initMatch for OpenOCD. When in debug mode, the messages are very different. It includes file names and such from where the message is coming from -- so lots of dot chars. Also, there will be too many references to .cpu. which may have nothing to do with gdb port opening. A vendor (I think) can also name their CPUs differently from normal convention, I fixed it in my fork looking specifically for a gdb connection being enabled
Old initMatch: /Info\s:\s([^\n\.]).cpu([^\n])/i
New InitMatch: /Info\s:[^\n]*Listening on port [0-9]+ for gdb connection/i
I have this change in my fork, along with a couple of other changes...
https://github.com/haneefdm/cortex-debug
We time out looking for a pattern from OpenOCD. When debugging OpenOCD setup, sometimes you have to enable debug mode. This can be done by using the command-line option '-d' (which we can't do with Cortex-Debug) or in a config script by doing a 'debug_level 3'
The trouble is initMatch for OpenOCD. When in debug mode, the messages are very different. It includes file names and such from where the message is coming from -- so lots of dot chars. Also, there will be too many references to .cpu. which may have nothing to do with gdb port opening. A vendor (I think) can also name their CPUs differently from normal convention, I fixed it in my fork looking specifically for a gdb connection being enabled
Old initMatch: /Info\s:\s([^\n\.]).cpu([^\n])/i
New InitMatch: /Info\s:[^\n]*Listening on port [0-9]+ for gdb connection/i
I have this change in my fork, along with a couple of other changes...
https://github.com/haneefdm/cortex-debug