yeahtuna
Senior Member

As far as I can tell, readSectorsCallback() is still forcing the user to wait. It would probably be more useful it was a non-blocking operation that triggered the callback when the read was complete.

Are readSectorsCallback() and its related methods being used?

I managed to make it so that commands are initiated in user code (the first call queue_Data_Transfer), but then all the subsequent calls related to the command are handled in the callbacks. Seems to work nicely. I'll...

Ya, I agree that user code should have to wait while the data is read / written. Things would get pretty messy otherwise. In my non-blocking USBDrive init, I do the initialization as a state machine inside of Task()...

Congratulations.

I'll try it out today, but I feel like it's using duct tape to fix a problem. Obviously commands need to begin in user code, but subsequent calls to queue_Data_Transfer should probably be done inside the callbacks so...

Thank-you so much. This fixes the issue for me. I can't tell you how many hours I have spent pouring over the UBSHost code desperately trying to fix this issue.

What about.movimg.the calls to msGetCSW() to the input or output callbacks. Wouldn't that be safer?

I'm about to go to bed, but I also noticed that the MassStorageDriver is currently not checking for stalled transfers, instead treating them as complete. If a transfer is stalled, don't we need to retransfer?

Is the solution to the problem to ensure that all transfers are queued in the isr()?

I do need BigBuffer. A tested using several months ago using MIDIDevice, and was the same problem with the hub. I actually came up with a workaround get the hub working again, but not a proper fix. Of course it's...

Thank-you again for taking the time to test. I've been making posts for months trying to get help resolving these issues, but few seem to really care. Much appreciated. The 'solution' I mention in post #750 is not...

I've found something. If a delay is added before a transfer is removed from the async followup list, the test completes reliably. Sounds like the issue is might be that we are calling queue_Data_Transfer() while...

I suspect if you comment out the lines that queue a transfer in claim() midi.cpp, the hub will denounce properly when you remove the drive. // if an IN endpoint was found, create its pipe if (rx_ep && rx_size <=...

I just tested with a powered hub and the result is the same.

Can you confirm that the device connected to your computer is T3.6 and the speed is set to 180 Mhz? No, I'm not testing with a powered hub at the moment.

I also conducted the test with T4.1 as the device connected to the computer, and it ran without issue.

Alright. I've found something else. If I reduce the speed of the T3.6 connected to the computer from 180 Mhz down to 96 Mhz, the test always completes.

@mjs513 I performed your test as best I could---I was still using T3.6 devices. I performed the test 10 times, each time I power cycled the teensy connected to the computer, leaving the hub, flash drive, and second...

You're talking about this code? if (stat & USBHS_USBSTS_UAI) { // completed qTD(s) from the async schedule println("Async Followup"); //print(async_followup_first, async_followup_last); Transfer_t *p =...

Thanks for taking the time to test. I appreciate others taking this issue seriously. The reason your test doesn't hang is because your MIDI device connected to the hub is constantly sending MIDI. The Mass Storage...

So, correct me if I'm wrong, but it seems that MIDI devices queue transfers that only complete once a MIDI event is received. So any other transfers that are queue by other drivers won't get called until after a MIDI...

If lines 194 and 195 in midi.cpp are commented out, then the test completes. https://github.com/PaulStoffregen/USBHost_t36/blob/69b90727a5b028699b47910aa5cd6a0823de5f69/midi.cpp#L194

The build type is MIDI.

Thanks for the reply, KurtE. The RawHID was a red herring. I know all hubs are not created equal, and I tested with a few more hubs and could not reproduce the issue. The second test with the devices set to USB MIDI,...

Here's a sketch to show that the USB Host MIDI driver is causing the Mass Storage driver to fail. Both teensy devices should be running the same sketch included below. If the test is performed without the second...

That is not the serial port, and it's just an illustration to get the idea across. The first teensy is of course attached to a computer. It looks like the real culprit is the MIDI driver. I'll post an updated test.

Tried with a different USB hub and it seems to be working fine.

Here is a minimal setup to cause the MassStorageDriver to fail. Both teensy devices should be running the same sketch included below. If the test is performed without the second teensy connected to the USB host...

It's not just you. This probably explains the problems I'm seeing. I have a hub / MIDI / rawUSB also running concurrently, so my device is putting ehci through its paces. Sometimes a drive will timeout during...

That's my point. From the perspective of msGetCSW(), the value of .Tag doesn't change and when it gets to this point: if(StatusBlockWrapper.Tag != CBWTag) It seems to me that there's a chance that the real value...

But after the call to queue_Data_Transfer() completes, the value of StatusBlockWrapper.Tag is still 0, and its value is only updated outside of the scope of msGetCSW().

I opened an issue on github in regards to possible erroneous CommandBlockStatus.Tag errors here: https://github.com/PaulStoffregen/USBHost_t36/issues/113 Is my logic incorrect? Can we be sure that the compiler...

I should also mention that some of these kinds of issues will disappear when printing debugging information as that often forces the code to reload the value, so make sure you also test without debugging enabled.

I have sorted out a few issues that I was seeing with CSW tag errors. I wouldn't be surprised if you are running into the same issues I was seeing where the code wouldn't reload Command wrapper.tag, instead just using...

I've spent weeks going over the MassStorage code and have pointed out several issues, but the maintainers of the code haven't attempted to fix them. Some of the issues are very simple fixes, others are much more...

:) Doubtfully, but I want to know the limits. I'm more interested in the touchscreen I've got going on this RnD device. Just playing around.

To answer my own question, you don't need to change how the buffers are setup. I was trying to draw transparency by changing the alpha channel of an RGB32 color. Instead you draw transparency by including an extra...

I've started porting my desktop graphics library over to Teensy 4.1 with the help of this wonderful library. I'm trying to draw with transparency. Do you have a simple of example of setting up the buffers?

I'm pretty sure it does. The crash I was experiencing comes from a bug, which is fixed in the code below: void USBFilesystem::end(bool update_list) { mscfs.end(); //if (update_list)...

I found an issue with some USB Flash devices, and I'm not sure fix it. Apparently some devices with issue a STALL when you request getMaxLUN(). In that case we need to reset somehow, and I'm not entirely sure how that...

It's particularly frustrating when it works on one platform and not not the other. Today I rewrote the USB drive begin() function as non-blocking. It takes care of the system hanging when first opening a drive. Still...

Sadly, this solution doesn't seems to work on Teensy 4.1. Back to the drawing board.

Indeed I have. I got pretty cool RnD device that should keep me busy for a while. It's SD card, host port, touchscreen, audio, a digital port extender, SPI ADC, buck regulated DC in....Lots to learn.

So I had a quick test with my new prototype and it looks like SD card is the way to go--must faster then USB memory. I was able to playback 32 simultaneous stereo tracks using 8K buffers. Which should allow me to...

I finally have first audio!

I'm playing around with TeensyThreads.h. Looks the perfect companion to this library if you want non-blocking functionality.

Here's what I used a starting point for my USB host port firmware updater. https://forum.pjrc.com/threads/47783-Teensy-programs-Teensy?p=321170#post321170

Fixed. My issue was unrelated to your code, which continues to perform well.

My setup is quite different. I'm streaming the firmware via rawHID from an application on a computer, through a master unit (T3.6 or T4.1) to a device connected to the master's USB host port. I didn't use Paul's...

I'm so happy to report that I solved the issue. #define RAWHID_RX_SIZE 64 // 32 works fine for T3.6, but not T4.1 A few notes about your driver, Paul. I think you'll find that if you implement a minimum wait time...

One more question, Paul. Is is safe to assume that after we call bootloader.write() and the control callback comes back 'Complete', we can reuse / free the memory location passed to bootloader.write()?

Thanks, Paul. I had a quick look over the code and it's basically the same process as before, so I must be dealing with some sort of hardware issue. Considering how much attention you are paying towards the proper...

Paul, I really need this working on a T4.1. I've been studying the USB protocol and the code in ehci.cpp all day, looking for where things go wrong, but I'm stumped. I know you are busy, and I don't expect you to...

When I use T4.1 as master, it looks like the teensy connected to the Host port programs properly, but in fact it doesn't. All the packets are sent, nothing times out, but the device doesn't reboot (the program doesn't...

I see. Then my problem must be hardware related. Thanks.

The link is broken, Frank B. Is the code still available somewhere? Using a T3.6 I can program 3.x and 4.x devices fine. But using T4.1 as master always fails.

I think I've finally gotten it resolved. What a headache. I'll report back after I've sure the fix I'm using works properly.

I've spent about 8 hours now trying to get to the bottom of this. Ultimately the problem is that the hub issues a queue_Control_Transfer, but the associated callback is never called. I can detect when this happens,...

Alright. Thanks.

I can program a T3.x and T4.1 froma T3.6. I did indeed need to increase the wait time for erasing the T4.1 chip. The problem I'm seeing is programming T3.x from a T4.1 device. It looks like it works--all the blocks...

Sorry for bringing up an old thread, but I've been using a variation of this for years. Now I'm moving to T4.1 based devices and I'm experiencing issues. Did you have any troubles modifying this code to work for T4.1...

I've been looking around at some other USB_Host stuff and it occurs to me, that we should be able to rewrite the begin() method as a state machine so that it's non-block. begin() could be a void method signals to the...

Do what you want with this. I don't mind if you don't want to use it. Here's the updated section of USBHost_t36. class USBDrive : public USBDriver, public FsBlockDeviceInterface { public: USBDrive(USBHost &host) {...

I've got it rock solid now... Very snappy, and no lockups even with LTO. I had to make quite a few changes. When I have more time, I'll zip the library up and send it to you.

I now have things very stable. 15 low voltage power cycles in a row without a lockup. The last issue I found that was causing a lock-up is related to compiling with link time optimization. I haven't been able to...

I found another issue in claim. datapipeIn = new_Pipe(dev, 2, endpointIn, 1, packetSizeIn, intervalIn); datapipeOut = new_Pipe(dev, 2, endpointOut, 0, packetSizeOut, intervalOut); //need to...

I've been working through a few more lock ups. I really think every single time you send or receive data to the flash drive there needs to be some kind of timeout implemented. I'm implemented this function: bool...

Also worth mentioning that after the USBFilesystem fails during begin, I need to call the end() method; otherwise its boolean value wouldn't return to false. Seems like it should automatically be false it it fails to...

So I've swapped in a TPD3S044DBVR, and it's still no go. The only way I can get that drive up and running is to connect it to a powered USB hub plugged into the USB port. No big deal. But this brings to light a...

Problem solved A17 is not located at N3. Unfortunately SD_B1_05 looks too similar to AD_B1_05. I'll get it in the next try.

This is just to confirm that it's working to control my 4 quad digipots. I used to use SPI with CS pins, which worked out to 6 pins total. Nice to see that I can now accomplish the same thing using just 2 digital pins...