Getting "disk not ejected properly" in OSX

[LarryTru]

Hello,

I get "Disk not ejected properly" errors a few minutes after my MicroPython board is connected to my Mac. I've tried several cables since I saw previous posts where this behavior was due to faulty USB cables, but it did not help. I am not using an SD card. Sometimes the error pops up on its own and sometimes it pops up only after I try to access the MicroPython drive.

Any ideas?

Larry

[pythoncoder]

I've no experience of OSX but the symptom could be explained by an intermittent power connection or dubious voltage level. As a quick test I'd turn on an LED on the board and check that it's still on after the error has appeared. You could also check the 5V level on the board if you have a DVM.

Regards, Pete

[blmorris]

I have been seeing the same problem, only recently confirmed that the problem isn't specific to my own fairly old MacBook.

[LarryTru]

Hello bimorris, Glad it isn't just me!


Hello pythoncoder, Voltage looks good and stable.


Here's a sequence of events to illustrate what I am experiencing:


1) main.py contains following program:


from pyb import LED
from pyb import delay


l = LED(3)
c = 0


while True:
print(c)
c += 1
l.toggle()
delay(250)


2) This program toggles the yellow LED and counts to console at a rate of ~4HZ.


3) Plug in Micro Python and program begins without any error indication. LED flashes as expected.


4) Start a terminal window and use “screen /dev/tty.usbmodem*” to connect to console. The count progresses on the console output as expected.


5) Start another terminal window and use “cd /Volumes/"no name”” to set PWD to the Micro Python “0:/” drive.


6) Execute “date >test1” to prove that the drive can be written to (red disk activity LED lights on Micro Python board).

7) Now we’re just waiting to see the problem occur, but I have not found a way to reproduce it consistently If I wait long enough the “ disk not ejected properly error will appear. Exercising the drive (e.g. "date >test2”, listing, reading, etc.) can make it show up earlier.


Observations:
1) The program continues running continuously even after the error occurs. The LED continues to flash and the console continues to show the continuing count.
2) The problem does not appear to be triggered by disk activity since the red activity LED only lights up for writes I initiate.
3) The only way I know to re-establish access to the “0;/“ drive is to hard reset or unplug/plugin the USB cable.
4) Reading a file from the disk is not a reliable way to detect if the problem has occurred (apparently because file contents are cached and used for repeated reads).
5) I don’t think there is any visible indication at the moment the problem occurs. I only see the impact later when something attempts to access the disk.



Any requests for other test cases to try?

Thanks,

Larry

[dhylands]

I moved this topic to general, since it doesn't really belong in Micropython Development..

[blmorris]

I moved this topic to general...

Thanks, better place for it.

Hello blmorris, Glad it isn't just me!

Yeah, and I'm feeling rather silly now not reporting it earlier, as I've been aware of it for a while. Initially I thought it was just my own old machine getting flaky. Then I got used to just unmounting disk right away after doing what I wanted. Then I actually confirmed on another Mac but forgot to report.

Anyway, all five of your observations are completely consistent with what I have seen.

• The program running on the board will continue as though nothing has happened.
• The virtual comm port will continue to function without interruption; I have left boards running and connected to a terminal program for hours without any sign of instability.
• There is no obvious sign that the Mass Storage driver has frozen up; everything looks normal until you try to write a file, read a file that isn't already open, or unmount the drive, then you get the "disk not ejected properly" message window.
• Everything will work perfectly for a few minutes or so, and if you unmount the drive in that time there will be no hangups and you can continue to work through the REPL.
• I tried to trace the problem using a Beagle USB 12 analyzer, but couldn't find any event to indicate when the problem occurs (I'm no expert debugging low-level USB issues.)

Running OSX 10.7.5 on a 2007 MacBook Pro Core 2 Duo

[dhylands]

Pressing Control-D at the REPL used to reset the sdcard (via UMS - USB Mass Storage) which might trigger the host to detect that the volume wasn't ejected properly (I don't have a Mac, so I'm not sure).

There was a recent change in the firmware for the sdcard: https://github.com/micropython/micropyt ... ac13086dd1 which changes the behaviour for the physical sdcard. (but doesn't change any behaviour for the internal flash area).

It would be interesting to find out if that has any impact on things.

[LarryTru]

Hello,

Pressing "ctrl-d" does soft-reset the board, but has no effect on the state of the USB mass storage.

I did update my firmware recently, but perhaps not recently enough to have that sdcard fix in it. I'll try to update it again sometime soon.

Larry

[blmorris]

Confirmed that the issue still exists for me- I downloaded the latest firmware image http://micropython.org/static/download/ ... ad2df3.dfu and burned to a pyboard; plugged in and confirmed that I could access files from the internal flash (no SD card involved); waited ~5 minutes and tried to eject the "NO NAME" drive. After thinking for about a minute the system gives the "disk not ejected properly" message.

I maintain the REPL on a terminal the whole time, it continues to work normally.

-Bryan

[dhylands]

@blmorris - you mentioned that you have a Beagle 12.

Is it possible for you to grab a capture when you eject the volume?

I'm not sure what formats it can export in (or maybe it can't).

Is the SW for the Beagle 12 available somewhere? Sometime the SW works without the device for doing things like examining captures, but it seems to vary from product to product.