- Status Unconfirmed
- Percent Complete
- Task Type Bugs
- Category Operating System/Drivers
- Assigned To No-one
- Operating System All players
- Severity Low
- Priority Very Low
- Reported Version Release 3.9
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#12468 - Hotswap fails to recognize the card after it was removed in USB mode
If Rockbox is connected via USB with no sd card inserted and it is inserted, it offers the OS to mount the new drive.
If the sd card is removed and reinsterted again, it fails to offer and recognize it.
I could locate the problem in firmware/usbstack/usb_storage.c in the line
if(inserted && check_disk_present(IF_MD(volume))) {
after reinserting the card, check_disk_present fails to return true, so this check fails and the card isn't recognized anymore.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Ok, further investigation reveals, that in the function fat_get_sector_buffer() called in check_disk_present() returns an empty string after reinserting the sd card.
If check_disk_present() returns false, that means the storage_read_sectors() call inside failed. It's just reading the very first sector. A failure probably means the sd driver is encountering problems.
The initial contents of memory pointed to by the return value of fat_get_sector_buffer() don't matter. That's just some free memory where storage_read_sectors() can write.
On what device is this happening? Is this on Fuze+ and related to
FS#12458?Ok, indeed I read the code wrong. It is on Fuze+, but as the other bug had other errors in description, I opened a new one, as I found these problems while investigating the other bug.
Further investigations on this bug reveals, that indeed storage_read_sectors returns a -1 instead of 0 when the sd card is reinserted.
storage_read_sectors calls sd_read_sectors which calls transfer_sectors. And this is indeed a fuze+ specific implementation.
I'll investigate this problem further to see, which part of transfer_sectors fails.
Ok, the problem is that the following line:
ret = sd_wait_for_tran_state();
sets ret to -1.
Investigating further it seems to hint to a timeout during the following lines:
—
—
cmd_retry is set to 10, but no values like 20 or 100 brought the desired result, so it seems that something in send_cmd(SD_SEND_STATUS… goes wrong.
When the thing fails, card_info.rca is set to -433847008 and response is set to 2816.
3861120288 is card_info.rca actually if read as unsigned int.
But other thing is, that SSP_SHORT_RESP has the value of 1 and MCI_ACMD is 4, so send_cmd automatically should have (flags & MCI_ACMD) checked to false as this should become 0, so send_cmd always returns false and won't read. Does this make any sense?