Since my very first pyboard arrived as a result of the first kickstarter campaign N years ago I've got along happily using the mass-storage method for uploading code to the pyboard. Though I am aware of dhylands' https://github.com/dhylands/rshell (and though I would be happy to use it if I needed to) in practice I have got along so far perfectly fine without it.
OK: occasionally I have forgotten to eject the disk properly before unplugging, and occasionally this has corrupted things, but that has always been recoverable, so I never felt the need to change my working practices.
However: just this week, while doing some intense development on a D-series board (my first and only D-series) which is embedded in a device I'm building, I've noticed something I've not seen before. For all I know, what I'm seeing is not actually a pyboard problem. On the contrary it may turn out to be a mac problem --- however I report it here just in case anyone else has seen it, or in case it relates exclusively to D-series board (since this is the first and only time I've done lots of development on a D-series).
The minor irritation I'm seeing is caused by my need to do occasional hard resets to reset the LAN stack.
Because it's hard to reach the pyboard (I have to remove a ceiling panel to get to it) I tend to hard reset it by disconnecting and reconnecting the USB cable. To do this I first click the relevant PYBFLASH eject button in my mac's finder window. The initiated ejection process then takes about 10 seconds instead of the 1 second I'm used to seeing it take for previous boards I have worked with. Nonetheless the unmounting/ejection process appears to work successfully: there and no error messages, and the mount points disappear from the filesystem as expected. All therefore looks good. At this point I cab pull out the usb cable and reconnect it .. and continue my development. Such cycles continue happily until I get tired and go to bed, say, after which I may have done, say, 5 hard resets, and many soft resets. Still no problems.
BUT:
Then hours later, when I re-open my computer, after having gone to bed or had dinner in the meantime, I am presented with a flood of notifications (e.g. 5 or 6) from the OS all warning me that I forgot to eject the drive properly many hours ago. I've checked that I do not have the "do not disturb" settings on my mac set to delay the arrival of the notifications --- though of course that doesn't mean that there's not a mac bug that has the effect of making things behave as if such a setting were enabled.
Strange!
The fact that these notifications only appear a long time (~hours) after the ejections, coupled with the fact that the ejections take a strange time (~10 seconds, perhaps indicating a timeout) rather than usual ~1 second, all point (in my mind) circumstantially to this being a new quirk of OSX on the mac rather than something pyboard-D specific.
But maybe someone on this forum knows differently?
[ Aside: I have assumed above that it's the hard-resets following the slow ejects that are leading to the error messages hours later, but I suppose it is possible that they are being caused by the soft resets I'm doing instead? Is this possible? I've not previously seen soft resets result in my being given complaints about incorrect ejection .... ]
Cause of complaints about hard resets being delayed by hours?
-
- Posts: 23
- Joined: Sat Nov 17, 2018 10:04 pm
Re: Cause of complaints about hard resets being delayed by hours?
Interesting!
Unfortunately I don't know much about the macOS side of things, but I think it's worth highlighting that while the mass storage approach does work well but it is quite fragile... there are a lot of ways it can go wrong.
For my own projects I always use LFS2 instead of FAT and disable MSC. I use pyboard.py (and the soon-to-be-merged mpr -- see https://github.com/micropython/micropython/pull/6375), although rshell is also very good.
For me, pyboard.py is so much more efficient because I don't even have to copy the files to the pyboard during development. mpr makes that work for multi-file projects because it can mount the host PC's filesystem onto the pyboard.
LFS2 avoids a lot of problems with hidden filesystem corruption and is just generally more resiliant to power outage.. for example it's possible to get into a state where the pyboard's FAT drive ends up full of abandoned blocks (which can be repaired with fsck/scandisk) but won't happen automatically.
Unfortunately I don't know much about the macOS side of things, but I think it's worth highlighting that while the mass storage approach does work well but it is quite fragile... there are a lot of ways it can go wrong.
For my own projects I always use LFS2 instead of FAT and disable MSC. I use pyboard.py (and the soon-to-be-merged mpr -- see https://github.com/micropython/micropython/pull/6375), although rshell is also very good.
For me, pyboard.py is so much more efficient because I don't even have to copy the files to the pyboard during development. mpr makes that work for multi-file projects because it can mount the host PC's filesystem onto the pyboard.
LFS2 avoids a lot of problems with hidden filesystem corruption and is just generally more resiliant to power outage.. for example it's possible to get into a state where the pyboard's FAT drive ends up full of abandoned blocks (which can be repaired with fsck/scandisk) but won't happen automatically.
-
- Posts: 23
- Joined: Sat Nov 17, 2018 10:04 pm
Re: Cause of complaints about hard resets being delayed by hours?
As I'd never come across pyboard.py before reading the last post, I'm putting a link to it below:
https://docs.micropython.org/en/latest/ ... rd.py.html
It looks very useful!
https://docs.micropython.org/en/latest/ ... rd.py.html
It looks very useful!
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Cause of complaints about hard resets being delayed by hours?
My view is that MSC mode isthe spawn of the devil. Sooner or later it will bite you ![Sad :(](./images/smilies/icon_e_sad.gif)
It shouldn't be necessary to unplug a Pyboard to reboot it. If you can get to a REPL with ctrl-c you can issue
Your terminal emulator will probably kick you out, but you should be able to restart it.
![Sad :(](./images/smilies/icon_e_sad.gif)
It shouldn't be necessary to unplug a Pyboard to reboot it. If you can get to a REPL with ctrl-c you can issue
Code: Select all
import pyb
pyb.hard_reset()
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.