This is quite an interesting problem. Not entirely sure if it's an mbed bug, but see what you think.

So, I've been using mbed on FreeBSD and monitoring the serial console using screen. Now I'll pretend I don't know the solution and say that the only problem is, the output vanishes if you unplug the mbed and plug it back in again. This terminates the screen session as expected, but upon reconnect, output is no longer sent to screen, but I can see the mbed flash if I type on the keyboard: i.e, something is definitely getting from the screen session to the mbed.

Well It turns out this has nothing to do with screen, and you can use Freebsd's cu command and the same thing happens. What is going on? Working with the guys on the FreeBSD forum, whilst the initial thoughts were to blame screen, it would seem that this was red herring.

The problem of the missing output can be solved simply by power-cycling the mbed fully: complete disconnect and reconnect from power source. Then, when it fires up and is connected to FreeBSD, the serial output can be seen as normal.

It took a while to discover this workaround because: (i) I was using an external power supply so the mbed never lost power. (ii) This problem does not occur on Linux or Mac (not tried windows), so I had no suspicion that this might work.

So it would appear that something odd is going on. I was under the impression that when connecting an mbed via USB to an OS, one should expect the same behaviour whether or not the mbed is already powered up?

Is there some difference in the way an mbed would enumerate itself in the two cases:

1. First time connected after first power up 2. Second time connected (without an intermediate power-cycle event)

?

Regards

Ashley

Just to follow this up. It would seem that cycling the power doesn't always work. So this points to an OS problem. I would still be interested to know if there would be any differences as outlined above.

Interestingly, or not, I noticed this problem also occur with Linux. But only on the very rare occasion.

I think it might be something to do with OS cleanup of open file descriptors, but that's just a guess.

This isn't really a problem as there is an obvious workaround, namely cycling the power, but still I find it compelling to understand things.

Ashley

It turns out that the power-cycling doesn't always fix this. I am trying to figure out what exactly is going on. Bizarrely I can get it to work through linux on a virtualbox on freebsd

Out of interest, this is how the mbed appears on FreeBSD 10.0-RELEASE:

umass0: <mbed Microcontroller, class 2/0, rev 1.10/1.00, addr 5> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x4100
umass0:4:0:-1: Attached to scbus4
umodem0: <mbed Microcontroller, class 2/0, rev 1.10/1.00, addr 5> on usbus1
umodem0: data interface 2, has CM over data, has break
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0: <mbed Microcontroller 1.0> Removable Direct Access SCSI-0 device 
da0: Serial Number 101000000000000000000002F7F10359
da0: 1.000MB/s transfers
da0: 2MB (4096 512 byte sectors: 64H 32S/T 2C)
da0: quirks=0x2<NO_6_BYTE>

The quirks=0x02<NO_6_BYTE> is a bit strange, see: http://www.root.org/~nate/freebsd/scsi/quirks.html, but probably not the issue.

I believe the issue lies in the umodem device, which in term uses ucom. There are many options when a tty is created, these are the options on the cuau0 device that FreeBSD creates:

speed 9600 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb clocal

I've tried turning flags on and off to no avail. My next step is to hit the freebsd-usb mailing list.