Jump to content
43oh

Permissions for /dev/ttyACM0 for LaunchPad on Linux


Recommended Posts

I've got a "classic" v. 1.3 LaunchPad, and I'm trying to work with it on my Linux box. I'm sure I'm missing something obvious to the experts around here, but what I wrong with my permissions? Have a look:

 

 

$ ls -l /dev/ttyACM0
crw-rw----. 1 root dialout 166, 0 Apr 21 16:18 /dev/ttyACM0
$ groups
john disk lp wheel cdrom dialout floppy games users
$ # permissions on /dev/ttyACM0 look right, I'm in the dialout group, so...
$ ./mspdebug rf2500
MSPDebug version 0.19 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer 
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open interface 1 on 005
rf2500: can't open device: Permission denied
rf2500: failed to open RF2500 device
$ sudo ./mspdebug rf2500
[sudo] password for john: 
MSPDebug version 0.19 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer 
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open interface 1 on 005
Initializing FET...
FET protocol version is 30066536
Configured for Spy-Bi-Wire
Set Vcc: 3000 mV
Device ID: 0xf201
 Code start address: 0xf800
 Code size         : 2048 byte = 2 kb
 RAM  start address: 0x200
 RAM  end   address: 0x27f
 RAM  size         : 128 byte = 0 kb
Device: MSP430F2012
Code memory starts at 0xf800
Number of breakpoints: 2

Available commands:
   =         delbreak  gdb       load      opt       reset     simio     
   alias     dis       help      locka     prog      run       step      
   break     erase     hexout    md        read      set       sym       
   cgraph    exit      isearch   mw        regs      setbreak  

Available options:
   color           gdb_loop        iradix          
   fet_block_size  gdbc_xfer_size  quiet           

Type "help " for more information.
Press Ctrl+D to quit.

(mspdebug) 

 

I don't have any special udev rules set up for the LaunchPad, but it seems like being in the dialout group should do it.

 

Any pointers?

 

Bonus question: mspdebug is identifying my target chip as an MSP430F2012, when it's really an MSP430G2231. The 'G2231 is supposed to be supported by mspdebug, so why isn't it getting the right ID from the FET? Do I need to update the FET firmware? I haven't done that yet.

 

Thanks!

Link to post
Share on other sites

Thanks for the pointer, but it looks like I've got the firmware file already. Any other ideas?

 

What Linux kernel version and distribution is known to work? I'll set it up just to try tracking down what's wrong on my Fedora 15 and 16 machines here.

Link to post
Share on other sites

Guys, MSPDebug does not work on the tty device (in the RF2500 FET context). It opens the raw USB node directly. The tty device is for the passthrough (to the target) serial comms. MSPDebug (libusb, really) works with /dev/usb/${bus}/${device} directly (or, well, this is what it is on my box, not that you ever know how they decide to call it tomorrow).

Link to post
Share on other sites
Guys, MSPDebug does not work on the tty device (in the RF2500 FET context). It opens the raw USB node directly. The tty device is for the passthrough (to the target) serial comms. MSPDebug (libusb, really) works with /dev/usb/${bus}/${device} directly (or, well, this is what it is on my box, not that you ever know how they decide to call it tomorrow).

 

haha yeah, decided to have a go at resolving this and found that out. just rebooting to test udev solution.

Link to post
Share on other sites

Alright, turns out that my idProduct was not "f430" but infact "f432"

i checked with

mspdebug  --usb-list

the id corresponds to

/dev/bus/usb/00x/00x

and changing the group from root to my used one worked so i created a udev file with the correct id.

 

sudo nano /etc/udev/rules.d/69-ti-launchpad.rules

ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f432", MODE="0660", GROUP="dialout"

 

saved and rebooted, and it seems to be working.

Link to post
Share on other sites
So, does the USB interface have problems for you if the LaunchPad's serial back channel sends some bytes while no process on the Linux side is listening for them? I was hoping for a fix for that.

 

Indeed. If no process grabs the data, I need to replug the Launchpad to make it work again. This bug causes me to use a separate USB<->UART device almost all the time.

Does anyone know why the driver behaves this way? A regular bug, or something related to the strange fact that it shows up as a modem device?

Link to post
Share on other sites

Good to know it's not just me with the "no listening process zaps the driver" issue.

 

I found a discussion about this problem with the TUSB3410 and Linux on the Linux Kernel Mailing List in 2010. Greg K-H had some comments, but the thread ended without a real fix. It's interesting that Greg K-H suggested using minicom or similar instead of stty and cat on the ttyACM device.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...