I have very similar results with the M0 version: Adafruit LoRa Feather -> Gateway
If both the M0 and 32U4 platforms have the same or similar issues, then i suspect the LMIC library might be to dependent on the Atmega328P. Has anybody got it working on an non Atmega328P processor?
I have some issues with the M0 and outputting to serial port. This makes it very hard to debug. I have spent many hours trying to figure it out, but no luck.
Same here @sillevl 
very hard to generate debug info on the serial interface, and also tried blinking the onboard LED to see where things get stuck but that only makes it more unstable…
But then @Galagaking has got it working on this architecture, so there is hope. There is only very little configuration to do to get it running out of the box, so where do we go wrong…?
To create even more mystery on it for you guys: the same setup is working for me on a M0 feather! I got messed up with several LMIC versions, I have cleaned up all my libraries, did a re-install of Arduino IDE. I did have problems with Visual Studio to create a working setup. May be you can look at that? Downloaded the library from @matthijs as mentioned above , change pin numbers, and it works. I use a breakout board for the RFM95, so I connected in another way. M0 / 32u4 setup is the same:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {5, 6, LMIC_UNUSED_PIN}, //
};
The first OTAA cycle will last long (3-4 mins), but then I sent every minute a frame without a problem. Hope this can be helpful.
@sillevl , The M0 serial port IS terrible. I switched to Serial1, connecting via a normal FTDI connector and not through this USB simulation stuff. Replace all the Serial statements with Serial1 and (debug) life is a lot easier!
@Galagaking I will try if your pinmapping makes the difference (this weekend). Will update with the results.
Did you change the spi fequency in the hal.cpp file? I have some FTDI breakout boards, will try that again as well.
Yes !!! Success
I have the ABP demo working using the following pinmap.
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {3, 6, LMIC_UNUSED_PIN},
};
The SPI frequency is set to 8Mhz in the hal.cpp (will try default 10Mh value later).
The only extra connection I needed was to connect DIO1 to pin D6.
I will try the OTAA example later on.
Congrats! Had some thoughts about your problems. I use 10E6 (default) in hal.cpp, because i did a new start with the clean LMIC library. The Serial / USB port emulation was driving me mad. So I changed everything to Serial1 (connect FTDI to RX0, TX0). For experimenting my ‘wifi FTDI’ ESP8266 Serial to Wifi setup was extremely helpful (https://github.com/jeelabs/esp-link). By debugging this way, things were much more stable. I think there is some interference between the USB / Serial code and LMIC. At this moment my node only stops when the LIPO is empty! Cheers
For me still no luck, while I seemingly have totally identical setup to @sillevl : same pin mapping, same HW connection from DIO1 to D6, using ABP, SPI clock changed to 8E6… And still it only sends data once and then stalls… Driving me nuts! 
@iot-partners did you remove all the references to Serial? I changed them all to Serial1 and used an FTDI breakout board as external Serial to USB converter. I am not sure, but I think this makes the difference.
I did not change to serial1 yet but I did take out all references to serial. No effect…
I have a rather short connection from DIO1 to D6. Could crosstalk from the RF-signal be a problem?
Victory!!!
Out of frustration, I bought an M0, and I got it running within a minute! So there is definitely a problem with this software running on the 32u4 architecture. It’s not the serial interface, because I took all of that out already and it gives the same issue.
After a lot of debugging and trial and error (and some expletives), I finally got it working on a Feather 32u4 as well:
According to the schematics of the Feather 32u4, DIO0 is connected to digital pin 7. For the M0 version, DIO0 is connected to digital pin 3. So in the initialization for the Feather 32u4, I used .dio = {7,6,LMIC_UNUSED_PIN}. I have connected IO1 to digital pin 6 with a wire bridge.
My first statement in void setup() is delay(1000). Without this delay, I get the same results as @iot-partners
I got my 32U4 to work as well with this tip!!!
Who would have thought it to be an initialization problem! 
Thank’s a lot for this short, but very usefull post !
I’m trying to OTAA a Adafruit 32u4 Feather.
I seem to have the correct pinout with help from this thread:
I’m running into a consistent “EV_JOIN_FAIL” when using OTAA.
When I try and do ABP it prints "EV_TXCOMPLETE (includes waiting for RX Windows)…and then packet queued.
Any suggestions on how to troubleshoot this? Is it likely a problem with the keys?
Thanks!
I also have a Adafruit Feather 32u4 LoRa Radio up and running based on the “IBM LMIC framework” library included via the Arduino IDE. It seems this originates from Matthijs Kooijman’s work for Arduino platforms.
// Pin map for Adafruit Feather 32u4 LoRa
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = 4,
.dio = {7, 6, LMIC_UNUSED_PIN},
};
I have connected IO1 to digital pin 6 with a wire bridge.
I modified the code to join TTN using OTAA.
But now I experience a strange behaviour:
The gateway is located in a room next to me - why does it obviously need SF10 in order to enable the node to actually receive the response from TTN? I would possibly understand if the gateway would be located far away from the node, but it isn’t.
Is this possibly an issue of the timing of the join receive windows in the nodes? It is hard to believe that the code provided by Matthijs Kooijman really works for each and every Arduino based hardware. Is there some place in the code where these receive windows need to be adjusted?
5539776: WK --- IRQ Handler 0 // Join message #1 sent
10548152: WK --- IRQ Handler 1 // Receive timeout in join receive window 1 (5s)
11754072: WK --- IRQ Handler 1 // Receive timeout in join receive window 2 (5+1s)
21323944: WK --- IRQ Handler 0 // Join message #2 sent
26332368: WK --- IRQ Handler 1
27538304: WK --- IRQ Handler 1
42022208: WK --- IRQ Handler 0 // Join message #3 sent
47037272: WK --- IRQ Handler 1
48236584: WK --- IRQ Handler 1
66233032: WK --- IRQ Handler 0 // Join message #4 sent
71248144: WK --- IRQ Handler 1
72447408: WK --- IRQ Handler 1
77584832: WK --- IRQ Handler 0 // Join message #5 sent
82613200: WK --- IRQ Handler 1
83799200: WK --- IRQ Handler 1
113588872: WK --- IRQ Handler 0 // Join message #6 sent
118617336: WK --- IRQ Handler 1
119803320: WK --- IRQ Handler 1
161840632: WK --- IRQ Handler 0 // Join message #7 sent
EV_JOINEDThe LMIC code is quite portable.
The only issue I had was when using a less accurate clock.
You could try adding
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
Thank you, adding the following line actually made the “join” work with the first attempt. That’s great.
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
Again, this is my working pin map for Adafruit Feather 32u4 LoRa
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = 4,
.dio = {7, 6, LMIC_UNUSED_PIN},
};
I have connected IO1 to digital pin 6 with a wire bridge.
I need to mention that I also fetched a new clone from https://github.com/matthijskooijman/arduino-lmic as the library I was working with was not up to date, didn’t have built in the MAX_CLOCK_ERROR code.
Strange code: LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
The compiler will optimize out (and therefore ignore) the “* 1” which leaves you with LMIC_setClockError(MAX_CLOCK_ERROR / 100);