Hi David,
I am using my Linux PC mith an onboard parport and an additional ISA
parport card. If you are working on Linux You can
- open four xterms (or if you do not need the debug output of
msp430-gdbproxy three)
- on xterm1: msp430-gdbproxy -port=2000 msp430 /dev/parport0 (which is
the default)
- on xterm2: msp430-gdbproxy -port=2001 msp430 /dev/parport1
- on xterm3: msp430-gdb ...
target remote localhost:2000
...
- on xterm4: msp430-gdb ...
target remote localhost:2001
...
I am using an Olimex MSP430 Parport-JTAG dongle with an msp430fg439
running suse-linux on an old 233MHz Celeron with 128MB RAM and it works
without any problems.
Have a nice day
Arnd-Hendrik
David Brown wrote:
Has anyone had success using LPT2 (on windows - or, for curiosity's sake at
the moment, on linux) for debugging or programming, using parallel port jtag
interfaces? I regularly use msp430-jtag for programming and msp430-gdbproxy
while debugging, normally using the first parallel port. But at the moment
I am working on a system involving two msp430 cards which should communicate
over a serial link, and it would be really nice to be able to debug both at
once. msp430-jtag has a flag "-l2" or "--lpt=LPT2", but I can't get it to
work - I get the same "An error occured: Can't open interface" error as I
would when there is no contact with the msp430 (for example, if the power
supply is switched off). I can't see any flags for msp430-gdbproxy relating
to the parallel port.
Having wandered around the sourceforge cvs repository, I have found the
source of the problem with msp430-jtag, but I'm not sure about the best way
to deal with it. In the file mspgcc/jtag/hardware_access/HIL.c function
HIL_Initialize, the LPT port addresses are hard-coded to [0, 0x378, 0x278,
0x3bc], which are standard for ancient ISA card lpt cards. PCI cards, such
as mine, invariably use different addresses (mine happens to be at 0xb000).
So I downloaded the HIL source code, edited the addresses to [0, 0x378,
0xb000, 0x3bc] and re-build HIL.dll using cygwin gcc. I then replaced the
HIL.dll in the mspgcc\bin directory (using the pre-built windows binaries
that I downloaded a few months ago) with my modified version.
Unfortunately, this made no difference to msp430-jtag - nor did removing the
original HIL.dll entirely. It looks like the binaries (most likely
msp430mspgcc.dll ?) are have the HIL.c functions staticly linked. While
this is not entirely a dead-end for me (I could re-build the other binaries
too), it is getting beyond what I can do at the moment, and at best it would
leave me with a specificly patched jtag download of no use to anyone else,
and with no debugging.
To get much further, this is going to need at least some work by "the powers
that be". While I might be able to hack together a specific downloader
binary for myself, to be of use to others it is going to need configurable
addresses rather than fixed ones, support for Linux and FreeBSD, and support
in gdbproxy, which are all beyond me at the moment. I don't know whether
this is a big issue - maybe I'm the only one looking for the feature. If
USB-based debugging takes off, there will no longer be the same problem, as
support for multiple debuggers will be more natural there.
David Brown
System Developer
WestControl a.s
Norway
"Utvikling er kunsten av å vikle seg ut av det man har viklet seg inn i"
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&opÌk
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
