Hi Woody,
On Wed, Feb 27, 2013 at 10:12 AM, Woody Wu <[email protected]> wrote: > After I power up my board and start openocd, I can see my config file > run with no error and my board get a reset and the bootloader continuous > to run -- the bootloader and Linux has a serial console, so I can > monitor the running of my board. > > There is something I want to ask for the scenario so far: since my > board get reseted after the openocd started, does this mean that the > openocd issued a 'reset' to my target and succeeded? What is your cfg script with which you start OpenOCD - look at the end what is executed, and if reset init is called. > The user manual > mentioned that in the last step of openocd's configuration stage, it > will do a 'init' + 'reset', but no more details. You do not have to reset your board - you can just attach to a running system, halt it and debugg it. What you want to do is configurable in TCL script (cfg file). > Since, as what I will > describe shortly, I cannot successfully issue 'reset xxx' command from > telnet client, so I am so confused what's the difference between my > failed reset and this time of successful reset in the end of > configuration stage. Well, it is difficult to say, but maybe some running system is holding some reset lines, or prohibiting writing in some regs, or hiding some regs in special mode... There is tons of possibilities. > While my board is running and the openocd is listening, I started a > telnet connection to it and issued the some 'reset xxx' command to it. I > tried with 'reset halt', 'reset init' and 'reset run'. The following > information and log focus on 'reset halt' only, but for the other kinds > of reset command, what happened to me are more or less similar. > > > reset halt > JTAG tap: s3c2416.cpu tap/device found: 0x07926f0f (mfg: 0x787, > part: 0x7926, ver: 0x0) > WARNING: mystery debug reason MOE = 0xc. Try issuing a resume + halt. > invalid mode value encountered 0 > cpsr contains invalid mode value - communication failure > > > in procedure 'reset' > WARNING: mystery debug reason MOE = 0xc. Try issuing a resume + halt. > target state: halted > target halted in ARM state due to debug-request, current mode: User > cpsr: 0x08100050 pc: 0x08100038 > MMU: disabled, D-Cache: disabled, I-Cache: disabled > > > >From the above output, I see, there is a warning 'mystery debug reason > MOE = 0xc', I am not sure I can safely ignore it. I'd look at the code and ARM spec to see what this means... But probably not a good sign. > At the end, it seems > the command completed with success. In the same time, on my Linux > console window, I found, my board is get reset and then continuous to > run and then *halted* at some early step of the bootloader. Then, in the > openocd session, I used 'targets' command to check my target status. > However, the reported status is 'running' > >> targets > TargetName Type Endian TapName State > -- ------------------ ---------- ------ ------------------ ------------ > 0* s3c2416.cpu arm926ejs little s3c2416.cpu running As I said - not a good sign ;). What does command "poll" says ? > Then I tried to issue 'halt' from the openocd, sometimes it succeeded > and the target status is reported as 'halted' but sometimes it cannot > succeeded with an error 'halt time out ...'. And, in whatever case, I > cannot resume my board with 'resume'. I believe that the previous 'halt > xxx' command had brought my target to an incorrect non-functional > status. > > Can someone please help me? Your reset is not working correctly, and it might be physical reset lines. Do you have some other SW to check your reset configuration : 1) prevent Linux to run (or temporary remove it from flash) and try to play around halting/resuming bootloader. If this does not work, then 2) Remove bootloader, and in it's place put a small ASM hello world (write a few registers in an infinite loop) - try halting and reseting the board. > Below are some information about my environment: > > - my adapter is running at 5K Hz, I found put it too faster or too > slower than this just resulted in even more error and not stable. > - in my init_board() procedure, I configured the reset behavior as > following: > reset_config trst_and_srst > adapter_nsrst_assert_width 2000 > adapter_nsrst_delay 2000 How did you came up with this reset configuration ? > > The last is a very basic openocd question: I found my reset-init event > handler never get executed, is that normal? My understanding is, the > 'reset' has at least succeeded for one time, that is when the openocd > entered into the run stage and I really saw that my board is get reseted > as I just described before. So, my handler should get triggered bug it > was not. The handler defined as: > > > proc init_board {} { > ... > > $_TARGETNAME configure -event reset-init { > echo "event: reset-init" > } > } Looks OK to me, insure that init reset is called. Here you just configure what will be done on reset init, but if you never call it - well... nothing will be done ;). BR, Drasko ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
