-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
WiPy: interrupts not returning to main loop? #2406
Comments
The 2 main differences for WiPy between v1.8.1 and v1.8.3 are an upgraded FreeRTOS library, and addition of multithreading. Both of those things could impact the behaviour of IRQs. Can you please post here a minimal example which fails on 1.8.3 and passes on 1.8.1? |
Thanks for fast response. This is minimal main.py which I just tested with 1.8.1 and 1.8.3:
1.8.1 - output:
1.8.3 - output:
And it hangs here until I press the switch again. Btw is multithreading documented somewhere? |
Thanks, that definitely looks like a bug.
The |
@dmartauz I don't have a WiPy to test against right now but I'm pretty sure that disabling threading will fix the problem. You can disable it by changing lines 105-106 of cc3200/mpconfigport.h to: #define MICROPY_PY_THREAD (0)
#define MICROPY_PY_THREAD_GIL (0) If this works for you then I'll temporarily disable threading on cc3200 until a proper fix is worked out. |
I gave it a try. Using plain interrupt with version 1.8.1 just caused the REPL to disappear. Disabling threading made REPL stable, and the ISR was called, just the print statement in the ISR never showed anything. But a counter, which I used instead, was increased. Actual test code:
Newly created MP version: MicroPython v1.8.4-30-g99b05f4-dirty on 2016-09-10; WiPy with CC3200 Update: The same version with threading enabled also ran stable. So maybe the issue went away with version 1.8.4. |
Damien, Robert, I am currently on holiday and I don't have WiPy with me. I will do the build and testing with and without threading disabled on Monday 19.9. |
All, |
@dpgeorge: changing mpconfigport.h according to your suggestion seems to cure the problem for the moment. The test code timer4.py or jgmdavies runs for 35000 interrupts now. The impression, that it went away with 1.8.4 was wrong. Only sometimes it can take very long until the test stops. It seems to depend on the network activity. |
Interupts still not working MicroPython v1.8.5 on Wipy, it does return to main but hangs a short while after: PYB: soft reboot
After main loop printed Counter 0 for the sixth time the GP23 signal is connected to gnd via a button. The interupt routine pinInterrupt is called at least once (No debouncing on button) and counter is increased. This fact is shown on the seventh Counter print out from main. Then the rst button is pressed and it return to REPL. Ctrl-C will not abort the running code. Some times it works but on later press of GP23 button it hangs. boot.py is empty apart from a comment. `# main.py -- put your code here! uart = UART(0, baudrate=115200) micropython.alloc_emergency_exception_buf(100) def pinInterrupt(pin): def main():
` I have also tested,
code above it does not return to main loop, allthough interrupt continue to work, but pressing ctrl.c does not make it return to REPL. Here is a short print out: Consequently the error is not corrected in V1.8.5 /Blueslow |
Did you disable threading in mpconfigport.h as suggested by Damien?
|
No I did not. I saw the note about it but forgot to mention it. I used the pre built release as is from http://micropython.org/download. I have not the right tool chain installed and I have not looked in to the details of building the firmware for micropython running on the wipy. Any tips on how to install the tools chain for ARM under linux? |
Running Python code on a hard interrupt is incompatible with having a GIL, because most of the time the GIL will be held by the user thread when the interrupt arrives. Hard interrupts mean that we should process them right away and hence can't wait until the GIL is released. The problem with the current code is that a hard interrupt will try to exit/enter the GIL while it is still held by the user thread, hence leading to a deadlock. This patch works around such a problem by just making GIL exit/enter a no-op when in an interrupt context, or when interrupts are disabled. See issue #2406.
This issue should now be fixed by 17ba6ef. Please test and report back if it's working for you, thanks! |
Hi, Conclusion it works, at least in the short term. Good work Damien, thanks. This is how I tested: I have executed my script stated in 2406 Another problem: /Klas Den 2016-10-19 kl. 05:33, skrev Damien George:
|
I cannot confirm the build issue. I updated to the latest state (git pull), rebuilt the image, downloaded it to WIpy. FTP still runs. Which client & which OS are you using? |
Robert-hh, my ftp issue is a completely different problem of what is discussed in this thread so people may regard this as offtopic. |
Running Python code on a hard interrupt is incompatible with having a GIL, because most of the time the GIL will be held by the user thread when the interrupt arrives. Hard interrupts mean that we should process them right away and hence can't wait until the GIL is released. The problem with the current code is that a hard interrupt will try to exit/enter the GIL while it is still held by the user thread, hence leading to a deadlock. This patch works around such a problem by just making GIL exit/enter a no-op when in an interrupt context, or when interrupts are disabled. See issue micropython#2406.
Improve USB eject by resetting on replug
I would like to move following discussion from MP forum to GitHub, because in my opinion it is a major problem:
http://forum.micropython.org/viewtopic.php?f=11&p=13664#p13664
Based on my tests (build MicroPython v1.8.3-41-g253e1a6 on 2016-08-23) the issue is not only about loosing REPL but interrupts do not return to main loop ("e.g. printing some values with time delay indefinitely) started in main.py either.
When tested with MicroPython v1.8.1-65-gcbffd0a on 2016-06-18 interrupts return ok (but umqtt does not work - problem for my project).
The text was updated successfully, but these errors were encountered: