UHS_FS_NEW_DEMO crashing #46
Comments
|
No need to do a hardware reset on the max chip. Resetting is able to be
done by commands on SPI. See the RM for details.
…On Wed, May 29, 2019, 11:50 AM Marcio Teixeira ***@***.***> wrote:
I am trying to run the UHS_FS_NEW_DEMO on an Tosduino MEGA 2560 (Arduino
Mega compatible) with an Arduino USB Host Shield and it seems to crash
during Init_Generic_Storage(&UHS_Usb);, as shown by this screen shot:
[image: usb_rebooting]
<https://user-images.githubusercontent.com/29129419/58571496-158d5580-81f7-11e9-9db2-6496bad60ce8.png>
One of our engineers had made a small modification to the RESET pin of the
Arduino shield, so I had to add the following bit of code to the start of
the sketch:
void setup() {
// MAX3421 reset pin on D7
pinMode(7, OUTPUT);
digitalWrite(7, LOW);
delay(100);
digitalWrite(7, HIGH);
delay(100);
...
}
I presume this won't cause a problem, but I thought I would mention it,
just in case. I'll try narrowing down where in Init_Generic_Storage the
crash is happening.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#46?email_source=notifications&email_token=AA5SJTBJBDKIRJ544HQMX2DPX2Q5NA5CNFSM4HQOGN5KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GWQXXNQ>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5SJTA6QSQCIVMUZXBUIW3PX2Q5NANCNFSM4HQOGN5A>
.
|
I'll have to ask why he did this, but I seem to recall it was recommended somewhere because apparently that pin wasn't properly connected on the shield and could cause issues. The crash happens here: UHS30/libraries/UHS_FS/UHS_FS_INLINE.h Line 330 in 9da30f0 I'm a bit surprised to see "new" in Arduino code. This seems like it would be highly inefficient, considering we only have a couple kbytes of RAM. |
|
On Wed, May 29, 2019 at 12:21 PM Marcio Teixeira ***@***.***> wrote:
No need to do a hardware reset on the max chip. Resetting is able to be
done by commands on SPI. See the RM for details.
I'll have to ask why he did this, but I seem to recall it was recommended
somewhere because apparently that pin wasn't properly connected on the
shield and could cause issues.
The crash happens here:
https://github.com/felis/UHS30/blob/9da30f03c005016d0555eb40448b18cd6b2042d9/libraries/UHS_FS/UHS_FS_INLINE.h#L330
/**
* This must be called before using UHS USB Mass Storage. This works around a G++ bug.
* Thanks to Lei Shi for the heads up.
*/
static void UHS_USB_BulkOnly_Init(UHS_USB_HOST_BASE *hd) {
for(int i = 0; i < MAX_USB_MS_DRIVERS; i++) {
UHS_USB_Storage[i] = new UHS_FS_BULK_DRIVER(hd, i);
/}
}
Tried AVR gcc from 1.6.11?
I'm a bit surprised to see "new" in Arduino code. This seems like it would
be highly inefficient, considering we only have a couple kbytes of RAM.
Yeah, but notice that UHS3 comes with it's own ISR safe memory management...
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#46?email_source=notifications&email_token=AA5SJTGHSR7YKEPXAL7NA33PX2UPRA5CNFSM4HQOGN5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWP33BI#issuecomment-497008005>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5SJTAR57G7R6JK3TY2XMLPX2UPRANCNFSM4HQOGN5A>
.
--
Visit my github for awesome Arduino code @ https://github.com/xxxajk
|
My concern is with the overhead of heap management. I don't know what type of data structure is used for the heap, but I imagine it must have at least a few bytes per allocated block of overhead. Anyhow, I guess at this point I just need to know why it is crashing. I am using Arduino 1.8.8, BTW. |
|
use avr boards 1.6.11 (boards manager) and see if that works. |
|
When I downgrade to 1.6.11 via the boards manager, it fails to link: |
|
Oh, wait, that looks like it is avrdude that is failing to run. Let me see if I can use something else to load the hex file. |
|
you may need to install 32bit compatibility libs... |
|
I'm pretty sure if I ask the answer will be no. This is 2019... What is it about the newer AVR stuff that is incompatible with this library? Even if I can get this particular example to work, if it requires older libs, then I'll run into integration problems later, so it's kind of a catch-22. |
|
I'm aware of that fact. |
|
I had to use the system copy of Oddly, inserting a USB drive does nothing. But at least it's getting closer... and it seems like at least I confirmed that the latest AVR stuff is having some adverse effects.
Makes sense. And we can't really make any demands unless we hire you as a consultant and you are willing to do that :) But I have a couple weeks to determine whether it is feasible for us to make a new printer based on UHS3, so this is a good thing to know. Incompatibilities with current tools would definitely be a significant obstacle and would recommend against that. Do you have any notion whether the AVR incompatibility is just with the FAT parsing stuff, or whether it affects the USB_HOST and BULK_STORAGE code too? If it were only the FAT code, we could still possibly proceed since my plans were to use the Marlin FAT code anyway. |
|
Format the drive as fat, not ntfs? Also, may take a few moments to mount
the volume.
…On Wed, May 29, 2019, 1:02 PM Marcio Teixeira ***@***.***> wrote:
I had to use the system copy of avrdude to flash the .hex file, but now
it gets past the initialization. Woot!
Start.
USB HOST READY.
No media. Waiting to mount /
Oddly, inserting a USB drive does nothing. But at least it's getting
closer... and it seems like at least I confirmed that the latest AVR stuff
is having some adverse effects.
Basically I need to spend the time to resolve this issue.
Makes sense. And we can't really make any demands unless we hire you as a
consultant and you are willing to do that :) But I have a couple weeks to
determine whether it is feasible for us to make a new printer based on
UHS3, so this is a good thing to know. Incompatibilities with current tools
would definitely be a significant obstacle and would recommend against that.
Do you have any notion whether the AVR incompatibility is just with the
FAT parsing stuff, or whether it affects the USB_HOST and BULK_STORAGE code
too? If it were only the FAT code, we could still possibly proceed since my
plans were to use the Marlin FAT code anyway.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#46?email_source=notifications&email_token=AA5SJTEXFTJFDGU5GCD5ZTDPX2ZKDA5CNFSM4HQOGN5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWP7VLI#issuecomment-497023661>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5SJTDMLO4YC4MO26QVYILPX2ZKDANCNFSM4HQOGN5A>
.
|
Linux identifies it as vfat. Is that compatible? Anyhow, I don't think it's a file system issue. Here is what it shows when I enable the code to show state: I'll dig further, but I bet the drive is returning NAKs. If that is the case, then it is the same issue I was seeing before when I tried running UHS3 inside Marlin. This is both good and bad news. It's good news in that it seems like the issue is reproducible outside of Marlin, so my integration work must not the the cause; but the bad news is we still don't know why our drives get stuck in this odd state. And of course it's equally puzzling why UHS2.0 running on 32-bit is able to mount them. The plot thickens... |
|
What kind of USB stick? Try another one?
…On Wed, May 29, 2019, 1:33 PM Marcio Teixeira ***@***.***> wrote:
Format the drive as fat, not ntfs? Also, may take a few moments to mount
the volume.
Linux identifies it as vfat. Is that compatible?
Anyhow, I don't think it's a file system issue. Here is what it shows when
I enable the code to show state:
Start.
USB HOST READY.
USB HOST state 1d
No media. Waiting to mount /
USB HOST state 02
USB HOST state 0a
USB HOST state 03
USB HOST state 0c
USB HOST state f0
I'll dig further, but I bet the drive is returning NAKs. If that is the
case, then it is the same issue I was seeing before when I tried running
UHS3 inside Marlin. This is both good and bad news. It's good news in that
it seems like the issue is reproducible outside of Marlin, so my
integration work must not the the cause; but the bad news is we still don't
know why our drives get stuck in this odd state. And of course it's equally
puzzling why UHS2.0 running on 32-bit is able to mount them. The plot
thickens...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#46?email_source=notifications&email_token=AA5SJTAEQP67YTGAJBBI4GTPX25ABA5CNFSM4HQOGN5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQCONQ#issuecomment-497035062>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5SJTBL67R2BT7F3X5C2W3PX25ABANCNFSM4HQOGN5A>
.
|
|
We have some Lulzbot branded USB sticks that we ship with our TAZ Pros. I've tried a 3rd-party one too and it does not work either, but it fails in a different way. Even if these particular sticks are particularly finicky, we've kind of gotten ourselves in a pickle since we've shipped hundreds of printers with them, so if they suddenly don't work after a firmware upgrade, customers will not be happy. I feel slowly we are learning more and more. I feel this is one of those situations where multiple factors are conspiring to make it a particularly hard to nail down problem. Thank you for the patience with me! |
|
I'll take a look at this tonight and see what I can find out.
…On Wed, May 29, 2019, 1:44 PM Marcio Teixeira ***@***.***> wrote:
We have some Lulzbot branded USB sticks that we ship with our TAZ Pros.
I've tried a 3rd-party one too and it does not work either, but it fails in
a different way. Even if these particular sticks are particularly finicky,
we've kind of gotten ourselves in a pickle since we've shipped hundreds of
printers with them, so if they suddenly don't work after a firmware
upgrade, customers will not be happy.
I feel slowly we are learning more and more. I feel this is one of those
situations where multiple factors are conspiring to make it a particularly
hard to nail down problem. Thank you for the patience with me!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#46?email_source=notifications&email_token=AA5SJTEMKKSTHHDU4Y6S6OTPX26G3A5CNFSM4HQOGN5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQDNDY#issuecomment-497038991>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5SJTDTA3OPD3Z62F64RH3PX26G3ANCNFSM4HQOGN5A>
.
|
|
@xxxajk: I would definitely appreciate it, but again, don't feel you have to take time away from your other projects. You've done quite enough already :) |
|
@xxxajk: Are you able to gleam anything from these debug logs? What stands out to me is the fact that the host seems to be requesting 64 bytes as part of the ctrlReq, but the device only replies with 18 bytes once, then subsequently replies with 0 bytes. It seems like getting zero bytes is an abnormal condition and |
|
I discussed this with one of my co-workers who is fiddling with UHS2.0 and he pointed out that device descriptors are 18 bytes. This jives with what I was seeing above. It seems like this particular drive will only transfer 18 bytes, no more, and UHS3.0 is expecting more. I made a small change to the code: Now, when I run the code with this particular drive, I get something way more promising: So, success! |
|
Just to sort of wrap things up, with this change, UHS3.0 seems to work fine on our Mini 2 (8-bit board) as well as our 32-bit board (TAZ Pro) when using software SPI for the color LCD panel. Trying to use hardware SPI for the color LCD panel crashes the machine, but this is expected due to the fact that UHS3.0 is using interrupts. Earlier you said that wrapping everything up with begin/endTransaction should fix that problem, so I guess that's my next step. |
|
Yes, they are 18 bytes. Last I checked everything worked here. SPI sharing won't be a problem once you guard the remaining SPI code. |
One thing I notice is that "ctrlReq" is called from a lot of places, so my fix of returning success (0) when a short read happens is probably not correct for anything other than descriptors, and even then, it is probably only a success if the drive returns exactly 18 bytes. So could I ask you a favor? Could you look at the code and perhaps come up with a better way of handling the situation? Perhaps look at UHS2.0 and see what is happening there? I imagine the fix will either be requesting only 18 bytes (if that is possible) when reading descriptors, or having a way in which "ctrlReq" can report how many bytes were actually read and then the code for reading device descriptors could treat it as a success if exactly 18 bytes were read, while all other code using ctrlReq would treat short reads as errors. It may well be a quirk of these particular drives, but for maximum compatibility, the code needs to be resilient to known bad implementations out there. I recall reading somewhere that a large part of the driver code in Windows is about working around poor implementations of standards in devices... |
|
Actually, part of the "bad behavior" is because of how older versions of windows did USB. |
|
1: Update RTClib, pushed a fix Please try the following: See if that makes a difference. |
|
Also, what MCU is giving the problem exactly? AVR? ARM? MIPS? |
|
AVR. I'll test UHS_DEVICE_WINDOWS_USB_SPEC_VIOLATION_DESCRIPTOR_DEVICE. You want me to remove my patch and test with UHS_DEVICE_WINDOWS_USB_SPEC_VIOLATION_DESCRIPTOR_DEVICE. Is this correct? |
|
Here's what the startup should look like: At this point, things are ready to roll, and the probe and automount happens. |
|
Yes, with a pure pull, please. |
|
Without UHS_DEVICE_WINDOWS_USB_SPEC_VIOLATION_DESCRIPTOR_DEVICE: With UHS_DEVICE_WINDOWS_USB_SPEC_VIOLATION_DESCRIPTOR_DEVICE: i.e. no change. |
|
The above is what happens using one drive (call it the "black" drive). With the "blue" drive, I get an infinite loop (the following is with UHS_DEVICE_WINDOWS_USB_SPEC_VIOLATION_DESCRIPTOR_DEVICE): Both the black and blue drives appear to be from the same vendor, although one is branded with our logo, and one isn't (I presume it was a sample from the manufacturer). |
|
For what it is worth, one of the drives is labeled "VICFüN". It appears to be these guys: https://www.amazon.com/VICFUN-10pcs-Drives-Sticks-Drive-Black/dp/B00UALPCFW |
|
"COMPATIBILITY AND HIGH PERFORMANCE - plug and use, unplug and go, support Win7/8/10 /Vista/XP/2000/ME/NT Linux and Mac OS, support USB 2.0 and backwards, support TV, speakers with USB slots, support share around" ... it's totally compatible. It even supports share around ;) |
|
It looks like the blue drive is a 4GB, while the black one is 8GB. I also have a 16GB. It behaves like the 8GB: Anyhow, in short, it seems like all the VICFuN drives behave somewhat similarly, but the 4GB has the special wrinkle of getting the code into an infinite loop. I assume they changed the FW in the 8GB and 16GB to eventually return some sort of error to tell the host no more bytes were available. |
|
I have a "Datastick Pro by Centron" and it behaves similarly: |
|
I'll email you the needed details to get the stick to me. This is a deep quirk. |
|
Okay. I'll see what I can do. We only have one of the blue drives, so we're a little reluctant to part with it, but I think if you manage to figure out what is happening with the black drives, it will probably fix it for the blue drive as well. |
|
Pushed something that might work. |
|
Identified as a USB host hardware implementation bug. |
|
@xxxajk: Well, the software fix we came up with solved the problem. No hardware fixes needed. |
|
@xxxajk: I think we may be referring to two separate problems. We were able to solve one of them with the change to UHS_DEVICE_WINDOWS_USB_SPEC_VIOLATION_DESCRIPTOR_DEVICE. The hardware fix was adding a cap to VBUS. Our EE is back in today and I forwarded the suggestion. Anyhow, either way, I think this ticket can be closed. |
I am trying to run the UHS_FS_NEW_DEMO on an Tosduino MEGA 2560 (Arduino Mega compatible) with an Arduino USB Host Shield and it seems to crash during
Init_Generic_Storage(&UHS_Usb);, as shown by this screen shot:One of our engineers had made a small modification to the RESET pin of the Arduino shield, so I had to add the following bit of code to the start of the sketch:
I presume this won't cause a problem, but I thought I would mention it, just in case. I'll try narrowing down where in Init_Generic_Storage the crash is happening.
The text was updated successfully, but these errors were encountered: