@wwatson, @WMXZ, @mjs513...
I may not have much time to play here today, so thought I would revisit why the 1GB CRUZER (SanDisk) is not working... Endless loop waiting for media available...
And document what I have found, in case someone else can pick up where I leave off...
So wondered if maybe it has multiple logical units... So thought about adding the code for it... Then saw it was already there...
Changed the init code to print out the result, like:
Code:
msResult = msDrive1.msGetMaxLun();
Serial.printf("## mscInit after msgGetMaxLun: %d\n", msResult);
delay(150);
And for working disk and this non-working disk they showed 0 printed...
Then I looked a little closer at it. The code for getting max lun...
Code:
uint8_t msController::msGetMaxLun() {
mk_setup(setup, 0xa1, 0xfe, 0, 0, 1);
queue_Control_Transfer(device, &setup, report, this);
return report[0];
}
This won't work as you have only queued the request and then return the data before it ever has chance to be filled in...
Now looking at output of my non-working drive:
Code:
control CallbackIn (msController)
00 00 00 00 00 00 00 00
## mscInit after msgGetMaxLun: 0
control CallbackIn (msController)
01 00 00 00 00 00 00 00
msController CallbackOut (static)
You will see the Callback showing a value of 1...
And going back to look at the other thumb drive that is returning data:
Code:
control CallbackIn (msController)
00 00 00 00 00 00 00 00
## mscInit after msgGetMaxLun: 0
control CallbackIn (msController)
00 00 00 00 00 00 00 00
msController CallbackOut (static)
It does show 0 as the last valid LUN...
So thinking maybe in this case, (after fixing the code to wait for callback before returning, which I have not done yet),
Maybe if media is not available on LUN=0, need to try others up to MAX and/or maybe always try the MAX one first?
If this is the issue, will need to change several low level functions, to take in the LUN to pass as either parameter or some global setting....
Kurt
