Thank you Eric! Your document https://github.com/cire831/mm/blob/mm5t/doc/Notes is particularly helpful for the overall setup.
I will try to downgrade the firmware using the windows downgrader in the CCS. I'll see if I can reproduce some of the expected stuff. Nevertheless, I will probably try to keep atleast one cable on V3. That we I can possibly contribute some comparison metrics/bugs fixes. As for the TODO mentioning msp430-jtag, it is https://github.com/tp-freeforall/prod/blob/msp430-int/tools/toolchain/TODO Regards Shalabh On Tue, Jun 26, 2012 at 7:25 PM, Eric Decker <[email protected]> wrote: > > > On Tue, Jun 26, 2012 at 4:02 PM, Shalabh Jain <[email protected]>wrote: > >> Hello, >> >> 2. Most of the posts on the net mention being able to use the 'uif' or >> 'uif-bsl' modes with the JTAG. However, whenever I try that I get errors in >> the connection (I'll explain later why I'm trying to use it) >> > > My understanding is that uif uses the jtag pod as a jtag for the device > the jtag is connected to... > > While uif-bsl talks directly to the bsl (bootstrap loader) that is on the > cpu in the jtag itself. In other words you don't want to flash a program > you've built for your mote into the jtag which is what you might be doing > if you specify uif-bsl. > > Take a look at the email thread at > http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/8924 > > That might provide some insight... > > I think most of your problems are coming because you updated to V3. > > > >> for uif >> uif: read error: Connection timed out >> fet: open failed >> >> for uif-bsl >> bsl: bootloader start returned error 128 (Unknown error) >> bsl: warning: FET firmware not responding >> bsl: bad ack character: 5 >> bsl: bad ack character: 92 >> bsl: sync failed >> >> I'm guessing/rather hoping that this has something to do with the V3 not >> being usable in the bsl mode. Perhaps you could shed some light on that. >> > > Don't know. I consider the V3 stuff a work in progress. I haven't > updated my jtag pods. So I use "mspdebug uif -jd /dev/ttyUSB0". > > Now that you have updated to V3 I don't know how you can go back. > > >> 3. My device (again I'm guessing because of the V3 firmware) shows up as >> /dev/ttyACM0. The device ID and vendor ID I get is deviant from most of the >> literature I have seen on the internet. > > > Don't know what to tell you. I've avoided taking this route but have > stayed on the old firmware. I consider the V3 stuff a work in progress. > It is coming along but I didn't want to caught up in helping to make it > work (distraction). > > > >> Also, plugging in the USB doesn't initiate the loading of the ti3410 >> kernel module. > > > That would be a udev issue. > > >> In fact manually loading this module changes nothing in the system. Now I >> am able to run the debugger and connect to it (its crashing for now but I >> got it to work once). I don't know if its because of this different type of >> interface. Do you have any comments/clarifications about this problem? >> > > nope. > > Here is what I get from lsusb for my device... > > Bus 005 Device 003: ID 0451:f430 Texas Instruments, Inc. MSP-FET430UIF > JTAG Tool > > > I haven't dealt with 2047:0010. > > > >> Below are the outputs of dmesg and lsusb after plugging in the board >> >> dmesg >> [34487.948166] usb 6-2: new full speed USB device number 9 using uhci_hcd >> [34488.160347] cdc_acm 6-2:1.0: This device cannot do calls on its own. >> It is not a modem. >> [34488.160411] cdc_acm 6-2:1.0: ttyACM0: USB ACM device >> >> lsusbBus 006 Device 009: ID 2047:0010 Texas Instruments >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 2.00 >> bDeviceClass 2 Communications >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 8 >> idVendor 0x2047 Texas Instruments >> idProduct 0x0010 >> bcdDevice 1.04 >> iManufacturer 1 Texas Instruments >> iProduct 2 Texas Instruments MSP430-JTAG >> iSerial 3 77FF598CDECE430F >> bNumConfigurations 1 >> >> >> I think that most of the confusions I have arise because of a lack of >> understanding of the toolchain and the JTAG and BSL interfaces. > > > okay. I would agree. > > I would recommend in the future that you don't change the state of devices > until you've fleshed things out better. It is hard to recover stuff after > it has been changed. > > >> Also, there is some confusions in my mind regarding using serial >> debuggers. > > > Okay, but you are changing subjects. Technically, jtags aren't serial > debuggers. Jtags are boundary scan chain interface units. They talk to > control hardware in chips that are VLSI. Is that what you are talking > about? Serial debuggers are a different beast. > > I have been reading a lot on these topics. But this still seems fuzzy. If >> you have any good recommendations of things I could look at to better >> understand this process and debugging of the board, I'd appreciate it. I >> think for the type of algorithms I intend to implement, it will be really >> helpful to be comfortable with the overall chain, rather than using it as a >> simple gui tool. >> > > I don't know what you mean. I'm not parsing your sentence. There > really isn't such a thing as a simple gui tool (its all lies :). > > eric > > > >> >> Thanks a lot for your help >> >> Shalabh >> > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
