Cause of complaints about hard resets being delayed by hours?
Posted: Sun Feb 07, 2021 9:57 am
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 .... ]
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 .... ]