DISK_ERR persists following re-insertion of microSD card #563
Replies: 15 comments
-
Posted at 2014-08-11 by DrAzzy I've seen similar behavior on the Espruino board. I think something needs to be reset, but the filesystem code we have just doesn't do so yet. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by @gfwilliams Does a soft reset with As there's no disconnect pin on the Espruino board, it doesn't know if the card has been pulled out, so it doesn't unmount/remount it. Does the error happen if you pull the card out and re-insert it, without doing any file operations when it is removed? I thought that it worked in that case. I think right now your only solution is to call If the error only happens if you read when the card is removed, I'd just explicitly check the value of the card detect pin, and not do anything when it's disconnected. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by roy.emmerich Unfortunately a soft reset doesn't do the trick @gordon. This is what happens: Case 1:
However if I hit the reset button on the board or cycle the power then everything comes back to life. Case 2:
Yes, the
Case 3: I thought out another situation that could occur:
This still works. So it seems a problem arises only once you have already performed a previous card read/write and then remove/re-insert the card, with or without doing any file operations while removed.
Yes, that is what I thought I'd do. Hardware wise however, as you pointed out, this isn't possible with the Espruino board as the card detect pin is not wired up. Also, it seems from the second case illustrated above, that if you have already performed a file operation, then remove and re-insert the card without any further file operations (blocked by not detecting a card) and then attempt a file operation post re-insertion, you still have a problem.
Yes, this is my suspicion too @drazzy. It probably has to be looked at in the C code. Not exactly my strength...yet :). I would have it a guess that upon detecting the card removal (assuming this hardware functionality is available), that the I don't suppose it absolutely must happen in the C code. The main thing is the handle to the FATFS needs to be renewed...I think :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by cephdon Unless things have changed, and I didn't look to see if that was the case or not, the readfile function in fs was a simple open, read, close operation. It used to do an fs init call the first time it was executed, or really the first time anything was executed. From what I know of how it did work, I am wondering if there needs to be an additional flag added for state change of the card. It would be something like: If the state changed is true and the card is not detected, call fs kill and destroy all handles. If this is done during idle, you should have the ability to swap out cards without trouble.....it's a guess anyway, from knowledge of a few versions ago. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by @gfwilliams As there isn't a card detect pin on some boards, we could add an The problem is that |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by DrAzzy A function to reset the fs module would be handy, even if it was manually called. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by @gfwilliams Just to check, I just tried 'Case 1' here on the Espruino Board and it works fine - so I'm pretty surprised that yours is different as it's using the same code. I guess it may be possible that you didn't do a |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by @gfwilliams Having just looked into this a bit more, I could detect the specific I'll add an |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by @gfwilliams Ok, if you pull from GitHub you'll now have function called |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by DrAzzy Not to nitpick, but, why not call it fs.unmount()? That way everything related to the filesystem would be in the same place. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-11 by roy.emmerich @gordon thanks for this addition. I cloned the latest from Git, compiled it and am testing it out. This is what I see: Case 1.1
Case 2.1
Conclusion
I did forget to do
I think there has to be something else. Using the very latest Github version, calling |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-12 by cephdon From what I remember, the fs_kill only deals with the stream handles... unless that has changed. While that would absolutely need to be done, so that streams are handled correctly, the readfile code is a "one shot" open, read, close. Does reset() call wrap_fat_kill and jswrap_fs_kill? Then, once the card is inserted again, you would have to call jsfsInit to get it back into operation. after code inspection At least, that is what it looks like from code inspection based on what is in github. If this works, we would need E.mount to go with E.unmount in order to take full advantage of the hot swap as we are discussing. It looks like it should auto init on read after being unmounted, but I am wondering if that is not working for some reason (as in we are not doing enough to initialize the device, clearly we can initialize on startup). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-12 by @gfwilliams I actually tested both of those cases on the Espruino board before committing and they worked fine. I tested again just now and they're still fine, so I'm not sure what's different with your setup. Are you sure you actually removed the card totally, and that you re-inserted it properly? Could there be a dodgy connection to the add-in board? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-12 by roy.emmerich Not sure what is going on but there must be something more at play here. I have also just tested all the above cases again, making sure to remove the card completely from the slot, and still no joy :( Out of desperation I even removed and replaced the whole microSD click board from the mikroBUS slot while powered up and I still got the same errors! The only difference I can think of is the card detect (CD) pin going low upon card extraction and going high upon re-insertion. I wonder whether that change isn't causing some confusion in the code somewhere? I'm off visiting a friend for the next few days so my involvement here could be a bit sporadic. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-12 by @gfwilliams As far as I can see from the code the card detect pin isn't used anywhere, so I doubt that's the issue... I'm afraid I can't afford to spend any more time on this myself though... If you want an SD card that works, there's always the Espruino board :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-08-10 by roy.emmerich
This is a follow on from my previous discussion concerning the microSD card.
With all my bits and pieces connected up and working, when I run the following command, assuming a text file called
test.txt
is already on the microSD card which contains the word hello followed by an empty line:If, while my system is running, I remove the microSD card and re-run the above I get the following response:
replacing the card and re-running the same command still produces the
DISK_ERR
.My questions:
Temporary solution
The only way I can get the read to work again is to reset everything.
Beta Was this translation helpful? Give feedback.
All reactions