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"
