USB Host Shield based on MAX3421E interfacing with ATTiny 1634 problems

I am trying to interface the USB host shield with ATTiny1634MUR in QFN20 package and I am facing problems. I am using (https://github.com/felis/USB_Host_Shield_2.0) library for the USB host shield and have added the pin and board definition in USB libraries.

My USBcore.h file looks like this-

/* shield pins. First parameter - SS pin, second parameter - INT pin */
#ifdef BOARD_BLACK_WIDDOW
typedef MAX3421e<P6, P3> MAX3421E; // Black Widow
#elif defined(CORE_TEENSY) && (defined(__AVR_AT90USB646__) || defined(__AVR_AT90USB1286__))
#if EXT_RAM
typedef MAX3421e<P20, P7> MAX3421E; // Teensy++ 2.0 with XMEM2
#else
typedef MAX3421e<P9, P8> MAX3421E; // Teensy++ 1.0 and 2.0
#endif
#elif defined(BOARD_MEGA_ADK)
typedef MAX3421e<P53, P54> MAX3421E; // Arduino Mega ADK
#elif defined(ARDUINO_AVR_BALANDUINO)
typedef MAX3421e<P20, P19> MAX3421E; // Balanduino
#elif defined(__ARDUINO_X86__) && PLATFORM_ID == 0x06
typedef MAX3421e<P3, P2> MAX3421E; // The Intel Galileo supports much faster read and write speed at pin 2 and 3
#elif defined(ESP8266)
typedef MAX3421e<P15, P5> MAX3421E; // ESP8266 boards
#elif defined(ESP32)
typedef MAX3421e<P5, P17> MAX3421E; // ESP32 boards
#elif (defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__))
typedef MAX3421e<Pb4, Pb3> MAX3421E;
#elif (defined(__AVR_ATtiny1634__))
typedef MAX3421e<Pa6,Pa5> MAX3421E;
#else
typedef MAX3421e<P10, P9> MAX3421E; // Official Arduinos (UNO, Duemilanove, Mega, 2560, Leonardo, Due etc.), Intel Edison, Intel Galileo 2 or Teensy 2.0 and 3.x
#endif 

My avrpins.h looks like this-

#elif defined(__AVR_ATtiny1634__)
#define P1 Pa6
#define P2 Pa5
#define P3 Pa4
#define P4 Pa3
#define P5 Pa2
#define P6 Pa1
#define P7 Pa0
//#define P8 Pa4
//#define P9 Pa4
#define P10 Pc5
#define P11 Pc4
#define P12 Pc3
#define P13 Pc2
#define P14 Pc1
#define P15 Pc0
#define P16 Pb3
#define P17 Pb2
#define P18 Pb1
#define P19 Pb0
#define P20 Pa7

My USBhost.h looks like this-

/* SPI pin definitions. see avrpins.h   */
#if defined(PIN_SPI_SCK) && defined(PIN_SPI_MOSI) && defined(PIN_SPI_MISO) && defined(PIN_SPI_SS)
// Use pin defines: https://github.com/arduino/Arduino/pull/4814
// Based on: https://www.mikeash.com/pyblog/friday-qa-2015-03-20-preprocessor-abuse-and-optional-parentheses.html
#define NOTHING_EXTRACT
#define EXTRACT(...) EXTRACT __VA_ARGS__
#define PASTE(x, ...) x ## __VA_ARGS__
#define EVALUATING_PASTE(x, ...) PASTE(x, __VA_ARGS__)
#define UNPAREN(x) EVALUATING_PASTE(NOTHING_, EXTRACT x)
#define APPEND_PIN(pin) P ## pin // Appends the pin to 'P', e.g. 1 becomes P1
#define MAKE_PIN(x) EVALUATING_PASTE(APPEND_, PIN(UNPAREN(x)))
typedef SPi< MAKE_PIN(PIN_SPI_SCK), MAKE_PIN(PIN_SPI_MOSI), MAKE_PIN(PIN_SPI_MISO), MAKE_PIN(PIN_SPI_SS) > spi;
#undef MAKE_PIN
#elif defined(__AVR_ATmega1280__) || (__AVR_ATmega2560__) || defined(__AVR_ATmega32U4__) || defined(__AVR_AT90USB646__) || defined(__AVR_AT90USB1286__)
typedef SPi< Pb1, Pb2, Pb3, Pb0 > spi;
#elif  defined(__AVR_ATmega168__) || defined(__AVR_ATmega328P__)
typedef SPi< Pb5, Pb3, Pb4, Pb2 > spi;
#elif defined(__AVR_ATmega644__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__)
typedef SPi< Pb7, Pb5, Pb6, Pb4 > spi;
#elif (defined(CORE_TEENSY) && (defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__MKL26Z64__))) || defined(__ARDUINO_ARC__) || defined(__ARDUINO_X86__) || defined(__MIPSEL__) || defined(STM32F4)
typedef SPi< P13, P11, P12, P10 > spi;
#elif defined(ARDUINO_SAM_DUE) && defined(__SAM3X8E__)
typedef SPi< P76, P75, P74, P10 > spi;
#elif defined(RBL_NRF51822)
typedef SPi< P16, P18, P17, P10 > spi;
#elif defined(ESP8266)
typedef SPi< P14, P13, P12, P15 > spi;
#elif defined(ESP32)
typedef SPi< P18, P23, P19, P5 > spi;
#elif defined(__AVR_ATtiny1634__)
typedef SPi<Pc1,Pb1,Pb2,Pa6>spi;
#else
#error "No SPI entry in usbhost.h"
#endif

Is there anything else that has to be added to these libraries/header/C files. If anyone could suggest how to go forward or give some advice, it would be really helpful.

Thanks,
Akash.

[SpenceKonde]

Edited in code tags so underscores around compiler-supplied defines wouldn't get turned into markup.

Quite frankly that is some of the ugliest code I have ever seen. I can't tell why he feels a need to do all that wacky macro stuff other than to proove how clever he is by making abominations like this that nobody else can extend. I choose not to venture down that rat hole. Do you know what kind of resources it requires at the end of the day? Hsve you built it for something more common? Will it build for a 328p? Build it for something that it already had full support for, see how much ram and flash it uses, that may give you the answer you don;t wabnt about the prospects, but at least you'd get it quickly.

That code is doing wacky things that seem utterly unnecessary and inappropriate and I cannot fathom why he is doing them.

I am using a commonly used USB host shield made for Arduino UNO and It's working with the ATMega328P on the Arduino UNO.
Github repo which has the USB library ((https://github.com/felis/USB_Host_Shield_2.0)) does not support ATTiny1634 but I have added the board and pin definition for the SPI pins and so on.
Is there something else for ATTiny that I need to define or add to get it to work?
Code uses around 15-16 Kb(98%) of flash memory.

On a digital Oscilloscope I am getting the SCK pulses, Slave select, MISO pulses but I am not getting the MOSI pulses. USB host shield is based on SPI protocol, where the ATTiny needs to act as master and MAX3421E(USB shield) has to act as slave for SPI.

[SpenceKonde]

The miso pulses? those would be pulses coming from the host shield? I would double-check by disconnecting miso, from the host shield and verifying  (by putting scope probe on the wire that is now connected to only the ATTiny. If you see pulses there, then you have MOSI and MISO reversed.) that the "MISO" pulse is actually coming from the ATTiny, and is what should be the MOSI I

If it has managed to pull in the included version of the SPI (as opposed to implementing a software SPI, (it's easy enough to do that's it's plausible - have seen libraries that do that when they can't find a normal SPI port)) , you're using the USI , a USI does not have a MISO or MOSI, it has a DI and a DO (notice on the pinout chart how the legend says the blue color of the miso/mosi which uses the hardware USI to get something that's kind of like an SPI port only worse in every way. (this doesn't have a real hardware SPI implementation, only the tiny88 and tiny 841 of the classic tinies have real SPI, the rest have this USI (I had to look into how it worked once - oh my god it is a garbage peripheral! I have great respect for the people who wrote the USIWire and tinySPI libraries. That peripheral is just awful to work with,

Crap communication peripherals - yet another thing I don't miss when working on the "modern"(megaTinyCore,, where I have been doing a lot more development lately. I do try to tell describe this on the part-specific doc page

[SpenceKonde]

https://github.com/SpenceKonde/ATTinyCore/blob/master/avr/extras/ATtiny_1634.md#spi-support

Now, DO is MOSI and DI is MISO and on the oscilloscope I am getting all the pulses. On the the ATTiny, I am printing the USB data using software serial. However, when I try to connect USB device to the Host shield, the ATTitny controller most likely gets reset as it stops sending serial data.
When I remove the connection which ties the RESETS of both (USBHost-MAX3421E and ATTiny), and then reset the ATTiny, it starts sending serial data again. And when I connect back the RESETs of both (USBHost-MAX3421E and ATTiny), the ATTiny continues to print data on serial but USB device does not get connected.

[SpenceKonde]

I wonder if it's related to the software part of software serial? You have not one, but TWO real full fledged hardware serial ports. They're just plain better than software serial and much less of a source of problems (because software serial requires the processor's undivided attention, while hardware serial can send in the background while the chip is putting most of it's attention towards something else (like, say, talking to a USB host shield? Also, have you confirmed it isn't a power problem? (ie, supply glitch when new load is connected)? Those are my thoughts at least - but I think you're getting into the sort of territpory where someone who was more familiar with the USB shield and the library and what sort of issues different symptoms suggestwould be better placed to help with...

[SpenceKonde]

Closing as not a defect in the core, I will still see responses - but this is getting out of my area of expertise, other than to reccommend that you just say no to software serial,. (wanting a decent tiny with hardware serial is why I started maintaining cores in the first place!)

It was a memory issue, removed software serial. The controller was halting because it was out of RAM.