I've had my RF2500 kit for several weeks now.
In that time I have managed to work my way through the usual set of “new processor” basics: I've managed to convince the IAR Workbench to compile my C code and download it to the target board, and I've been able to successfully flash the LEDs and read the internal temperature sensor. On the other hand, I obviously still have a lot to learn: every time I read the F2274 documentation a new xxxCLK signal seems to have been added (Grin?).
One problem I've encountered has to do with the “MSP430 Application UART”, the MSWinXX driver interface to the F2274's specially-routed UART lines (P3.4, P3.5). Now, I can live with a 9600 Baud speed-invariant interface, but under some as-yet-undetermined circumstances it will completely disappear from Device Manager's list of available devices and only reappear after some serious effort on my part.
First, the equipment: I'm working from a Dell Latitude D630 laptop under MSWinXP SP2 (plus the usual random assortment of Microsoft-supplied “Install these or your system Will Suffer Unspeakable Horrors” patches). I'm using the IAR Embedded Workbench IDE 5.1.1.453.7838 (5.1.1.453), and I have attempted to access the target board's UART via USB under openSuSE Linux, but have had no success to date.
Hardware changes: I've soldered a 2x9 header onto the target board, and trimmed the “dongle” case to permit the modified target board to be plugged in.
Code: I have experienced the problem using the TI-supplied demo_AP.c code/file/project. I see the same problem using Hyperterminal or my own C# COMx port monitor. Unfortunately, I can't seem to reliably reproduce the problem.
It “feels” as if some part of the hardware/software inside the dongle is getting into a state where it won't reset itself after being reconnected. Of course, it could also be that the MSWinXP USB driver code is “holding on” to some characteristic of the hardware even when the dongle is unplugged, and then refusing to re-recognize it because it “knows” the port is busy.
Depending on the phase of the moon, one or more of the following steps seem to necessary to clear the problem:
-
Unplugging and replugging the dongle.
-
Cycling power on the laptop.
-
(Drastic) Removing the target board and plugging in the empty dongle, then hot-plugging the target board into the dongle. I'm not comfortable doing this, and I _certainly_ wouldn't recommend it to anyone who was not already in desperate straits, but it does seem to work as a “last resort” when other options fail.
Has anyone else experienced this?
If so, can you offer any suggestions on how I could fix or work around it?
It's entirely possible that this is what IBM used to call a PUE in its S/360 APARS (Probable User Error), but even knowing that for certain would be useful. I'm also aware that I'm omitting three essential pieces of information in this posting... I just don't know what those are. (Sigh!)
My thanks for any insight anyone can provide on this problem.
Frank