We rely on the SD heavily for the program to work properly, to store the frames that will be sent later, to log events for later analysis, to keep the time in case the RTC is reset.
We have seen several SD related issues which appear in some hardware/usage combination. The purpose of this issue is to narrow down exactly the combination that makes the SD to behave funny.
Issue #47 The SD behaves funny with a GPS+Iridium. In commit e504b3586a we fix the problem stopping the SD before using the GPS and starting the SD when done with the GPS. I could not reproduce this issue here with an H mote, so we decided it was an issue specific to the J firmware. But maybe it was not, did that mote have a lemming board as well? The root cause may be one of these combinations: GPS+Iridium+J ; GPS+Iridium+Lemming, GPS+Iridium+J+Lemming
Issue #52 An SD error message is printed in start up, even if later it works fine. Fixed in commit d5bb83f7 and commit 8532495 , we switch off the SD before switching it on, even if the SD is in theory already off. Again we identified this to be an issue specific to the J firmware, but it may be some other combination.
New issue reported in Slack with latest versions of the software. This happens with J+Lemming+GPS+Iridium. Probably it will be fixed by starting the SD a bit later in the boot process, after network initialization:
J#
..C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdBaseFile.cpp1801
C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdBaseFile.cpp1801
.
1554462259.003 INFO Welcome to wsn
1554462259.025 DEBUG Detect hardware
1554462259.747 DEBUG Init network
C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdVolume.cpp268
C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdBaseFile.cpp2123
Append to log file failure status=1
Ideally the purpose of this issue is to identify what hardware combination makes the SD to behave funny, so we can handle it appropriately, e.g. avoiding using the SD and xxx at the same time.
Since we're logging a bit everywhere, the initial idea was to start the SD early and stop it as late as possible. Also starting/stopping the SD takes a bit of time, so the idea was to keep it ON most of the time while the mote is awake. But since we have some conflicts we will need to switch it off/on like we do with the GPS. It would be nice to understand better what's going on.
The SD uses SPI, in theory it's not related to any of the protocols used by sensors, network modules, and gps.
We rely on the SD heavily for the program to work properly, to store the frames that will be sent later, to log events for later analysis, to keep the time in case the RTC is reset.
We have seen several SD related issues which appear in some hardware/usage combination. The purpose of this issue is to narrow down exactly the combination that makes the SD to behave funny.
Issue #47 The SD behaves funny with a GPS+Iridium. In commit e504b3586a we fix the problem stopping the SD before using the GPS and starting the SD when done with the GPS. I could not reproduce this issue here with an
Hmote, so we decided it was an issue specific to the J firmware. But maybe it was not, did that mote have a lemming board as well? The root cause may be one of these combinations: GPS+Iridium+J ; GPS+Iridium+Lemming, GPS+Iridium+J+LemmingIssue #52 An SD error message is printed in start up, even if later it works fine. Fixed in commit d5bb83f7 and commit 8532495 , we switch off the SD before switching it on, even if the SD is in theory already off. Again we identified this to be an issue specific to the J firmware, but it may be some other combination.
New issue reported in Slack with latest versions of the software. This happens with J+Lemming+GPS+Iridium. Probably it will be fixed by starting the SD a bit later in the boot process, after network initialization:
J# ..C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdBaseFile.cpp1801 C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdBaseFile.cpp1801 . 1554462259.003 INFO Welcome to wsn 1554462259.025 DEBUG Detect hardware 1554462259.747 DEBUG Init network C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdVolume.cpp268 C:\Wasp-UIO\hardware\waspmote\avr\cores\waspmote-api\sd_utilities\SdBaseFile.cpp2123 Append to log file failure status=1
Ideally the purpose of this issue is to identify what hardware combination makes the SD to behave funny, so we can handle it appropriately, e.g. avoiding using the SD and xxx at the same time.
Since we're logging a bit everywhere, the initial idea was to start the SD early and stop it as late as possible. Also starting/stopping the SD takes a bit of time, so the idea was to keep it ON most of the time while the mote is awake. But since we have some conflicts we will need to switch it off/on like we do with the GPS. It would be nice to understand better what's going on.
The SD uses SPI, in theory it's not related to any of the protocols used by sensors, network modules, and gps.