Connecting mbed microcontroller to FreeBSD

ashleymills

ashleymills

Hi,

This is me:

Code: 
[mbd@stdy ~]$ uname -a
FreeBSD stdy.xxx 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 01:47:53 UTC 2012     root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

I'm trying to develop for the mbed microcontroller on FreeBSD. The mbed is a microcontroller with a mini USB jack, which when plugged into the host OS, appears as both a mass-storage device and a serial port. See mbed.org for more information.

I have no problem mounting the device and programming it via the cloud IDE (binaries are simply saved to the mass storage device).

My problem applies to monitoring the Serial output of the mbed device on the host serial port. The problem is fundamental: I am unable to see any output from the mbed. This is not a problem on Linux, or Mac, or Windows. I mention the latter, so you can have some confidence that this is not user error: I have used the mbed device on perhaps 15 different non-FreeBSD systems without the problem described here.

This is my first post here. I must admit, I was a little intimidated in this regard, out of fear of appearing stupid. I've attempted to comply to the exacting standards outlined by DutchDaemon, but no doubt I'll have made some egregious mistake in someone's unforgiving eyes. I hope not.

Obseve the following sequence of events (I'm going to plug the mbed device in):

Code: 
[mbd@stdy ~]# ls -l /dev/cua*
crw-rw----  1 uucp  operator    0,  45 Nov 30 09:35 /dev/cuau0
crw-rw----  1 uucp  operator    0,  46 Nov 30 08:38 /dev/cuau0.init
crw-rw----  1 uucp  operator    0,  47 Nov 30 08:38 /dev/cuau0.lock
[mbd@stdy ~]# # plugging mbed in now
[mbd@stdy ~]# ls -l /dev/cua*
crw-rw----  1 uucp  operator    0, 142 Nov 30 15:36 /dev/cuaU0
crw-rw----  1 uucp  operator    0, 144 Nov 30 15:36 /dev/cuaU0.init
crw-rw----  1 uucp  operator    0, 145 Nov 30 15:36 /dev/cuaU0.lock
crw-rw----  1 uucp  operator    0,  45 Nov 30 09:35 /dev/cuau0
crw-rw----  1 uucp  operator    0,  46 Nov 30 08:38 /dev/cuau0.init
crw-rw----  1 uucp  operator    0,  47 Nov 30 08:38 /dev/cuau0.lock
[mbd@stdy ~]# # examine dmesg
[mbd@stdy ~]# dmesg | tail -n 12
ugen4.3: <mbed> at usbus4
umass0: <mbed Microcontroller, class 2/0, rev 1.10/1.00, addr 3> on usbus4
umass0:  SCSI over Bulk-Only; quirks = 0x4100
umass0:2:0:-1: Attached to scbus2
umodem0: <mbed Microcontroller, class 2/0, rev 1.10/1.00, addr 3> on usbus4
umodem0: data interface 2, has CM over data, has break
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: <mbed Microcontroller 1.0> Removable Direct Access SCSI-0 device 
da0: 1.000MB/s transfers
da0: 2MB (4096 512 byte sectors: 64H 32S/T 2C)
g_vfs_done():ada0p1[READ(offset=262144, length=8192)]error = 5
ext2fs: ada0p1: wrong magic number 0x1f07 (expected 0xef53)

Everything looks OK, both the serial console (umodem0) and the mass storage device (umass0) appear. I'm not sure about the last two lines, but I'm guessing it isn't the problem, any thoughts?

Now that the mbed is plugged in, I'm going to try and monitor it via screen:

Code: 
[mbd@stdy ~]$ screen /dev/cuaU0 115200

Whilst you can't see the output, trust me that screen says:

Code: 
Cannot open line '/dev/cuaU0' for R/W: Permission denied
Sorry, could not find a PTY.

Hmm, this is strange, what permissions are on this device?

Code: 
[mbd@stdy ~]$ ls -l /dev/cuaU*
crw-rw----  1 uucp  operator    0, 142 Nov 30 15:36 /dev/cuaU0
crw-rw----  1 uucp  operator    0, 144 Nov 30 15:36 /dev/cuaU0.init
crw-rw----  1 uucp  operator    0, 145 Nov 30 15:36 /dev/cuaU0.lock

And to which groups do I belong?

Code: 
[mbd@stdy ~]$ groups 
mbd wheel operator uucp dialer vboxusers

Right, so I'm a member of operator, and it looks like operator has rw permissions, so why can I not open this device? Let me guess, there is some weird proviso somehwere that I don't know about concerning these special devices?

That's my first problem: permissions.

However, as I know what I'm connecting to, I don't mind being root to check things out. I'll try and connect as root:

Code: 
[root@stdy ~]# screen /dev/cuaU0 115200

This time the screen session starts, but I cannot see any output from the mbed device. It could be the mbed doing something odd I suppose, but this seems unlikely since it works on Linux and Mac without issue.

You probably don't care, but on the mbed I'm using an exceptionally simple test program:

Code: 
#include "mbed.h"
int main() {
   Serial pc(USBTX,USBRX);
   pc.baud(115200);
   while(1) {
      pc.printf("Hello\r\n");
      wait(1);
   }
}

At least you should be able to ascertain that it would be difficult to get this wrong.

What does stty say about the console device? :

Code: 
[root@stdy ~]# stty -f /dev/cuaU0
speed 115200 baud;
lflags: -icanon -isig -echo echoe echok echoke echoctl
iflags: -icrnl -ixany -imaxbel ignpar
oflags: -opost -onlcr tab0
cflags: cs8 -parenb -hupcl clocal
eol     eol2    erase2  kill    min     time    
^@      ^@      ^@      ^H      100     2

I can't see anything wrong here, but then again, I've only read the stty manual twice.

I've tried setting /dev/cuaU0.init to 115200 baud using stty, just in case, but I can't seem to get it to work. I've also tried the /dev/ttyU0 device, and that didn't work, but from reading the handbook, I can't see why that would be different, unless I've missed something?

Now, here is the clincher: earlier today I fired up screen, and it worked. I have no idea why. I saw the output from the mbed device, and there were no problems. Then it stopped working when I tried something else later on.

And crazily, it just worked now when I tried it, despite not working for the past 1 hour of testing and messing around. I did leave the device unplugged for a while just now, perhaps this has something to do with access to file handles? (a guess based on experience with badly terminated AF_INET sockets)

The next time it breaks, I'll try unplugging it for 15 minutes, and then back in to see if that helps.

In the meantime, any ideas on either of the two problems (permissions and monitoring)?

Thanks

Ashley
 
Don't use screen for this, use something like cu(1) or comms/minicom.

Also check if the board actually expects 115K2 baudrate. It may default to 9600, which is still a common speed for console(-like) access.
 
First, compliments on a nicely-formatted post. Thanks for taking the time to do it well.

While sysutils/screen can be used as a terminal program, there have been more than a few reports of problems with it in general. Many people have switched to sysutils/tmux. However, tmux(1) does not have serial terminal program support. I use cu(1), because tip(1) has never made sense to me. Oddly, people have told me they use tip(1) because cu(1) never made sense to them. (This would be less strange if they weren't actually the same program.) For cu(1):
% cu -l /dev/cuaU0 -s 115200

The problems may be due to the mbed being a composite USB device. The g_vfs_done error at the end of the output suggests a problem. Maybe due to the device doing something unexpected, and possibly something that could be addressed with a USB quirk. The freebsd-usb mailing list is the best place to ask about that.

Is the mbed configurable? Could the USB mass storage function be disabled?
 
Hello,

Thank you for your quick and sensible responses.

SirDice: the board does default to 9600 but I'm setting it to 115200 in it's program.

SirDice,wblock:

I just booted up and tested everything out. screen was working and so was cu(1)(), and interestingly, so was cu(1)() as a non-root user, so it seems cu(1)() at least respects the permissions.

I unplugged the device, and plugged it back in. And then it stopped working, on both screen and cu(1)().

So I tried power-cycling the device. And you guessed it, it worked. I've tested the same routine now 10 times and it works every time. I can use either screen or cu(1)(), it doesn't matter.

So here is an example, of having done something so many times on other systems: namely re-enumerating the device without power-cycling, and having no problem. And so completely overlooking this as a potential problem on a new system. Note that when I say power-cycle, I mean a complete termination of power supply, followed by re-establishment: resetting the device doesn't work. My previous miraculous instances of it working, must have been due to an incidental power-cycling event.

In this case then, it would seem that there is something different in the way the mbed presents itself to FreeBSD, depending whether it is the first time after power-on that it is connected, or the second and subsequent times. And whatever this difference is, it doesn't cause a problem elsewhere, but it does on FreeBSD.

It is feasible that there is a genuine bug in the mbed interface code, as quite often people power the mbed with USB, such that a cable-reconnect is by default, a power-cycle too. I'm using an external power supply.

I'll ask the mbed guys about what differences might manifest in the two scenarios.

Thanks

Ashley
 
You must log in or register to reply here.
Back
Top