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.

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

Arduini Pro Mini stuck on os_init #523

Closed
aparcar opened this issue Jan 11, 2020 · 6 comments
Closed

Arduini Pro Mini stuck on os_init #523

aparcar opened this issue Jan 11, 2020 · 6 comments
Assignees
Labels

Comments

@aparcar
Copy link

aparcar commented Jan 11, 2020

Similar to #521 my Arduino Pro Mini hangs on os_init. While Catena offers a working fork for the Feather M0 (Catena 4410) I can't find something similar for the Pro Mini.

Is it possible that the same GPIO changes corrupted the os_init() here as well?

@JackGruber
Copy link

Hi aparcar,

@terrillmoore for me it looks like the commit 306330f is the problem.
I have today no time to investigate deeper, but with git bisect i figured out, that with this commit the pro Mini stuck in the os_init function.

With the a4044c0 i can join the network and send data.

Have a nice weekend
Alex

@terrillmoore
Copy link
Member

@JackGruber and @aparcar -- thanks for looking into this.

This is because "interrupts disabled" are stopping the clock from advancing properly. hal_waitUntil() is hanging because time is not advancing.

Various BSPs handle time differently when interrupts are disabled, and start up with different interrupt enabled/disabled state. The MCCI BSPs all have the property that time advances even when interrupts are disabled. But many BSPs do not.

The LMIC needs to be reworked to remove all the interrupt enable/disable logic that's presently there, as I am certain that there's no need for extended interrupt disables. (I think this was an artifact of the original adaptation for Arduino. I'll raise a linked bug.

@aparcar
Copy link
Author

aparcar commented Jan 27, 2020

How to proceed here? Should I just use the outdated version or is there a way to change the behavior in the current release?

@terrillmoore
Copy link
Member

Unluckily, I have a pressing commitment on another project, and can't look at this until that's done. Probalby another week. If you use git to clone the repo, you can then use git to backout the single change 306330f. The command is something like:

git revert 306330fcb5be10c9897f96d2885af530d168a5d3

The problem is that os_radio() disables interrupts. delay() and delay_microseconds() work (but may be inaccurate) on many platforms, even interrupts are disabled.

There is no good reason for os_radio() to disable interrupts other than to prevent re-entry into the radio driver. There are standard techniques for doing this without disabling interrupts. My first hurried attempt to fix this didn't work; I need a few hours when I'm not on deadline to correct this. Another approach would be to use #if, but on any platform disabling interrupts for so long is not a good thing. I'd prefer to fix the root cause. (Disabling interrupts like that causes other problems for timing inside the radio driver.)

@bertrik
Copy link

bertrik commented Jan 29, 2020

Aww, ran into this exact problem, traced it down to hal_waitUntil(). Good to see the issue acknowledged.

@sweetpants
Copy link

I reverted back to 3.0.99.9 (commit: e59c123) and works again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants