Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use PG as cutoff #9

Open
bschulz1701 opened this issue May 4, 2018 · 3 comments
Open

Use PG as cutoff #9

bschulz1701 opened this issue May 4, 2018 · 3 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@bschulz1701
Copy link
Contributor

Use PG pin to connect to reset line (or some similar setup) to prevent writing to SD card when voltage is below cutoff (As this can cause corruption to files), alternative would be to use CRC check on SdFat writing

@bschulz1701 bschulz1701 added the enhancement New feature or request label May 4, 2018
@bschulz1701 bschulz1701 self-assigned this May 4, 2018
@bschulz1701
Copy link
Contributor Author

Currently PG is only provided as an input to the micro, it is reliant on the user to test PG via firmware before making writes to SD card in order to prevent corruption.

Note: The issue of SD cards being corrupted by voltages lower than 3.3V has been reported anecdotally, it has not been observed with the Margay system and can not be directly confirmed via SD card documentation. That being said, it is good idea to ensure power is stable and within operational ranges before making reads and writes regardless.

@awickert awickert added this to the v3 milestone Mar 1, 2021
@bschulz1701
Copy link
Contributor Author

This could be implemented in hardware, but would require a fair bit of testing to make sure you don't get yourself into a corner on the power system (stuck in a reset loop, etc). This issue was added as the Cave Pearl group noted that you could corrupt the data on an SD card if you performed an undervoltage write (this is reasonable as if the voltage is not sufficient you may not be able to set the SRAM blocks, resulting in a check error). We have never seen this happen on any of our loggers, even when drained below the 3.3V + dropout (~175mV if I remember correctly). Not to say it can't happen, which is why I put this issue as a long term want.
If you look at a micro SD card datasheet, the supply voltage is rated down to 2.7V. The buffer we are using to communicate with the SD card (SN74AUP3G34, U5 on v2.2) is rated all the down to 0.8V. So in the dropout region (2.875V < Vin < 3.475V) the buffer should drive the SD card perfectly correctly and not provide a low voltage to the device. The micro is also able to work fine down to that voltage (discounting potential overclocking issues, but that is separate). All this to say that we have a pretty wide range after the device goes into dropout to detect low input voltage and stop logging before corruption occurs.
I think rather than trying to implement this in hardware (given the low likelihood of an issue and that it would take a bit of time better spent on more pressing issues) we should just implement it in firmware. Before writing to the SD card check the PG pin and do not write if it is low, instead print an error message or flash a low voltage light, etc. This should protect equally well against the issues and may be preferable, since it can give indication of the status rather than just being stuck in reset. I never love the idea of being dependent on mission critical elements in the firmware, but in this case, probably the better/simpler solution. Especially due to the fact we have not been contending with this problem. I have not yet tried to induce a corruption, but from inadvertent low voltage writes, it seems the voltage needs to very low (like 2.5V or less) to cause these kind of issues.

tl;dr - We have never observed this problem, this was a want. However, I think this would be better implemented in firmware for several reasons, would be a very simple implementation.

@awickert
Copy link
Member

awickert commented May 3, 2022

Now that I have made some more significant changes towards v2.3, would you like to make these towards v3 of the board, such that this is the version that we will publish about?

Or should we keep things as they are and keep a possible hardware implementation (beyond PG being broken out) in the future / maybe won't happen?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants