>
>
>I'm trying to embed a FT2232D based programmer into my board with a STM32
>(Cortex-M3 MCU).
>
>I want the programmer to be compatible with jtagkey, so I looked at schematics
>of compaible designs.
>
>I noticed that while the JTAG signals (TCK, TDI, TDO, T
The best is to standardize at a lower level ... and to forget the idea to have
the possibility to bitbang from the TCL of the openocd.
>
>That's as for the SWD, we have to standardize some function call in the
>ft2232, and avoiding bitbang access from higher-level.
>
>That's not simple to dev
>
>My objective is not to block feature.Never,never,never ... But we have
>to avoid any trouble in generic ft2232 driver regarding specific layout.
>That's all.
>Your TCL bitbang will control the port of the FTDI from an higher level
>than FT2232.c. OK but you T
(Resending since I forgot to cc the list)
There is at least one useful end-user use case for bitbanging. There
are many IO lines unused on the FTDI port that can be used for GPIO.
Some dongles expose these and of course a custom FTDI interface that you
integrate with your prototype can expos
Thanks - I tried that, it recognizes the correct amount of sections and
>their sizes in the ihex file but not the base address - I am getting
>random values when reading the base_address member in the struct
>"imagesection".
>
>Am I supposed to read the section address from that variable or is th
>
>
>Another way would be to implement a minimalistic Intel HEX parser in the
>ULINK driver or in a separate C module.
>
>If you are looking for an Intel HEX parser, look in targets/image.c. There it
>parses Intel Hex, ELF, and Srec files.
Phil___
> Ah, this'll probably be my fault, and it's not intentional must be
> something I missed when I modified the verbose stuff late last year.
> I've only been using the svf command to program my actel fpga with an
> auto-generated svf file, and haven't noticed this issue, either
> because I don
I've been programming Lattice XP2 FPGAs with SVF using a git checkout from the
beginning of February. (So, to answer Oyvind svf at least partially works.)
However, I've noticed that the echo to the screen does not echo the first line
of SDR commands. The SVF has SDR commands of the form:
SDR
>
> you can try configure with "--enable-verbose-jtag-io". All the jtag
> input/output is done in interface.c.
>
I'm assuming this will help us see what is shifted in during the irscan
commands.
Any ideas on how to configure OpenOCD to handle the tap switching? Our current
method does not h
After some experimenting with building the right cable and generating an
appropriate SVF file, I was able to program a Lattice XP2 using OpenOCD and a
Signalyzer-H2. Since I also have a jlink, I figured why not give that a shot.
It seems that the jlink does not have the JTAG_STABLECLOCKS jtag c
Hi,
I've been working on Rodrigo on adding support to flash Freescale dsp56800e
devices and have been looking at the dsp563xx code. I think the define for the
JTAG CLAMP instruction in dsp563xx_once.c is incorrect. It should be 0x05
according the Freescale AN2074 (and is also 0x05 in the dsp
I have a Freescale 56F8013 which is a DSC from the DSP56800E family that I want
to flash. I am planning on connecting a FTDI FT2232H to the JTAG pins and wish
to flash it.
Freescale provides documentation as to the TAP and ON/CE commands needed to
program the flash
(http://cache.freescale.com
I have had some success with Code::Blocks on Windows. On Linux it works fine.
On Windows there are a few annoyances. The main one is how to halt remote
targets. With OpenOCD I do it through the telnet interface. See the
discussion
at http://forums.codeblocks.org/index.php/topic,12412.0.htm
I have found some situations where single step with next in GDB with OpenOCD on
a LPC3220 (uses lpc3250.cfg with modification of core ID and memory size), does
not work. Whenever I reach a certain line while single stepping, OpenOCD
prints
out "Error: Unable to set 32 bit software breakpoint
14 matches
Mail list logo
