On Wed, May 9, 2012 at 4:10 PM, Xiaofan Chen <[email protected]> wrote:
> On Wed, May 9, 2012 at 9:11 PM, Andreas Fritiofson
> <[email protected]> wrote:
>>
>> "Great", that's the type of feedback I need. The config file layouts
>> are a bit of a guesswork from my side, so they may be wrong for
>> luminary. I've tested with jtagkey.cfg, olimex-arm-usb-ocd.cfg and
>> olimex-arm-usb-ocd-h.cfg. Do you have access to any of these or
>> another adapter? Just to determine if the config or the code is to
>> blame.
>>
>> Can you send a -d3 debug log?
>
> With the on-board TI/Luminary debugger.
>
> mymacmini:lm3s1968 xiaofanc$ ~/bin/bin/openocd -d3 -f
> board/ek-lm3s1968_mpsse_icdi.cfg
> Open On-Chip Debugger 0.6.0-dev-00448-gac053a2 (2012-05-09-19:01)

> ocd_command type ocd_ftdi_vid_pid 0x0403 0xbcd9
> Debug: 59 4 command.c:147 script_debug(): command - ftdi_vid_pid
> ocd_ftdi_vid_pid 0x0403 0xbcd9
> Debug: 61 4 command.c:147 script_debug(): command - ocd_command
> ocd_command type ocd_ftdi_layout_init 0x0088 0x00cb
> Debug: 62 4 command.c:147 script_debug(): command - ftdi_layout_init
> ocd_ftdi_layout_init 0x0088 0x00cb
> Debug: 64 4 command.c:147 script_debug(): command - ocd_command
> ocd_command type ocd_ftdi_layout_signal nSRST -data 0x0020 -oe 0x0020
> Debug: 65 4 command.c:147 script_debug(): command - ftdi_layout_signal
> ocd_ftdi_layout_signal nSRST -data 0x0020 -oe 0x0020

> lm3s1968.cpu tap/device found: 0xffffffff (mfg: 0x7ff, part: 0xffff,
> ver: 0xf)
> Warn : 244 556 core.c:910 jtag_examine_chain_display(): JTAG tap:
> lm3s1968.cpu       UNEXPECTED: 0xffffffff (mfg: 0x7ff, part: 0xffff,
> ver: 0xf)
> Error: 245 556 core.c:910 jtag_examine_chain_display(): JTAG tap:
> lm3s1968.cpu  expected 1 of 1: 0x0ba00477 (mfg: 0x23b, part: 0xba00,
> ver: 0x0)
> Warn : 246 556 core.c:947 jtag_examine_chain_end(): Unexpected idcode
> after end of chain: 608 0x7fffffff
> Error: 247 556 core.c:1115 jtag_examine_chain(): double-check your
> JTAG setup (interface, speed, missing TAPs, ...)

Using the built-in adapter, you only get ones, but with the external
adapter you can at least read the idcode correctly. I've taken a look
at the schematics of the EK-LM3S1968 board and it seems like the I/O
config and init in interface/ftdi/luminary{,_icdi}.cfg is wrong. It
initializes SRSTN (FT2232 ADBUS5) as an input which makes the internal
signal between the FT2232 and the CPLD floating. Also, it uses the
FTDI pin as an open-drain output as if it directly controls target
nSRST even though it's buffered with a CPLD. Strangely, the layout
code in the old driver does the same thing, that's where I copied the
info from. Can you try the attached luminary.cfg to see if you can at
least read the idcode?

/Andreas

Attachment: luminary.cfg
Description: Binary data

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to