Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

3.1.0 breaks example ttn-otaa-feather-us915 - M0 stuck? #548

Closed
pomplesiegel opened this issue Mar 3, 2020 · 12 comments
Closed

3.1.0 breaks example ttn-otaa-feather-us915 - M0 stuck? #548

pomplesiegel opened this issue Mar 3, 2020 · 12 comments
Assignees
@terrillmoore
Labels
bug

Comments

@pomplesiegel
Copy link

pomplesiegel commented Mar 3, 2020 •
edited
Loading

tl;dr: The example works on a Feather M0 900Mhz with v2.3.2, but not with v3.1.0.

First: Huge fan of this project and eternally grateful for everyone's hard work. Thank you very much.

Quite excited about v3.1.0, but this release (and tags before it + code pushes after it) don't seem to be working on my custom M0 board nor a Feather M0 i just took out of the box.

I'm wondering if this is related to issue #542 but I am trying not to make any assumptions.

To get back to basics and isolate the issue, I am just running the "ttn-otaa-feather-us915.ino" example, adding in only my keys on a Feather M0 LORA 900Mhz.

Raw captures from both sw versions:

v3.1.0

Here is the output and a picture of TTN console
Both the serial logs and the TTN output get stuck here indefinitely:

12:24:46.570 -> Starting
12:24:46.570 -> Packet queued
12:24:46.570 -> 313343: EV_JOINING
12:24:46.570 -> 313419: EV_TXSTART

image

v2.3.2

In contrast, things work as expected with this existing version

12:22:58.235 -> Starting
12:22:58.272 -> Packet queued
12:22:58.272 -> 313352: EV_JOINING
12:22:58.272 -> 313430: EV_TXSTART
12:23:03.724 -> 654533: EV_JOINED
12:23:03.724 -> netid: 19
12:23:03.724 -> devaddr: <>
12:23:03.724 -> AppSKey: <>
12:23:03.724 -> NwkSKey: <>
12:23:03.724 -> 654759: EV_TXSTART

image

Environment

  • LMIC = v.3.1.0
  • Arduino IDE 1.8.12
  • Adafruit SAMD board v1.5.11 + Arduino SAMD board 1.8.5 (installed using Arduino IDE)
  • TTN
  • US915
  • Adafruit Feather M0 LORA (includes radio)

Any thoughts? I'm happy to provide more info if it would be helpful.

Thank you!
@pomplesiegel
Copy link
Author

Another detail: The same behavior occurs both when joining a "The Things Gateway" gateway or "Multitech Conduit"

@terrillmoore
Copy link
Member

This looks more like #523. It could possibly be the lack of DIO1 to D6 for the "out of the box Feather". To rule out #523, you could try reverting 306330f. Also, please list your Adafruit BSP version. I had reports of a recent Adafruit BSP breaking things which I didn't investigate because they switched to the MCCI BSP.

The root cause of all these problems is the interrupt disable in os_radio() (#524).

With code without 306330f, it didn't hang for me, but I got grossly inaccurate times (as measured externally). As soon as I can get a few free days, I'll correct #524, but I'm extremely busy with another project right now.

@pomplesiegel
Copy link
Author

@terrillmoore, thanks so much for jumping on this.

I tried reverting just 306330f but there are conflicts in hal/hal.cpp. Please advise what I should include.

Regarding the BSP, I believe it is 1.5.11 (I had the same behavior with 1.5.10). Screenshot below to confirm this is the right value:
image

BTW: Are you recommending an alternative wiring pattern for the Feather (or more generally, a RFM95W to a atsamd21g18) for better performance/compatibility? Perhaps I misunderstood.

@terrillmoore
Copy link
Member

No, just pointing out that the Adafruit Feather M0 is missing a critical connection for the LMIC: DIO1 from the SX1276 is not connected to anything. See the README.md for more info. The LMIC for the Feather M0 assumes that someone has wired DIO1 to D6, but the user has to remember to do that.

@pomplesiegel
Copy link
Author

Got it. Thank you for the clarification.

OK, sounds good. I will plan to use 2.3.2 until the interrupt issue is addressed. No problem.

@KiwiGonzales
Copy link

KiwiGonzales commented Mar 22, 2020 •
edited
Loading

No, just pointing out that the Adafruit Feather M0 is missing a critical connection for the LMIC: DIO1 from the SX1276 is not connected to anything. See the README.md for more info. The LMIC for the Feather M0 assumes that someone has wired DIO1 to D6, but the user has to remember to do that.

I have the same problem with 3.1.0 - but I've connected D01 and D6 with a wire. But even with that it doesnt works.
With 3.0.99 it still works

@trlafleur
Copy link

Same issue here... works fine with older versions, not with 3.1.0...

@pomplesiegel
Copy link
Author

I just tested and things still work for me using the tagged release
https://github.com/mcci-catena/arduino-lmic/releases/tag/V3.0.99.6

however, things break with the next release
https://github.com/mcci-catena/arduino-lmic/releases/tag/v3.0.99.10

@terrillmoore terrillmoore mentioned this issue May 11, 2020
Merged
terrillmoore added a commit that referenced this issue May 12, 2020
@terrillmoore
Merge pull request #571 from mcci-catena/issue568
0e67c4e 
The primary purpose of this PR is to fix #524, allowing the LMIC to run without disabling interrupts at all, and without requiring any changes to underlying BSPs. When configured for interrupts, interrupts simply cause the current time stamp to be captured. The secondary ISR is run as part of os_runloop_once(). This should also fix #503, and address #528, #558, #548, and others.

In addition, since we're updating the radio driver, I addressed #524.

In testing, I discovered a subtle bug with one of our applications that uses LMIC_sendAlive() -- there was a path when sending piggybacked MAC data with a poll that would result in trying to take the port 0 path instead. This caused problems with ChirpStack and TTN, at least. (This is #570.)

Finally, updated to use Arduino IDE 1.8.12 in test.

Version of library changes to v3.1.0.20.
@pomplesiegel
Copy link
Author

@terrillmoore Testing right now, but everything appears to be working swimmingly using v3.2! Thank you!

@terrillmoore
Copy link
Member

@pomplesiegel Excellent, thanks for letting me know. If you think of it, close the issue when you're satisfied that things are fixed.

@pomplesiegel
Copy link
Author

Great! Closing now, as this particular issue seems to be totally eliminated. Thanks again!

@IoTThinks
Copy link

@terrillmoore Testing right now, but everything appears to be working swimmingly using v3.2! Thank you!

I also have DIO1 disconnected.
Hence, finally, do you need DIO1 connected to make it sending again?

Thanks a lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@terrillmoore terrillmoore

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@pomplesiegel @trlafleur @terrillmoore @IoTThinks @KiwiGonzales