the unlocking procedure erases the flash mem (even if it wasn't locked), so it should be marked as erased after unlocking.
Change-Id: I5cc6a1e1d6cf4e1f243de532eff54111ffd66187
Signed-off-by: Rodrigo L. Rosa <rodrigorosa.lg@gmail.com>
Reviewed-on: http://openocd.zylin.com/222
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
if JTAG debug request fails then halting with a reset should be attempted.
the failure was ignored previously.
Change-Id: Ibec08e2e97f962d164a110c21aaa80bfc17b7f1a
Signed-off-by: Rodrigo L. Rosa <rodrigorosa.lg@gmail.com>
Reviewed-on: http://openocd.zylin.com/221
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
i had assumed two possible halt/debug states:
- halted + debug mode
- running + not debug mode
turns out this one also exists
- halted + NOT in debug mode
added code to handle this in an appropiate way.
Change-Id: Ia0ddcd55d1890c90d100a9e6f5e84ed8dda812a3
Signed-off-by: Rodrigo L. Rosa <rodrigorosa.lg@gmail.com>
Reviewed-on: http://openocd.zylin.com/220
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
now the flash algorithm running on the 568013 checks the buffer_empty bit (instead of the command_finished bit) before trying to write a new word to the flash mem.
this should speed up the flashing procedure. since it is open loop, this change may reduce the risk of failure. flashing will fail if JTAG speed is such that the flash module cannot keep up.
also, the USTAT register is only read once, as suggested in the flow chart provided by freescale (per. ref. manual @ 6-11)
the last step of the flow chart, exiting after commands are complete, is not implemented.
the algorithm will stay waiting for more data. it is up to the PC side to *not* send more data.
Change-Id: I47fe4b50de7da85f80868f5986a89a7e2152616c
Signed-off-by: Rodrigo L. Rosa <rodrigorosa.lg@gmail.com>
Reviewed-on: http://openocd.zylin.com/219
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
moved reset_jtag to the top, since it will be needed in future changes.
also send a define to the .h
Change-Id: I53ef9c02ffa70e7d0416364525a6fbfef855e222
Signed-off-by: Rodrigo L. Rosa <rodrigorosa.lg@gmail.com>
Reviewed-on: http://openocd.zylin.com/216
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
added logging of target error codes to enable automatic error handling from tcl.
the plan is to use a computer to execute a series of tcl commands, the changes allow simple parsing of return messages to detect errors.
Change-Id: Ia98d3bd036e1b6065b475ffff6c1d30baeaf7417
Signed-off-by: Rodrigo L. Rosa <rodrigorosa.lg@gmail.com>
Reviewed-on: http://openocd.zylin.com/215
Tested-by: jenkins
Tested-by: Øyvind Harboe <oyvindharboe@gmail.com>
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
added an attempt to use the non-reseting halting sequence. if it fails, then the full sequence will be attempted. this makes things a bit faster most of the time.
changed the location of a function, avoiding a forward def
added an alternative way to enter debug mode, which does not require restarting the chip.
this will not always work, but in general it will (failure 0.3%), and failure is not a dramatic issue, simply have to use the full sequence.
the user can only access "halt", which uses the full sequence, so the user should not have any problems.
restarting the chip requires reconfiguring the flash module. the doc is very poor, so i'd rather have the two methods, and live with the 0.3%.
sometimes the master tap will be enabled, since tap switching is required during halt/lock/unlocking procedures.
now irscan handles this, avoiding unnecessary warnings and preventing errors.
got new info regarding setting the chip to debug mode, and locking/unlocking flash memory.
the newer implementation is a bit slower, but always works.
the previous implementation would randomly (as once every 25k-70k times) get the chip into a state where the freescale tool would be necessary. this is fixed now.
added functions to play around with the jtag state machine. they are not the happiest, but are necessary to be able to execute the halting/locking/unlocking sequences.
Conflicts:
src/target/dsp5680xx.c
the user can execute halt, but no enter_debug_mode. modified the error handling to suite this.
the new implementation of unlocking will use enter_debug_mode, and should not get the same errors as the user would, because not being able to enter debug mode is actually success when checking for locked flash.
crc check was always performed on newly flashed data, now it is optional
flash mem can be locked by writing a specific word to a specific address in flash.
to verify flash, target must be halted, and this will (when the new halt sequence is implemented) require reseting the chip. if the target is reset after writing the lock words, then it will lock, hence the CRC will fail because it is not possible to read stuff from the target.
also added a function that resets the jtag state machine.
this is not used yet, but will be soon.
it is implemented to allow strict control over JTAG state machine, necessary to implement to halt and unlocking sequences.
i had started my code from dsp5683xx, i renamed a bunch of stuff to names i consider to be better.
i believe no one is using this code, so nobody should be affected. (it's not too late to do this change)
before doing anything with the flash module (FM) the clock divider must be set.
if erase_check was the first thing done with the FM after reset then an error would be generated because the clk divider was not set.
now erase_check sets the clk divider.
reorganized code to get rid of compiler warnings
the warning were related to allignment, i do not get these warning on my build system (i've tried setting the compiler flag but it doesn't work, still working on why) so i cannot detect them (yet.)
cygwin does not define sleep, so use our internal win32 version.
caused by commit 9d4aec6bda
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
rodrigo_l_rosa
Øyvind Harboe
Spencer Oliver