UHS30 support for MKRZERO? about uhs30 HOT 8 CLOSED

Technically, it should be able to just work. You will have to specify the SWI IRQ though.
I'll get back to you on what to do in a bit.

from uhs30.

From what I can tell, you have a few choices.
First, if you don't use one of the devices, you can steal the IRQ for SWI.
Unfortunately unlike Freescale and some other chips, Atmel didn't leave any unused IRQ on the NVIC, and will throw a fault.

So, for example, if you don't use I2S, at the very top of your sketch, do the following:

#define SWI_IRQ_NUM I2S_IRQn

Which is what the default is for the Arduino Zero.

from uhs30.

Thanks for the suggestion! Unfortunately it didn't change the behavior at all...
I had already modified dyn_SWI.h to effectively do the same thing by treating ARDUINO_SAMD_ZERO and ARDUINO_SAMD_MKRZERO the same in the ifdefs.

I'll spend some more time tomorrow trying to track down where it's going south. I may revert back to the original lib files and go through the changes I made a little more slowly to see if there's somewhere I dorked it.

Just knowing that the native usb and the UHS3 usb shouldn't interfere with each other is good to know.
Thanks again, and I'll keep plugging at it.

from uhs30.

After another day of beating my head against this I have some interesting observations to report...
I reverted all of the changes I made to the library files (removed my ifdefs for SAMD_MKRZERO) and replaced them with the following defines at the beginning of my sketch:

#define SWI_IRQ_NUM I2S_IRQn
#define UHS_GET_DPI(x) (x)
//#define UHS_GET_DPI(x) digitalPinToInterrupt(x)
//#define STDIO_IS_OK_TO_USE_AS_IS
#define USB_HOST_SERIAL Serial
#define SERIAL_PORT_MONITOR Serial
#define SERIAL_PORT_HARDWARE Serial
#define ENABLE_UHS_DEBUGGING 1
#define UHS_MAX3421E_SS 4
#define UHS_MAX3421E_INT 5

I did still had to make changes in UHS_printf_HELPER.h to get the printf statements to work. I ended up using the same code that was there for CORE_TEENSY. With that change, printfs began emitting to the native serial USB port (when it's working).

I have verified through a simple interrupt test sketch from the Arduino gui that digitalPinToInterrupt() is infact already defined as "( x )" in the MKRZERO core libs, so either of the above defines for UHS_GET_DPI(x) should work the same...

Recall that my main 'sketch' is a copy of the UHS_HID_KB_MOUSE.ino converted to a .cpp file for compilation with Eclipse. With the defines above added to the sketch I see the same behavior I was seeing yesterday with the code causing the native usb port to break.
I started commenting out bits to see if I could narrow down what exactly was causing the corruption. First indication was the instantiation of UHS_HID was causing the problem, then I moved deeper into that class and eventually determined it seems to be this line in the UHS_HID DriverDefault method:

epInfo[i].bmNakPower = (i == epInterruptInIndex) ? UHS_USB_NAK_NOWAIT : UHS_USB_NAK_MAX_POWER;

and (very oddly) it seems to be the reference to epInterruptInIndex that is causing the problem. I cannot understand how or why, but if I replace epInterruptInIndex with '1' (it's constant value) then the native usb port is no longer corrupted at startup (it does go corrupt later when a USB device is plugged in though).
I did a "gcc -E" on the main file to see what all of the macro expansions exploded out to, thinking maybe there would be something that would jump out. There appears to be nothing odd with epInterruptInIndex - it's simply a constant int on the UHS_HID class?
Any access of epInterruptInIndex appears to cause the corruption (it's not the values going into epInfo[i].bmNakPower that are causing the issue)...

I'm frankly at a loss as to why accessing epInterruptInIndex would be a problem, but that appears to be the root of the corruption I'm seeing?

As another/further testing, I setup and ran the board_qc.ino sketch from USB_HOST_SHIELD/examples, and that (when modified with the additional #defines) seems to run correctly with my setup. It doesn't corrupt the native usb port, and detects USB devices being plugged in and removed. Of course, it's not using the USB_HID classes either... But I do believe that it's evidence the hardware is actually talking to each other (the SPI) and the interrupt is being properly setup and can be responded to.

One other thing I'll throw out is that I am seeing 3 linker warnings whenever I compile with this library:

arm-none-eabi/bin/ld.exe: warning: changing start of section .bss by 240 bytes

Google searches seem to indicate this is a warning that can be safely ignored, but I mention it anyway in case it sparks a thought...

from uhs30.

If the QC code works, then everything is fine code-wise.
Have you tried a different keyboard? Some do fail because the keyboards do something odd.
Try also one of the other examples. If those work, then you can blame the particular keyboard. It may have a quirk. Also some additional work has been done to fix enumeration quirks, which could be affecting you as well.

from uhs30.

I can't see how it can be a keyboard hardware issue, when the native usb port dies on program start, even when the keyboard isn't plugged in. But I went ahead and tested with another keyboard (and a mouse) and saw the same results. I did a bunch more testing and got it to work at one point by replacing all references to UHS_HID.epInterruptInIndex and epInterruptOutIndex with hard-coded 1s and 2s. But that was when I building from the fully expanded source (gcc -E, made mods, then compiled that)... When I folded those changes back into the original lib files, it failed again... Not 100% certain I hadn't made some other changes in the expanded source that I subsequently lost though. I suspect there is an addressing problem somewhere in the USB_HID classes, but it's certainly not jumping out at me where...

I tried building and running the UHS_FS_NEW_DEMO sketch but that relies on some version of RTClib that I seem unable to track down (doesn't seem to be the version of RTClib hosted by the standard arduino lib manager?).

I think I have one last thing I'm going to try and that is to load the example sketch in the actual arduino tool (even though I totally hate using that) to see if perhaps it has something to do with the Eclipse build environment I'm using....

... Ok, I'm seeing exactly the same results from the arduino gui (v1.8.9). I can run the board_qc sketch, but the UHS_HID_KB_MOUSE sketch causes the native usb port to no longer connect with the host computer.

I think at this point I'm just going to give up on this lib and stick with my fork of USB_HOST_SHIELD_2.0 (with USB and UsbDevice renamed to avoid conflicts with the native USB libs on MKRZero).

Thanks for taking the time to try to help me out here, and best of luck getting UHS30 completed. If there is anything you'd like me to do to try to further document the issues I'm seeing on the MKRZero (either now or in the future) just drop me a line and I'd be happy to help...

from uhs30.

from uhs30.

Nope, no need to hardcode. It figures the endpoint direction based on the
8th bit.

Have to say, I feel like we may be talking past each other here... My fiddling with the epInterruptIn(Out)Index attribute references was simply because it seems like accessing those attributes (at runtime) seems to be causing the native usb port to become corrupt. Can't say I understand why, or even have a theory at this point, but it does seem to be the case...

You didn't clone the repo properly. 8-) see installation note at bottom of
readme.

Yep - I missed the submodule on my initial clone. Re-cloned and have it now.
Gave UHS_FS/examples/USB_HOST_SHIELD/UHS_FS_NEW_DEMO a shot and the good news is that it doesn't corrupt the native usb port, but it also doesn't appear to function (with my setup). I get the following on the console:

Start.

SWI_IRQ_NUM 27

USB HOST READY.
No media. waiting to mount /
BS SetInterface

then nothing else. I'm using a fairly new SanDisk Ultra USB 3.0 16GB thumb drive.

I suspect the root cause of the problems I'm seeing are probably interrupt related. When the drive is not present the INTR line from the MAX stays HIGH (which I'm assuming for the moment is inactive). Once the drive is presented there is activity on the INTR line (1ms pulses low), then it is left in the LOW state. So, I'm guessing that there may be some problem with the MKRZero interrupt handling routines that either manage to miss an interrupt, or manage to not reset the request from the MAX...

from uhs30.