I've posted here a couple of times about my problems using
IAR Kickstart with the LaunchPad and other devices, when
running on my Win7 Ultimate 64-bit machine. I do work hard to
keep it fairly clean (it's my work machine and although I
keep all of the Microsoft updates rather up-to-date, I don't
install much by way of 3rd party software on it and I block a
lot of web stuff and ensure that no admin privileges can be
done without my express permission (so far as I'm aware, the
settings I use guarantee that.) No one else uses the machine
for any other purpose, as well.
Despite that, I found it almost impossible to connect with
any of the many LaunchPad boards I've tried (and eZ430 and so
on.) Except once in a rare while. Intermittent, yes. But far
too infrequent. So I switched over to CCS for a trial with
that, because it appeared to work better. (And it does work
better.)
However, I did continue to run into problems as I used CCS
more. Similar messages about not being able to connect. These
were less frequent and one of the solutions was to disconnect
the board, close the IDE, connect the board, then restart the
IDE (which then appeared to rediscover the board.) But it
made me look further.
What I seem to have found is that a driver I use (Daemon
Tools Lite) for allowing me to mount ISO files as virtual
disks was the problem in my case. Removing it appears to have
solved the IAR connection problem.
It's my guess that IAR and CCS coders use the DLL from TI for
accessing the board and that solving this problem with Daemon
Tools Lite may not be much of a priority for TI or anyone
else. Chances are, IAR and CCS folks wrote slightly different
code accessing the DLL and that this explains what difference
I see in behavior (somewhat better success with CCS in
downloading code more consistently.) But the real culprit
appears to be an interaction between the TI DLL and Daemon
Tools (Lite and probably their Pro version, as well.)
Just a note to anyone who may be using that tool. So far,
without Daemon Tools running on the machine, everything seems
to work just fine today with IAR.
Jon
IAR kickstart problems and Win7 64-bit resolved, I think.
Started by ●January 11, 2013
Reply by ●January 12, 20132013-01-12
Hello,Jon.
Yes, W7 64bits didn't work for me at all when working with msp's launchpad
- drivers could not be installed correctly. Consequently, i could not
program the device. To overcome this, i simply used my jtag to program the
launchpad as 2-wire protocol. Really simple and works.
Using this as reference
http://processors.wiki.ti.com/index.php/JTAG_(figure2) and taking care
to keep the capacitance lower than the specified (or
egual. in the limit) works fine with IAR (tested and ok) and should work to
with CCS (not tested).
Regards
Fero
Yes, W7 64bits didn't work for me at all when working with msp's launchpad
- drivers could not be installed correctly. Consequently, i could not
program the device. To overcome this, i simply used my jtag to program the
launchpad as 2-wire protocol. Really simple and works.
Using this as reference
http://processors.wiki.ti.com/index.php/JTAG_(figure2) and taking care
to keep the capacitance lower than the specified (or
egual. in the limit) works fine with IAR (tested and ok) and should work to
with CCS (not tested).
Regards
Fero
Reply by ●January 12, 20132013-01-12
Everything is working just fine, now, without using anything
special. Part of my reason for posting as I did is because
I'd been "complaining" earlier about difficulties I'd had but
where I really didn't know why I was having them.
As it turns out, like often is the case, it's about software
conflicts. Without expensive and specialized tools or very
specialized Windows knowledge and some development time,
these conflicts can be pretty hard to track down. I happened
to get lucky and figured I'd post about it so that if someone
else were in the same boat, they could at least try what I'd
tried. I wanted also to make some amends for being ignorant
before about what was causing problems at my end.
Linking to what you provided below:
http://processors.wiki.ti.com/index.php/JTAG_(figure2)
gives me this,
"There is currently no text in this page. You can search for
this page title in other pages, or search the related logs."
Perhaps the link has a mistake?
Jon
special. Part of my reason for posting as I did is because
I'd been "complaining" earlier about difficulties I'd had but
where I really didn't know why I was having them.
As it turns out, like often is the case, it's about software
conflicts. Without expensive and specialized tools or very
specialized Windows knowledge and some development time,
these conflicts can be pretty hard to track down. I happened
to get lucky and figured I'd post about it so that if someone
else were in the same boat, they could at least try what I'd
tried. I wanted also to make some amends for being ignorant
before about what was causing problems at my end.
Linking to what you provided below:
http://processors.wiki.ti.com/index.php/JTAG_(figure2)
gives me this,
"There is currently no text in this page. You can search for
this page title in other pages, or search the related logs."
Perhaps the link has a mistake?
Jon
Reply by ●January 12, 20132013-01-12
Hey, John, sry
Here it goes:
http://processors.wiki.ti.com/index.php/JTAG_(MSP430)
- the (MSP430) is a part of the link.
- Figure 2 is the one i used!
Regards!
Here it goes:
http://processors.wiki.ti.com/index.php/JTAG_(MSP430)
- the (MSP430) is a part of the link.
- Figure 2 is the one i used!
Regards!
Reply by ●January 12, 20132013-01-12
On Sat, 12 Jan 2013 22:08:55 -0200, you wrote:
>Hey, John, sry
>
>Here it goes:
>
>http://processors.wiki.ti.com/index.php/JTAG_(MSP430)
>
>- the (MSP430) is a part of the link.
>- Figure 2 is the one i used!
>
>Regards!
Ah. Before I ask a few questions, let me say that I'm pretty
sure that TI got the JTAG hardware right on the LaunchPad.
I was using the IAR toolset and the "download and debug"
option underneath the Project menu option to transmit the
code. While other tools could be used, I currently think the
actual problem has to do with a conflict between the JTAG DLL
that is commonly used (and supplied by TI, I think) by
various vendors AND the Daemon Tools product. There may be
other such conflicts, as well.
Having removed the Daemon Tools product from the active
processes appears to have improved things quite well. I can
still use Daemon Tools when I care to, but just not at the
same time as I use the TI DLL for programming devices.
In short, it works now and I can reproduce the problem when I
want to, as well. It's all software.
That said, I am perhaps confused. I think you are suggesting
that a 2-wire Spy-Bi-Wire interface would fix things. From
that, it seems you imagine that the LaunchPad isn't using a
2-wire interface. But I'm using the MSP430F2001 and
MSP430F2231, for example. And I think those chips ONLY
support 2-wire Spy-Bi-Wire methods. So going to the trouble
of duplicating such hardware wouldn't help. However, perhaps
writing my own software (or using still another package)
would, because I could reference SLAU320G and write code to
do that, I suppose. (Though I think I'd need to pull jumpers
from the LaunchPad for that.)
Is that what you were thinking? Different software driver and
pulling the LaunchPad jumpers to allow access to the JTAG
pins on the MSP430F2001, for example?
I'd like all this to work for other students and to avoid
difficulties, such as more 3rd party downloads than
absolutely necessary, or having to do too much extra hardware
work, as well.
Anyway, I seem to have found a problem on my machine (and on
someone else's, by the way, who also happened to use Daemon
Tools.) So that's good enough for now.
Let me know if I understood you correctly, or let me know
where I went wrong.
And thanks,
Jon
>Hey, John, sry
>
>Here it goes:
>
>http://processors.wiki.ti.com/index.php/JTAG_(MSP430)
>
>- the (MSP430) is a part of the link.
>- Figure 2 is the one i used!
>
>Regards!
Ah. Before I ask a few questions, let me say that I'm pretty
sure that TI got the JTAG hardware right on the LaunchPad.
I was using the IAR toolset and the "download and debug"
option underneath the Project menu option to transmit the
code. While other tools could be used, I currently think the
actual problem has to do with a conflict between the JTAG DLL
that is commonly used (and supplied by TI, I think) by
various vendors AND the Daemon Tools product. There may be
other such conflicts, as well.
Having removed the Daemon Tools product from the active
processes appears to have improved things quite well. I can
still use Daemon Tools when I care to, but just not at the
same time as I use the TI DLL for programming devices.
In short, it works now and I can reproduce the problem when I
want to, as well. It's all software.
That said, I am perhaps confused. I think you are suggesting
that a 2-wire Spy-Bi-Wire interface would fix things. From
that, it seems you imagine that the LaunchPad isn't using a
2-wire interface. But I'm using the MSP430F2001 and
MSP430F2231, for example. And I think those chips ONLY
support 2-wire Spy-Bi-Wire methods. So going to the trouble
of duplicating such hardware wouldn't help. However, perhaps
writing my own software (or using still another package)
would, because I could reference SLAU320G and write code to
do that, I suppose. (Though I think I'd need to pull jumpers
from the LaunchPad for that.)
Is that what you were thinking? Different software driver and
pulling the LaunchPad jumpers to allow access to the JTAG
pins on the MSP430F2001, for example?
I'd like all this to work for other students and to avoid
difficulties, such as more 3rd party downloads than
absolutely necessary, or having to do too much extra hardware
work, as well.
Anyway, I seem to have found a problem on my machine (and on
someone else's, by the way, who also happened to use Daemon
Tools.) So that's good enough for now.
Let me know if I understood you correctly, or let me know
where I went wrong.
And thanks,
Jon
Reply by ●January 12, 20132013-01-12
><snip>Let me know if I understood you
correctly, or let me know
>where I went wrong.
>
>And thanks,
>Jon
I should add something else. The IAR tools' debugger also
could not connect with the LaunchPad when the Daemon Tools
was running. So even if I could download code using an
outside process to do it, it still wouldn't help in using the
IAR tools debugger. This would present a serious problem for
students.
Jon
>where I went wrong.
>
>And thanks,
>Jon
I should add something else. The IAR tools' debugger also
could not connect with the LaunchPad when the Daemon Tools
was running. So even if I could download code using an
outside process to do it, it still wouldn't help in using the
IAR tools debugger. This would present a serious problem for
students.
Jon
Reply by ●January 12, 20132013-01-12
When I went to add the FET USB drivers, I had to use the XP drivers. ( Big
Red Warning Not To) but I went ahead anyway. And they seem to be working
okay.
Red Warning Not To) but I went ahead anyway. And they seem to be working
okay.
Reply by ●January 13, 20132013-01-13
>When I went to add the FET USB drivers, I had to
use the XP drivers. ( Big
>Red Warning Not To) but I went ahead anyway. And they seem to be working
>okay.
Hmm. I don't recall getting such a message with IAR's
installation, which was the only way the FET USB drivers got
loaded on this particular machine (until I decided to load
CCS onto it, anyway.) My memory may be failing me, though.
Still, interesting comment. I suppose I can google up the XP
drivers and see about how to "adjust" IAR to use them. (And
then re-awaken Daemon Tools and check them out.)
Thanks for the thought,
Jon
>Red Warning Not To) but I went ahead anyway. And they seem to be working
>okay.
Hmm. I don't recall getting such a message with IAR's
installation, which was the only way the FET USB drivers got
loaded on this particular machine (until I decided to load
CCS onto it, anyway.) My memory may be failing me, though.
Still, interesting comment. I suppose I can google up the XP
drivers and see about how to "adjust" IAR to use them. (And
then re-awaken Daemon Tools and check them out.)
Thanks for the thought,
Jon
Reply by ●January 13, 20132013-01-13
In device manager, uninstall any drivers associated with the USB device.
Right click on the title "computer name" at the top of device manager. An
option should allow installation of legacy devices. I picked comm devices
and show all manufacturers. Click on the box for "have disk" and navigate to
you IAR folder and into drivers. This is where you get the warning about
the driver being too old or not a 64bit driver. Select the install anyway,
and let it do its thing. ( I was using a " kickstart" version of the IAR
software so my location may not be exactly the same as yours(TI's version?),
but the procedure is the same). You should have a useable USB FET device.
Inside IAR, you will have to select to use this target driver in your
project.
Right click on the title "computer name" at the top of device manager. An
option should allow installation of legacy devices. I picked comm devices
and show all manufacturers. Click on the box for "have disk" and navigate to
you IAR folder and into drivers. This is where you get the warning about
the driver being too old or not a 64bit driver. Select the install anyway,
and let it do its thing. ( I was using a " kickstart" version of the IAR
software so my location may not be exactly the same as yours(TI's version?),
but the procedure is the same). You should have a useable USB FET device.
Inside IAR, you will have to select to use this target driver in your
project.
Reply by ●January 13, 20132013-01-13
>In device manager, uninstall any drivers associated
with the USB device.
>Right click on the title "computer name" at the top of device manager. An
>option should allow installation of legacy devices. I picked comm devices
>and show all manufacturers. Click on the box for "have disk" and navigate to
>you IAR folder and into drivers. This is where you get the warning about
>the driver being too old or not a 64bit driver. Select the install anyway,
>and let it do its thing. ( I was using a " kickstart" version of the IAR
>software so my location may not be exactly the same as yours(TI's version?),
>but the procedure is the same). You should have a useable USB FET device.
>Inside IAR, you will have to select to use this target driver in your
>project.
Thanks for the walkthrough. I appreciate it.
To test this, I need to first "re-break" my system by
activating the Daemon Tools product (easy) and then verifying
that IAR has trouble once again (also easy.) Then start with
the above set of instructions. Fun to do when I get a moment,
hopefully sooner than later.
Jon
>Right click on the title "computer name" at the top of device manager. An
>option should allow installation of legacy devices. I picked comm devices
>and show all manufacturers. Click on the box for "have disk" and navigate to
>you IAR folder and into drivers. This is where you get the warning about
>the driver being too old or not a 64bit driver. Select the install anyway,
>and let it do its thing. ( I was using a " kickstart" version of the IAR
>software so my location may not be exactly the same as yours(TI's version?),
>but the procedure is the same). You should have a useable USB FET device.
>Inside IAR, you will have to select to use this target driver in your
>project.
Thanks for the walkthrough. I appreciate it.
To test this, I need to first "re-break" my system by
activating the Daemon Tools product (easy) and then verifying
that IAR has trouble once again (also easy.) Then start with
the above set of instructions. Fun to do when I get a moment,
hopefully sooner than later.
Jon
