On Sat, May 23, 2009 at 8:49 AM, Dylan Reid <dgr...@gmail.com> wrote:
> Something strikes me as pretty broken here. Maybe I am seeing ghosts.
>
> I put in a few prints to see what was going on, then got confused and
> ran from the debugger. This is what I found:
>
>
> static int jlink_get_version_info(void)
> {
> int result;
> int len;
> u32 jlink_caps, jlink_max_size;
>
> /* query hardware version */
> jlink_simple_command(EMU_CMD_VERSION);
>
> result = jlink_usb_read(jlink_jtag_handle, 2);
> if (2 != result)
> {
> ///***** Sometimes this fails, that doesn't seem to matter
> LOG_ERROR("J-Link command EMU_CMD_VERSION failed
> (%d)\n", result);
> return ERROR_JTAG_DEVICE_ERROR;
> }
This is in line with my past testing. It seems to me Magnus' patch solved this.
> ///***** most of the time it works and we get to here
> ///***** Problem is that what is read is "J-" the first two bytes of
> the jlink identifier string
> len = buf_get_u32(usb_in_buffer, 0, 16);
> ///***** len now holds 11594, which is what buf_get_u32 returns when
> it is fed "J-"
> result = jlink_usb_read(jlink_jtag_handle, len);
> ///***** jlink_usb_read doesn't check the length of the buffer before reading
> ///***** so it wipes out a bunch of variables including jlink_jtag_handle
> if (result != len)
> {
> LOG_ERROR("J-Link command EMU_CMD_VERSION read failed
> (%d)\n", result);
> return ERROR_JTAG_DEVICE_ERROR;
> }
You are right. It should probably check the return result of the read
operation (usb_bulk_read).
> The crazy thing is that sometimes this works. Often enough to be
> usable actually. I added a check to jlink_usb_read and it makes it
> fail every time. I attached the patch as I think it is the right
> thing to do anyways. If you increase JLINK_IN_BUFFER_SIZE to
> something big enough, it will keep it functional.
Where is the patch?
> I don't have any experience with low level jtag interfacing, what is
> this code trying to do? Should something other than "J-" be returned
> after EMU_CMD_VERSION?
>
> Wish I had more time to debug this tonight, but if I don't get home
> for memorial day weekend the GF is not going to be too happy :-)
I am also thinking that the USB timeout value may be extended a bit longer.
Right now it is 1000ms. Should be ok. But may not be ok for people
using VM or similar.
--
Xiaofan http://mcuee.blogspot.com
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
