Menu
▾
▴
openocd-user
|
From: Trampas S. <tr...@gm...> - 2016-07-31 20:25:37
|
I have a FT2232 device I am trying to use where the first channel is JTAG and second is used for debug UART. When I configure the first channel for WinUSB driver OpenOCD can not connect. When I configure the parent of the composite device to use WinUSB OpenOCD will connect but I loose the UART/com port. I was wondering if I am missing something or if it is even possible to use the second port on the FT2232 with OpenOCD connected to first port? Thanks Trampas |
|
From: Juan C. <jce...@nu...> - 2016-07-31 21:15:19
|
Try using zadig as is shown in this open project http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:firmware:instalacion_sw It uses FT2232 in the same way you need Good luck Juan El 31 de julio de 2016 5:25:31 PM GMT-03:00, Trampas Stern <tr...@gm...> escribió: >I have a FT2232 device I am trying to use where the first channel is >JTAG >and second is used for debug UART. > >When I configure the first channel for WinUSB driver OpenOCD can not >connect. When I configure the parent of the composite device to use >WinUSB >OpenOCD will connect but I loose the UART/com port. I was wondering >if I >am missing something or if it is even possible to use the second port >on >the FT2232 with OpenOCD connected to first port? > >Thanks >Trampas > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ > > >------------------------------------------------------------------------ > >_______________________________________________ >OpenOCD-user mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openocd-user |
|
From: Trampas S. <tr...@gm...> - 2016-08-01 14:12:05
|
I have used the FTDI programming tool to name the FT2232H device "Misfit"
Using Zadig the composite device is using the usbccgp driver:
[image: Inline image 2]
Interface 0 of the device is using WinUSB
[image: Inline image 3]
interface 1 is using FTDIBUS serial driver:
[image: Inline image 4]
Here is my interface configuration script:
interface ftdi
ftdi_device_desc "Misfit (Interface 0)"
ftdi_vid_pid 0x0403 0x6010
transport select swd
#ftdi_layout_init first word is initial data level, second is direction for
direction a "1" is output, "0" is input
#
ftdi_layout_init 0x0030 0x1F3b
ftdi_layout_signal LED -ndata 0x0800
ftdi_layout_signal LED2 -ndata 0x1000
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -noe 0x0020
ftdi_layout_signal SWD_EN -data 0x0200
When I try and connect using OpenOCD I get the following errors:
C:\Program Files\GNU ARM
Eclipse\OpenOCD\0.10.0-201601101000-dev\bin>openocd_old.exe -f "C:\Program
Files\GNU ARM
Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\interface\ftdi\misfit_swd.cfg"
-f "C:\Program Files\GNU ARM
Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\board\atmel_samd21g18.cfg"
GNU ARM Eclipse 64-bits Open On-Chip Debugger
0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Warn : Interface already configured, ignoring
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description
'Misfit (Interface 0)' and serial '*'
>From looking at the code it appears that it looks for the devices with
matching VID/PID's and then looks for matching description. For the
FT2232H I think (not confirmed) that there should be three devices reported
with the same VID/PID (the composite, Interface 0, Interface 1). From what
I have read the order that these devices are parsed is not fixed, ie
interface 2 could be the first device which would print out the "Error:
libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED" as it does not have
WinUSB driver. However the code should eventually find the correct
interface and work, but does not seem to.
I am trying to get the code to build on windows at the moment to include
more information when the description does not match, it seems that on
windows the description is not consistent for example in Zadig it as shown
above, however in device manager it is shown as:
[image: Inline image 5]
I have tried both "Misfit" and "Misfit (Interface 0)", but neither works.
I would appreciate any help or suggestions.. Until then I am trying to
compile under cygwin so I can add more diagnostic messages to figure out
what is going on. Not the only guides I found for compiling on windows are
very old, version 0.5, and it appears a lot has changed since then.
Thanks
On Sun, Jul 31, 2016 at 4:25 PM, Trampas Stern <tr...@gm...> wrote:
> I have a FT2232 device I am trying to use where the first channel is JTAG
> and second is used for debug UART.
>
> When I configure the first channel for WinUSB driver OpenOCD can not
> connect. When I configure the parent of the composite device to use WinUSB
> OpenOCD will connect but I loose the UART/com port. I was wondering if I
> am missing something or if it is even possible to use the second port on
> the FT2232 with OpenOCD connected to first port?
>
> Thanks
> Trampas
>
|
|
From: Juan C. <jce...@nu...> - 2016-08-01 14:30:45
|
###############################################################################
#
# Copyright 2014, Juan Cecconi (UTN-FRBA, Numetron)
#
# This file is part of CIAA Firmware.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# 3. Neither the name of the copyright holder nor the names of its
# contributors may be used to endorse or promote products derived from this
# software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
###############################################################################
#OpenOCD configuration (target and interface) for CIAA-NXP
######################################################################################################
# Utilizar una interface tipo FTDI, todo lo que sigue está basado en ello
######################################################################################################
interface ftdi
######################################################################################################
# Agrego el Par VID-PID del FTDI, si hay más agregar a continuación...
######################################################################################################
ftdi_vid_pid 0x0403 0x6010
######################################################################################################
# Se utilizó el Channel A (ADBUS0 a ADBUS3) para conectar el JTAG mediante MPSSE
######################################################################################################
ftdi_channel 0
######################################################################################################
# ftdi_layout_init 'Valor' 'Dirección', Configura los GPIO (H-L), su valor y dirección en ese orden(1 = Salida, 0 = entrada)
# los 16 bits se arman H-L como sigue 'ACBUS7-0+ADBUS7-0'
#ADBUS0 = FT_CLCK = 1, salida de Clock
#ADBUS1 = FT_TDI = 1, salida de datos del FT
#ADBUS2 = FT_TDO = 0, entrada de datos al FT
#ADBUS3 = FT_TMS = 1, salida de Test Mode Select, setear a 1
#ADBUS4 = Pin 14 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ADBUS5 = Pin 12 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ADBUS6 = Pin 10 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ADBUS7 = Pin 8 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ACBUS0 = FT_TRST = 1, salida de TRST...va al buffer y luego no se usa, setear a 1
#ACBUS1 = FT_RST = 1, salida de RST...va al buffer y luego no se usa, setear a 1
#ACBUS2 = FT_OE = 1, salida de OE para manejar el Buffer del JTAG, setear a 1
#ACBUS3 = Pin 6 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ACBUS4 = Pin 4 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ACBUS5 = Pin 2 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ACBUS6 = Pin 1 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
#ACBUS7 = Pin 3 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
######################################################################################################
ftdi_layout_init 0x0708 0xFFFB
######################################################################################################
# La creación de las señales que siguen no hacen falta porque se indicó en el Target cfg que no se
# las tiene conectadas a ningún lado
######################################################################################################
######################################################################################################
# Creo la señal llamada nTRST (Not TAP Reset) que es una tipo dato, y usa el bit 8 del GPIO (H-L), es
# decir GPIOH0 (pin ACBUS0) por eso 0x100, y a la vez se activa conjuntamente con el OE que
# está usado en el bit 10 del GPIO, es decir, en GPIOH2 (pin ACBUS2) por eso 0x400
######################################################################################################
#ftdi_layout_signal nTRST -data 0x0100
######################################################################################################
# Creo la señal llamada nSRST (Not System Reset) que se activa cuando se hace un cmd 'reset'
# Es tipo dato y usa el bit 9 del GPIO (H-L), es decir GPIOH1 (pin ACBUS1) por eso 0x200,
# y a la vez se activa conjuntamente con el OE que está usado en el bit 10 del GPIO, es decir,
# en GPIOH2 (pin ACBUS2) por eso 0x400
######################################################################################################
#ftdi_layout_signal nSRST -data 0x0200
################################################################
# Especifica en KHz la frecuencia del Clock en el JTAG (TCK)
################################################################
transport select jtag
adapter_khz 2000
################################################################
# Defino nombre de CHIP
################################################################
set _CHIPNAME lpc4337
################################################################
# Defino los TAP del JTAG, para el core M4 y M0
################################################################
# M4 JTAG mode TAP
set _M4_JTAG_TAPID 0x4ba00477
# M0 TAP
set _M0_JTAG_TAPID 0x0ba01477
jtag newtap $_CHIPNAME m4 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_M4_JTAG_TAPID
jtag newtap $_CHIPNAME m0 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_M0_JTAG_TAPID
################################################################
# Creo los 2 targets lpc4337.m4 y lpc4337.m0
################################################################
target create $_CHIPNAME.m4 cortex_m -chain-position $_CHIPNAME.m4
target create $_CHIPNAME.m0 cortex_m -chain-position $_CHIPNAME.m0
################################################################
# Defino un area de trabajo en la RAM para acelerar el proceso
# de programación de la flash
################################################################
set _WORKAREASIZE 0x8000
$_CHIPNAME.m4 configure -work-area-phys 0x10000000 -work-area-size $_WORKAREASIZE
################################################################
# Se define un banco de flash, grabable usando el driver lpc2000
# que es compatible con el LPC4337
# flash bank <name> lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc checksum]
################################################################
set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME lpc2000 0x1a000000 0x80000 0 0 $_CHIPNAME.m4 lpc4300 96000 calc_checksum
################################################################
# Se define un banco de flash qspi, grabable usando el driver lpcspifi
# que es compatible con el LPC4337. Solo usable para la CIAA-NXP (no EDU)
# flash bank <name> lpcspifi <base> <size> 0 0 <target#>
################################################################
if { ![info exists ::env(BOARD)] || [info exists ::env(BOARD)] && [string equal $::env(BOARD) "ciaa_nxp"]} {
if { [info exists ::env(BOARD)]} {
echo "Using CIAA-NXP, qspi flash defined!"
} else {
echo "BOARD variable undefined: Using CIAA-NXP as default board, qspi flash defined!"
}
set _QSPIFLASHNAME $_CHIPNAME.spiflash
flash bank $_QSPIFLASHNAME lpcspifi 0x14000000 0 0 0 $_CHIPNAME.m4
} else {
echo "Using Edu-CIAA-NXP, qspi flash is not present!"
}
################################################################
# TRST (TAP Reset) y SRST (System Reset) no están conectados más allá del Buffer
# en el prototipo.
# Por lo tanto se indica 'none'
################################################################
reset_config none
################################################################
# on this CPU we should use VECTRESET to perform a soft reset and
# manually reset the periphery
# SRST or SYSRESETREQ disable the debug interface for the time of
# the reset and will not fit our requirements for a consistent debug
# session
################################################################
cortex_m reset_config vectreset
targets $_CHIPNAME.m4
$_CHIPNAME.m4 configure -event gdb-attach {
echo "Reset Halt, due to gdb attached...!"
reset halt
}
|
|
From: Trampas S. <tr...@gm...> - 2016-08-01 14:50:06
|
If I set "ftdi_channel 0" I get the following now:
C:\Program Files\GNU ARM
Eclipse\OpenOCD\0.10.0-201601101000-dev\bin>openocd_old.exe -f "C:\Program
Files\GNU ARM
Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\interface\ftdi\misfit_swd.cfg"
-f "C:\Program Files\GNU ARM
Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\board\atmel_samd21g18.cfg"
GNU ARM Eclipse 64-bits Open On-Chip Debugger
0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Warn : Interface already configured, ignoring
none separate
adapter speed: 400 kHz
cortex_m reset_config sysresetreq
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : clock speed 400 kHz
in procedure 'init'
in procedure 'ocd_bouncer'
which is different than before, but it still does not work.
On Mon, Aug 1, 2016 at 10:29 AM, Juan Cecconi <jce...@nu...>
wrote:
> In the open project We use this config file (check some details as
> "ftdi_channel 0").
> Bye
> Juan
>
>
> El 01/08/2016 a las 11:11, Trampas Stern escribió:
>
> I have used the FTDI programming tool to name the FT2232H device "Misfit"
>
> Using Zadig the composite device is using the usbccgp driver:
> [image: Inline image 2]
>
> Interface 0 of the device is using WinUSB
> [image: Inline image 3]
>
> interface 1 is using FTDIBUS serial driver:
> [image: Inline image 4]
>
>
> Here is my interface configuration script:
>
> interface ftdi
>
> ftdi_device_desc "Misfit (Interface 0)"
> ftdi_vid_pid 0x0403 0x6010
>
> transport select swd
>
> #ftdi_layout_init first word is initial data level, second is direction
> for direction a "1" is output, "0" is input
> #
> ftdi_layout_init 0x0030 0x1F3b
> ftdi_layout_signal LED -ndata 0x0800
> ftdi_layout_signal LED2 -ndata 0x1000
>
> ftdi_layout_signal nTRST -data 0x0010
> ftdi_layout_signal nSRST -noe 0x0020
>
> ftdi_layout_signal SWD_EN -data 0x0200
>
>
> When I try and connect using OpenOCD I get the following errors:
>
>
> C:\Program Files\GNU ARM
> Eclipse\OpenOCD\0.10.0-201601101000-dev\bin>openocd_old.exe -f "C:\Program
> Files\GNU ARM
> Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\interface\ftdi\misfit_swd.cfg"
> -f "C:\Program Files\GNU ARM
> Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\board\atmel_samd21g18.cfg"
> GNU ARM Eclipse 64-bits Open On-Chip Debugger
> 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:13)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Info : FTDI SWD mode enabled
> Warn : Interface already configured, ignoring
> none separate
> adapter speed: 400 kHz
> cortex_m reset_config sysresetreq
> Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
> Error: no device found
> Error: unable to open ftdi device with vid 0403, pid 6010, description
> 'Misfit (Interface 0)' and serial '*'
>
>
> From looking at the code it appears that it looks for the devices with
> matching VID/PID's and then looks for matching description. For the
> FT2232H I think (not confirmed) that there should be three devices reported
> with the same VID/PID (the composite, Interface 0, Interface 1). From what
> I have read the order that these devices are parsed is not fixed, ie
> interface 2 could be the first device which would print out the "Error:
> libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED" as it does not have
> WinUSB driver. However the code should eventually find the correct
> interface and work, but does not seem to.
>
> I am trying to get the code to build on windows at the moment to include
> more information when the description does not match, it seems that on
> windows the description is not consistent for example in Zadig it as shown
> above, however in device manager it is shown as:
> [image: Inline image 5]
>
> I have tried both "Misfit" and "Misfit (Interface 0)", but neither works.
>
> I would appreciate any help or suggestions.. Until then I am trying to
> compile under cygwin so I can add more diagnostic messages to figure out
> what is going on. Not the only guides I found for compiling on windows are
> very old, version 0.5, and it appears a lot has changed since then.
>
> Thanks
>
>
>
> On Sun, Jul 31, 2016 at 4:25 PM, Trampas Stern <tr...@gm...> wrote:
>
>> I have a FT2232 device I am trying to use where the first channel is JTAG
>> and second is used for debug UART.
>>
>> When I configure the first channel for WinUSB driver OpenOCD can not
>> connect. When I configure the parent of the composite device to use WinUSB
>> OpenOCD will connect but I loose the UART/com port. I was wondering if I
>> am missing something or if it is even possible to use the second port on
>> the FT2232 with OpenOCD connected to first port?
>>
>> Thanks
>> Trampas
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> OpenOCD-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/openocd-user
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user
>
>
|
|
From: Juan C. <jce...@nu...> - 2016-08-01 15:33:44
|
execute openocd with command line option "-d 3" (debug level 0 to 3) to get more details. This webpage does what you want. http://www.allaboutcircuits.com/technical-articles/getting-started-with-openocd-using-ft2232h-adapter-for-swd-debugging/ El 01/08/2016 a las 11:49, Trampas Stern escribió: > If I set "ftdi_channel 0" I get the following now: > > C:\Program Files\GNU ARM > Eclipse\OpenOCD\0.10.0-201601101000-dev\bin>openocd_old.exe -f > "C:\Program Files\GNU ARM > Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\interface\ftdi\misfit_swd.cfg" > -f "C:\Program Files\GNU ARM > Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\board\atmel_samd21g18.cfg" > GNU ARM Eclipse 64-bits Open On-Chip Debugger > 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:13) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > Info : FTDI SWD mode enabled > Warn : Interface already configured, ignoring > none separate > adapter speed: 400 kHz > cortex_m reset_config sysresetreq > Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED > Info : clock speed 400 kHz > in procedure 'init' > in procedure 'ocd_bouncer' > > which is different than before, but it still does not work. > > > > > On Mon, Aug 1, 2016 at 10:29 AM, Juan Cecconi > <jce...@nu... <mailto:jce...@nu...>> wrote: > > In the open project We use this config file (check some details as > "ftdi_channel 0"). > Bye > Juan > > > El 01/08/2016 a las 11:11, Trampas Stern escribió: >> I have used the FTDI programming tool to name the FT2232H device >> "Misfit" >> >> Using Zadig the composite device is using the usbccgp driver: >> Inline image 2 >> >> Interface 0 of the device is using WinUSB >> Inline image 3 >> >> interface 1 is using FTDIBUS serial driver: >> Inline image 4 >> >> >> Here is my interface configuration script: >> >> interface ftdi >> >> ftdi_device_desc "Misfit (Interface 0)" >> ftdi_vid_pid 0x0403 0x6010 >> >> transport select swd >> >> #ftdi_layout_init first word is initial data level, second is >> direction for direction a "1" is output, "0" is input >> # >> ftdi_layout_init 0x0030 0x1F3b >> ftdi_layout_signal LED -ndata 0x0800 >> ftdi_layout_signal LED2 -ndata 0x1000 >> >> ftdi_layout_signal nTRST -data 0x0010 >> ftdi_layout_signal nSRST -noe 0x0020 >> >> ftdi_layout_signal SWD_EN -data 0x0200 >> >> >> When I try and connect using OpenOCD I get the following errors: >> >> >> C:\Program Files\GNU ARM >> Eclipse\OpenOCD\0.10.0-201601101000-dev\bin>openocd_old.exe -f >> "C:\Program Files\GNU ARM >> Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\interface\ftdi\misfit_swd.cfg" >> -f "C:\Program Files\GNU ARM >> Eclipse\OpenOCD\0.10.0-201601101000-dev\scripts\board\atmel_samd21g18.cfg" >> GNU ARM Eclipse 64-bits Open On-Chip Debugger >> 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:13) >> Licensed under GNU GPL v2 >> For bug reports, read >> http://openocd.org/doc/doxygen/bugs.html >> Info : FTDI SWD mode enabled >> Warn : Interface already configured, ignoring >> none separate >> adapter speed: 400 kHz >> cortex_m reset_config sysresetreq >> Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED >> Error: no device found >> Error: unable to open ftdi device with vid 0403, pid 6010, >> description 'Misfit (Interface 0)' and serial '*' >> >> >> From looking at the code it appears that it looks for the devices >> with matching VID/PID's and then looks for matching description. >> For the FT2232H I think (not confirmed) that there should be >> three devices reported with the same VID/PID (the composite, >> Interface 0, Interface 1). From what I have read the order that >> these devices are parsed is not fixed, ie interface 2 could be >> the first device which would print out the "Error: libusb_open() >> failed with LIBUSB_ERROR_NOT_SUPPORTED" as it does not have >> WinUSB driver. However the code should eventually find the >> correct interface and work, but does not seem to. >> >> I am trying to get the code to build on windows at the moment to >> include more information when the description does not match, it >> seems that on windows the description is not consistent for >> example in Zadig it as shown above, however in device manager it >> is shown as: >> Inline image 5 >> >> I have tried both "Misfit" and "Misfit (Interface 0)", but >> neither works. >> >> I would appreciate any help or suggestions.. Until then I am >> trying to compile under cygwin so I can add more diagnostic >> messages to figure out what is going on. Not the only guides I >> found for compiling on windows are very old, version 0.5, and it >> appears a lot has changed since then. >> >> Thanks >> >> >> On Sun, Jul 31, 2016 at 4:25 PM, Trampas Stern <tr...@gm... >> <mailto:tr...@gm...>> wrote: >> >> I have a FT2232 device I am trying to use where the first >> channel is JTAG and second is used for debug UART. >> >> When I configure the first channel for WinUSB driver OpenOCD >> can not connect. When I configure the parent of the composite >> device to use WinUSB OpenOCD will connect but I loose the >> UART/com port. I was wondering if I am missing something or >> if it is even possible to use the second port on the FT2232 >> with OpenOCD connected to first port? >> >> Thanks >> Trampas >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> OpenOCD-user mailing list >> Ope...@li... >> <mailto:Ope...@li...> >> https://lists.sourceforge.net/lists/listinfo/openocd-user > > > ------------------------------------------------------------------------------ > > _______________________________________________ > OpenOCD-user mailing list > Ope...@li... > <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/openocd-user > > |
|
From: Paul F. <fer...@gm...> - 2016-08-01 15:41:47
|
Hello, On Sun, Jul 31, 2016 at 04:25:31PM -0400, Trampas Stern wrote: > I have a FT2232 device I am trying to use where the first channel is JTAG and > second is used for debug UART. > When I configure the first channel for WinUSB driver OpenOCD can not connect. > When I configure the parent of the composite device to use WinUSB OpenOCD will > connect but I loose the UART/com port. You need to ask libusb windows experts, it's a problem on the layer below OpenOCD, we can't do anything about it, unfortunately. You should probably file a ticket on their issue tracker. This exact combination you described worked nicely with windows xp but somehow more modern versions require replacing driver of composite device parent. Blame microsoft. You might want to consider using a standard operating system instead. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Paul F. <fer...@gm...> - 2016-08-01 15:45:16
|
On Mon, Aug 01, 2016 at 06:41:18PM +0300, Paul Fertser wrote: > You need to ask libusb windows experts, it's a problem on the layer > below OpenOCD, we can't do anything about it, unfortunately. You > should probably file a ticket on their issue tracker. https://github.com/libusb/libusb/issues/85 -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Trampas S. <tr...@gm...> - 2016-08-01 16:28:35
|
OK I found that I had typed the device descriptor incorrectly, which was
one issue.
I am not sure about the "in procedure 'ocd_bouncer'" problems yet.
I found my problems by adding better error logging, I am not sure how to
put into main line code, maybe someone could do this?
The change is:
1. if libusb_open() fails it is not an error all the time, thus changed to
warning and clarified that it can be normal
2. Added warnings for failing on other tests
3. If device fails to open added error indicating possible causes for FTDI
devices.
Here is the snipit of code in the mpsse.c file I changed:
/* Helper to open a libusb device that matches vid, pid, product string
and/or serial string.
* Set any field to 0 as a wildcard. If the device is found true is
returned, with ctx containing
* the already opened handle. ctx->interface must be set to the desired
interface (channel) number
* prior to calling this function. */
static bool open_matching_device(struct mpsse_ctx *ctx, const uint16_t
*vid, const uint16_t *pid,
const char *product, const char *serial, const char *location)
{
libusb_device **list;
struct libusb_device_descriptor desc;
struct libusb_config_descriptor *config0;
int err;
bool found = false;
ssize_t cnt = libusb_get_device_list(ctx->usb_ctx, &list);
if (cnt < 0)
LOG_ERROR("libusb_get_device_list() failed with %s",
libusb_error_name(cnt));
for (ssize_t i = 0; i < cnt; i++) {
libusb_device *device = list[i];
char desc_string[256]={0}; /* Max size of string descriptor */
err = libusb_get_device_descriptor(device, &desc);
if (err != LIBUSB_SUCCESS) {
LOG_ERROR("libusb_get_device_descriptor() failed with %s",
libusb_error_name(err));
continue;
}
if (vid && *vid != desc.idVendor)
continue;
if (pid && *pid != desc.idProduct)
continue;
err = libusb_open(device, &ctx->usb_dev);
if (err != LIBUSB_SUCCESS) {
LOG_WARNING("libusb_open() failed with %s, this can be normal on composite
devices(FT2232 as example)",
libusb_error_name(err));
continue;
}
libusb_get_string_descriptor_ascii(ctx->usb_dev, desc.iProduct, (unsigned
char *)desc_string,
sizeof(desc_string));
if (location && !device_location_equal(device, location)) {
LOG_WARNING("location failed for location %s, actual device description is
\"%s\" ", location,desc_string);
libusb_close(ctx->usb_dev);
continue;
}
if (product && !string_descriptor_equal(ctx->usb_dev, desc.iProduct,
product)) {
LOG_WARNING("descriptor match failed for \"%s\", actual device descriptor
is \"%s\"",product,desc_string);
libusb_close(ctx->usb_dev);
continue;
}
if (serial && !string_descriptor_equal(ctx->usb_dev, desc.iSerialNumber,
serial)) {
LOG_WARNING("serial match failed for \"%s\", actual is
\"%s\"",serial ,desc_string);
libusb_close(ctx->usb_dev);
continue;
}
found = true;
break;
}
libusb_free_device_list(list, 1);
if (!found) {
LOG_ERROR("no device found, see warning messages above");
if (vid && *vid==0x0403)
{
LOG_ERROR("For FTDI devices with multiple interfaces using Windows OS you
need to have WinUSB driver installed for the interface with JTAG connected.
"
"You may also have the ftdi_device_desc or ftdi_channel set wrong for the
device."
" For WinUSB install see Zadig, http://zadig.akeo.ie/, ");
}
libusb_close(ctx->usb_dev);
return false;
}
On Mon, Aug 1, 2016 at 11:44 AM, Paul Fertser <fer...@gm...> wrote:
> On Mon, Aug 01, 2016 at 06:41:18PM +0300, Paul Fertser wrote:
> > You need to ask libusb windows experts, it's a problem on the layer
> > below OpenOCD, we can't do anything about it, unfortunately. You
> > should probably file a ticket on their issue tracker.
>
> https://github.com/libusb/libusb/issues/85
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fer...@gm...
>
|
|
From: Trampas S. <tr...@gm...> - 2016-08-01 18:03:06
|
I ran with more verbose debugging as Juan suggested and got:
Debug: 256 2195 command.c:145 script_debug(): command - ocd_command
ocd_command type ocd_transport init
Debug: 257 2205 command.c:145 script_debug(): command - ocd_transport
ocd_transport init
Debug: 259 2212 transport.c:240 handle_transport_init():
handle_transport_init
Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD
Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued
transactions
Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 =
ffffffff
Debug: 263 2242 command.c:628 run_command(): Command failed with error code
-4
User : 264 2251 command.c:689 command_run_line(): in procedure 'init'
in procedure 'ocd_bouncer'
Debug: 265 2263 command.c:628 run_command(): Command failed with error code
-4
User : 266 2269 command.c:689 command_run_line():
Not sure what is happening I might need to try a reboot...
On Mon, Aug 1, 2016 at 12:28 PM, Trampas Stern <tr...@gm...> wrote:
> OK I found that I had typed the device descriptor incorrectly, which was
> one issue.
>
> I am not sure about the "in procedure 'ocd_bouncer'" problems yet.
>
> I found my problems by adding better error logging, I am not sure how to
> put into main line code, maybe someone could do this?
>
> The change is:
> 1. if libusb_open() fails it is not an error all the time, thus changed to
> warning and clarified that it can be normal
> 2. Added warnings for failing on other tests
> 3. If device fails to open added error indicating possible causes for FTDI
> devices.
>
> Here is the snipit of code in the mpsse.c file I changed:
>
>
> /* Helper to open a libusb device that matches vid, pid, product string
> and/or serial string.
> * Set any field to 0 as a wildcard. If the device is found true is
> returned, with ctx containing
> * the already opened handle. ctx->interface must be set to the desired
> interface (channel) number
> * prior to calling this function. */
> static bool open_matching_device(struct mpsse_ctx *ctx, const uint16_t
> *vid, const uint16_t *pid,
> const char *product, const char *serial, const char *location)
> {
> libusb_device **list;
> struct libusb_device_descriptor desc;
> struct libusb_config_descriptor *config0;
> int err;
> bool found = false;
> ssize_t cnt = libusb_get_device_list(ctx->usb_ctx, &list);
> if (cnt < 0)
> LOG_ERROR("libusb_get_device_list() failed with %s",
> libusb_error_name(cnt));
>
> for (ssize_t i = 0; i < cnt; i++) {
> libusb_device *device = list[i];
>
> char desc_string[256]={0}; /* Max size of string descriptor */
>
> err = libusb_get_device_descriptor(device, &desc);
> if (err != LIBUSB_SUCCESS) {
> LOG_ERROR("libusb_get_device_descriptor() failed with %s",
> libusb_error_name(err));
> continue;
> }
>
> if (vid && *vid != desc.idVendor)
> continue;
> if (pid && *pid != desc.idProduct)
> continue;
>
>
> err = libusb_open(device, &ctx->usb_dev);
>
> if (err != LIBUSB_SUCCESS) {
> LOG_WARNING("libusb_open() failed with %s, this can be normal on composite
> devices(FT2232 as example)",
> libusb_error_name(err));
> continue;
> }
>
> libusb_get_string_descriptor_ascii(ctx->usb_dev, desc.iProduct, (unsigned
> char *)desc_string,
> sizeof(desc_string));
> if (location && !device_location_equal(device, location)) {
> LOG_WARNING("location failed for location %s, actual device description is
> \"%s\" ", location,desc_string);
> libusb_close(ctx->usb_dev);
> continue;
> }
>
> if (product && !string_descriptor_equal(ctx->usb_dev, desc.iProduct,
> product)) {
> LOG_WARNING("descriptor match failed for \"%s\", actual device descriptor
> is \"%s\"",product,desc_string);
> libusb_close(ctx->usb_dev);
> continue;
> }
>
> if (serial && !string_descriptor_equal(ctx->usb_dev, desc.iSerialNumber,
> serial)) {
> LOG_WARNING("serial match failed for \"%s\", actual is
> \"%s\"",serial ,desc_string);
> libusb_close(ctx->usb_dev);
> continue;
> }
>
> found = true;
> break;
> }
>
> libusb_free_device_list(list, 1);
>
> if (!found) {
> LOG_ERROR("no device found, see warning messages above");
> if (vid && *vid==0x0403)
> {
> LOG_ERROR("For FTDI devices with multiple interfaces using Windows OS
> you need to have WinUSB driver installed for the interface with JTAG
> connected. "
> "You may also have the ftdi_device_desc or ftdi_channel set wrong for the
> device."
> " For WinUSB install see Zadig, http://zadig.akeo.ie/, ");
> }
> libusb_close(ctx->usb_dev);
> return false;
> }
>
>
>
> On Mon, Aug 1, 2016 at 11:44 AM, Paul Fertser <fer...@gm...> wrote:
>
>> On Mon, Aug 01, 2016 at 06:41:18PM +0300, Paul Fertser wrote:
>> > You need to ask libusb windows experts, it's a problem on the layer
>> > below OpenOCD, we can't do anything about it, unfortunately. You
>> > should probably file a ticket on their issue tracker.
>>
>> https://github.com/libusb/libusb/issues/85
>>
>> --
>> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
>> mailto:fer...@gm...
>>
>
>
|
|
From: Paul F. <fer...@gm...> - 2016-08-01 20:10:51
|
On Mon, Aug 01, 2016 at 02:02:59PM -0400, Trampas Stern wrote: > Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD > Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued transactions > Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 = ffffffff This looks like hardware issue, SWD just doesn't work properly for you, the target doesn't respond at all. How is your debug adapter supposed to handle SWD specifics? Regarding your libusb issues, can you please clarify what OS version you're using, whether or not you succeeded to get the cited output with WinUSB just for a single interface and regular FTDI VCOM driver for the other, and can you please show the exact modification that made it work in diff -u form? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Trampas S. <tr...@gm...> - 2016-08-01 20:37:26
|
The libusb issue is resolved. Issue was I defined descriptor in config file that did not match the driver. The adapter I have uses tristate drivers to switch the signals for SWD. I moved adapter to a JTAG board and it is not working there either. I am debugging hardware now... I have checked pin out but have not found an issue, I will scope the signals next... On Aug 1, 2016 4:10 PM, "Paul Fertser" <fer...@gm...> wrote: > On Mon, Aug 01, 2016 at 02:02:59PM -0400, Trampas Stern wrote: > > Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD > > Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued > transactions > > Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 = > ffffffff > > This looks like hardware issue, SWD just doesn't work properly for > you, the target doesn't respond at all. How is your debug adapter > supposed to handle SWD specifics? > > Regarding your libusb issues, can you please clarify what OS version > you're using, whether or not you succeeded to get the cited output > with WinUSB just for a single interface and regular FTDI VCOM driver > for the other, and can you please show the exact modification that > made it work in diff -u form? > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fer...@gm... > |
|
From: Xiaofan C. <xia...@gm...> - 2016-08-04 12:59:50
|
On Tue, Aug 2, 2016 at 4:37 AM, Trampas Stern <tr...@gm...> wrote: > The libusb issue is resolved. Issue was I defined descriptor in config file > that did not match the driver. > Thanks. So this is not a libusb issue after all. -- Xiaofan |
|
From: Trampas S. <tr...@gm...> - 2016-08-01 20:38:52
|
The added error logging in the code snippet pointed out my descriptor issue rather quickly... On Aug 1, 2016 4:37 PM, "Trampas Stern" <tr...@gm...> wrote: > The libusb issue is resolved. Issue was I defined descriptor in config > file that did not match the driver. > > The adapter I have uses tristate drivers to switch the signals for SWD. I > moved adapter to a JTAG board and it is not working there either. I am > debugging hardware now... > > I have checked pin out but have not found an issue, I will scope the > signals next... > > On Aug 1, 2016 4:10 PM, "Paul Fertser" <fer...@gm...> wrote: > >> On Mon, Aug 01, 2016 at 02:02:59PM -0400, Trampas Stern wrote: >> > Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD >> > Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued >> transactions >> > Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 = >> ffffffff >> >> This looks like hardware issue, SWD just doesn't work properly for >> you, the target doesn't respond at all. How is your debug adapter >> supposed to handle SWD specifics? >> >> Regarding your libusb issues, can you please clarify what OS version >> you're using, whether or not you succeeded to get the cited output >> with WinUSB just for a single interface and regular FTDI VCOM driver >> for the other, and can you please show the exact modification that >> made it work in diff -u form? >> >> -- >> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! >> mailto:fer...@gm... >> > |
|
From: Trampas S. <tr...@gm...> - 2016-08-01 23:31:49
|
I am not getting a reset signal before the TCLK is clocking, I think the reset has to occur. Here is my configuration file, as much as I change this the SWD does not toggle the reset. If I change the state in the init it will change the pin level, I have unplugged the debug hardware and the reset does not change unless I change the ftdi_layout_init, am I missing something? Note my reset is on ACBUS0 which I think is bit #8, ie 0x0100 Configuration file. interface ftdi #ftdi_device_desc "Misfit" ftdi_vid_pid 0x0403 0x6010 #ftdi_channel 0 transport select swd #ftdi_layout_init first word is initial data level, second is direction for direction a "1" is output, "0" is input # ftdi_layout_init 0x0130 0x1F3b ftdi_layout_signal nSRST -data 0x0100 ftdi_layout_signal LED -ndata 0x0800 ftdi_layout_signal LED2 -ndata 0x1000 ftdi_layout_signal nTRST -data 0x0010 ftdi_layout_signal SWD_EN -data 0x0200 On Mon, Aug 1, 2016 at 4:38 PM, Trampas Stern <tr...@gm...> wrote: > The added error logging in the code snippet pointed out my descriptor > issue rather quickly... > > On Aug 1, 2016 4:37 PM, "Trampas Stern" <tr...@gm...> wrote: > >> The libusb issue is resolved. Issue was I defined descriptor in config >> file that did not match the driver. >> >> The adapter I have uses tristate drivers to switch the signals for SWD. I >> moved adapter to a JTAG board and it is not working there either. I am >> debugging hardware now... >> >> I have checked pin out but have not found an issue, I will scope the >> signals next... >> >> On Aug 1, 2016 4:10 PM, "Paul Fertser" <fer...@gm...> wrote: >> >>> On Mon, Aug 01, 2016 at 02:02:59PM -0400, Trampas Stern wrote: >>> > Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD >>> > Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued >>> transactions >>> > Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 = >>> ffffffff >>> >>> This looks like hardware issue, SWD just doesn't work properly for >>> you, the target doesn't respond at all. How is your debug adapter >>> supposed to handle SWD specifics? >>> >>> Regarding your libusb issues, can you please clarify what OS version >>> you're using, whether or not you succeeded to get the cited output >>> with WinUSB just for a single interface and regular FTDI VCOM driver >>> for the other, and can you please show the exact modification that >>> made it work in diff -u form? >>> >>> -- >>> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! >>> mailto:fer...@gm... >>> >> |
|
From: Juan C. <jce...@nu...> - 2016-08-01 23:31:46
|
Yes, it now appears like a HW problem or swd config problem, but not an openocd or FTDI issue. El 1 de agosto de 2016 5:37:19 PM GMT-03:00, Trampas Stern <tr...@gm...> escribió: >The libusb issue is resolved. Issue was I defined descriptor in config >file >that did not match the driver. > >The adapter I have uses tristate drivers to switch the signals for SWD. >I >moved adapter to a JTAG board and it is not working there either. I am >debugging hardware now... > >I have checked pin out but have not found an issue, I will scope the >signals next... > >On Aug 1, 2016 4:10 PM, "Paul Fertser" <fer...@gm...> wrote: > >> On Mon, Aug 01, 2016 at 02:02:59PM -0400, Trampas Stern wrote: >> > Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD >> > Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued >> transactions >> > Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 >= >> ffffffff >> >> This looks like hardware issue, SWD just doesn't work properly for >> you, the target doesn't respond at all. How is your debug adapter >> supposed to handle SWD specifics? >> >> Regarding your libusb issues, can you please clarify what OS version >> you're using, whether or not you succeeded to get the cited output >> with WinUSB just for a single interface and regular FTDI VCOM driver >> for the other, and can you please show the exact modification that >> made it work in diff -u form? >> >> -- >> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) >software! >> mailto:fer...@gm... >> > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ > > >------------------------------------------------------------------------ > >_______________________________________________ >OpenOCD-user mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openocd-user |
|
From: Trampas S. <tr...@gm...> - 2016-08-01 23:49:02
Attachments:
image.png
|
Yea, I will build up another board and test it... Here is the logic analyzer of the signals... [image: Inline image 1] On Mon, Aug 1, 2016 at 7:31 PM, Juan Cecconi <jce...@nu...> wrote: > Yes, it now appears like a HW problem or swd config problem, but not an > openocd or FTDI issue. > > > > El 1 de agosto de 2016 5:37:19 PM GMT-03:00, Trampas Stern < > tr...@gm...> escribió: > >> The libusb issue is resolved. Issue was I defined descriptor in config >> file that did not match the driver. >> >> The adapter I have uses tristate drivers to switch the signals for SWD. I >> moved adapter to a JTAG board and it is not working there either. I am >> debugging hardware now... >> >> I have checked pin out but have not found an issue, I will scope the >> signals next... >> >> On Aug 1, 2016 4:10 PM, "Paul Fertser" <fer...@gm...> wrote: >> >>> On Mon, Aug 01, 2016 at 02:02:59PM -0400, Trampas Stern wrote: >>> > Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD >>> > Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued >>> transactions >>> > Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 = >>> ffffffff >>> >>> This looks like hardware issue, SWD just doesn't work properly for >>> you, the target doesn't respond at all. How is your debug adapter >>> supposed to handle SWD specifics? >>> >>> Regarding your libusb issues, can you please clarify what OS version >>> you're using, whether or not you succeeded to get the cited output >>> with WinUSB just for a single interface and regular FTDI VCOM driver >>> for the other, and can you please show the exact modification that >>> made it work in diff -u form? >>> >>> -- >>> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! >>> mailto:fer...@gm... >>> >> ------------------------------ >> >> ------------------------------ >> >> OpenOCD-user mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openocd-user >> >> |
|
From: Trampas S. <tr...@gm...> - 2016-08-02 17:14:03
Attachments:
image.png
|
I have it all working now... I was a bit confused on the SWD, and how to connect TDO/TDI with TMS signal. However after reading about SWD I realized the SWDIO is bidirectional bus and the adapter should have an open collector driver to pull down, where I was doing a push/pull. The resistor hack is basically a hack, but would be better if a Schottky diode was used with a pull up resistor. This would simulate the TDI being an open collector driver and only pulling down the SWDIO. Also for some hardware the debugger should have a pull up on the SWDIO. Thanks to everyone for their help! I will be updating my schematics and open sourcing the hardware design. The current design supports JTAG and SWD for 3.3V I am also working on an isolated version that will support JTAG and SWD for 0.9V to 3.3V. I would like to include an INF file for automatically installing the WinUSB driver, if someone has examples of how to do this I would love to get the information. Thanks again Trampas On Mon, Aug 1, 2016 at 7:48 PM, Trampas Stern <tr...@gm...> wrote: > Yea, I will build up another board and test it... > > Here is the logic analyzer of the signals... > > [image: Inline image 1] > > On Mon, Aug 1, 2016 at 7:31 PM, Juan Cecconi <jce...@nu...> > wrote: > >> Yes, it now appears like a HW problem or swd config problem, but not an >> openocd or FTDI issue. >> >> >> >> El 1 de agosto de 2016 5:37:19 PM GMT-03:00, Trampas Stern < >> tr...@gm...> escribió: >> >>> The libusb issue is resolved. Issue was I defined descriptor in config >>> file that did not match the driver. >>> >>> The adapter I have uses tristate drivers to switch the signals for SWD. >>> I moved adapter to a JTAG board and it is not working there either. I am >>> debugging hardware now... >>> >>> I have checked pin out but have not found an issue, I will scope the >>> signals next... >>> >>> On Aug 1, 2016 4:10 PM, "Paul Fertser" <fer...@gm...> wrote: >>> >>>> On Mon, Aug 01, 2016 at 02:02:59PM -0400, Trampas Stern wrote: >>>> > Debug: 260 2219 ftdi.c:1092 ftdi_swd_switch_seq(): JTAG-to-SWD >>>> > Debug: 261 2225 ftdi.c:946 ftdi_swd_run_queue(): Executing 2 queued >>>> transactions >>>> > Debug: 262 2235 ftdi.c:978 ftdi_swd_run_queue(): JUNK DP read reg 0 = >>>> ffffffff >>>> >>>> This looks like hardware issue, SWD just doesn't work properly for >>>> you, the target doesn't respond at all. How is your debug adapter >>>> supposed to handle SWD specifics? >>>> >>>> Regarding your libusb issues, can you please clarify what OS version >>>> you're using, whether or not you succeeded to get the cited output >>>> with WinUSB just for a single interface and regular FTDI VCOM driver >>>> for the other, and can you please show the exact modification that >>>> made it work in diff -u form? >>>> >>>> -- >>>> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) >>>> software! >>>> mailto:fer...@gm... >>>> >>> ------------------------------ >>> >>> ------------------------------ >>> >>> OpenOCD-user mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openocd-user >>> >>> > |
|
From: Tomas V. <to...@us...> - 2016-08-02 19:32:36
|
On 02.08.2016 19:13, Trampas Stern wrote: > The resistor hack is basically a hack, but would be better if a > Schottky diode was used with a pull up resistor. This would simulate > the TDI being an open collector driver and only pulling down the > SWDIO. Also for some hardware the debugger should have a pull up on > the SWDIO. Certainly not. Pull up on SWDIO is really weak, just to prevent line floating. Asymmetric drive of open collector with the capacity of a cable would have much steeper failing slope than rising - this would limit reachable frequency. If you don't want to use a hack, you should connect a 3-state driver from TDI output to SWDIO and configure a FT2232 pin as a signal to enable it. See kt-link.cfg. Tomas |
|
From: Trampas S. <tr...@gm...> - 2016-08-02 19:45:09
|
I did use a tri-state driver to pull the SWDIO low. I also added a 10k pull up on the TMS/SWDIO as that even with tri-state the SWDIO on the hardware I was using was too week. On Tue, Aug 2, 2016 at 3:32 PM, Tomas Vanek <to...@us...> wrote: > On 02.08.2016 19:13, Trampas Stern wrote: > >> The resistor hack is basically a hack, but would be better if a Schottky >> diode was used with a pull up resistor. This would simulate the TDI being >> an open collector driver and only pulling down the SWDIO. Also for some >> hardware the debugger should have a pull up on the SWDIO. >> > Certainly not. Pull up on SWDIO is really weak, just to prevent line > floating. Asymmetric drive of open collector with the capacity of a cable > would have much steeper failing slope than rising - this would limit > reachable frequency. > > If you don't want to use a hack, you should connect a 3-state driver from > TDI output to SWDIO and configure a FT2232 pin as a signal to enable it. > See kt-link.cfg. > > Tomas > > |
|
From: Trampas S. <tr...@gm...> - 2016-08-02 20:11:53
|
Thanks ! What is the cfg file for the dangerousprototypes design/layout? On Tue, Aug 2, 2016 at 4:04 PM, Tomas Vanek <to...@us...> wrote: > Pulling SWDIO to low only is wrong, you should use push-pull for output > and hi-z for input. > SWDIO is not an open collector, it is a real bidirectional line. > See http://dangerousprototypes.com/forum/viewtopic.php?t=2001 > > > On 02.08.2016 21:45, Trampas Stern wrote: > > I did use a tri-state driver to pull the SWDIO low. > > I also added a 10k pull up on the TMS/SWDIO as that even with tri-state > the SWDIO on the hardware I was using was too week. > > > > On Tue, Aug 2, 2016 at 3:32 PM, Tomas Vanek <to...@us... > > wrote: > >> On 02.08.2016 19:13, Trampas Stern wrote: >> >>> The resistor hack is basically a hack, but would be better if a Schottky >>> diode was used with a pull up resistor. This would simulate the TDI being >>> an open collector driver and only pulling down the SWDIO. Also for some >>> hardware the debugger should have a pull up on the SWDIO. >>> >> Certainly not. Pull up on SWDIO is really weak, just to prevent line >> floating. Asymmetric drive of open collector with the capacity of a cable >> would have much steeper failing slope than rising - this would limit >> reachable frequency. >> >> If you don't want to use a hack, you should connect a 3-state driver from >> TDI output to SWDIO and configure a FT2232 pin as a signal to enable it. >> See kt-link.cfg. >> >> Tomas >> >> > > |
|
From: Xiaofan C. <xia...@gm...> - 2016-08-04 12:58:05
|
On Mon, Aug 1, 2016 at 11:44 PM, Paul Fertser <fer...@gm...> wrote: > On Mon, Aug 01, 2016 at 06:41:18PM +0300, Paul Fertser wrote: >> You need to ask libusb windows experts, it's a problem on the layer >> below OpenOCD, we can't do anything about it, unfortunately. You >> should probably file a ticket on their issue tracker. > > https://github.com/libusb/libusb/issues/85 > That is very specific to certain class of USB device with IAD which has nothing to do with FT2232 based device (not using IAD). So this seems to have nothing to do with libusb. Most likely the OP does not use Zadig properly. Zadig can install WinUSB driver to Interface 0 (for JTAG) and keep Interface 1 (for UART) using the vendor driver. -- Xiaofan |
|
From: Paul F. <fer...@gm...> - 2016-08-04 13:07:42
|
Hello Xiaofan, On Thu, Aug 04, 2016 at 08:57:58PM +0800, Xiaofan Chen wrote: > > https://github.com/libusb/libusb/issues/85 > > > > That is very specific to certain class of USB device with IAD > which has nothing to do with FT2232 based device (not using > IAD). Thank you for the clarifications! I was afraid you do not read -user ML so did a quick internet search without digging enough to understand what exactly this was about, sorry for misinformation. I think I've read some reports about issues with FTDI parts on newer windows versions when composite parent is not replaced with WinUSB but now I'm not so sure it was actually the case. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X