 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : ARMmite H7 5.05.10 and 5.07.00b12 PLAY interrupt problem
| Author | Message | ||||
| BrantB Newbie  Joined: 27/10/2017 Location: CanadaPosts: 40 |
In working with the latest H7 firmware (5.07.00b12), I tripped over what seemed to be some strange behaviour involving the interrupt feature of the PLAY FLAC command. This was part of a larger project, and after discovering the unexpected behaviour, I set about extracting only the most pertinent sections of the code in order to get it down to something that was manageable for testing and demonstrating. In the end, I was somewhat relieved to determine that the behaviour remained consistent and repeatable even after the condensation - so I don't think it is something wrong with logic flow, etc. I also went back and tried it in the 5.05.10 firmware, thinking to myself that I had not noticed it there. To my surprise, I discovered that 5.05.10 exhibited exactly the same behaviour. That caused a bit of head scratching.  Then it struck me! I was indeed correct in thinking that I had not seen the issue in 5.05.10. But not because the issue didn't exist there ... but rather ... because I had already switched to 5.07.00b12 before I implemented the additional functionality which exposed the issue. So, of course, I never had a chance to see it happen in 5.05.10. Good, I thought ... I am not going insane after all.  The actual problem, in brief (I know, I know - already way too late for brief  ) ...If the PLAY interrupt is the only one that exists in the program, everything seems to behave as expected. However, if additional interrupts exist in the code, then the PLAY interrupt erroneously fires immediately upon the 2nd and subsequent runs of the program. I discovered this when I added some QE (quadrature encoder - aka rotary encoder) functionality to a program that was already making use of the PLAY FLAC interrupt. With the QE routines present (which rely on associated pin change interrupts), the PLAY FLAC interrupt started to behave strangely. With all of the QE code commented out, the PLAY FLAC stuff worked as expected. I have attached a ZIP containing a couple of sample programs to illustrate the problem. I have also included the FLAC file that I used, just in case it turns out to be critical (but I really don't think it hinges on the FLAC file itself, as I did try others and still found the same problem). H7 PLAY Interrupt Bug.zip The logic flow of the sample programs simply alternate between playing a couple of FLAC files (I happen to just use the same file for both phases) for 30 seconds. In the one where the QE is active, the rotary position and the status of the switch is sent to the console. There are a few status statements sent to the console, as the program executes, to help clearly illustrate what is going on. If you load and run H7 FLAC Bug 6B.bas, in either v5.05.10 of the ARMmite firmware, or v5.07.00b12, it runs as expected the first time. If you run the program a 2nd time (or 3rd, or 4th, etc.), it again runs as expected. If you Ctrl-C in the middle of execution (either during the first run, or any subsequent run), and then run the program again, it still runs fine. However, if you load and run H7 FLAC Bug 6C.bas, things turn out differently. It runs fine the first time ... but when it is run a 2nd time (or subsequent times), the first thing that happens is the FLAC DONE interrupt executes immediately upon startup. That just does not seem right. The same thing happens with Ctrl-C. Once the program has been started once, any type of termination (be it Ctrl-C, or normal END) seems to set things up such that the FLAC DONE interrupt will be the first thing to execute on any subsequent run. Only a hardware reset seems to put things back to rights. (I have tried a CLEAR before running the code again, and that doesn't have any positive effect either.) So, B is the example of expected behaviour, and C is the example of unexpected behaviour. The only difference between the B version of the code, and the C version of the code, is that C has all occurrences of the apostrophe-exclamation comment marker removed in order to activate the code associated with the QE routines. (I used that combination in order to make it quick and easy to do a find/replace in a text editor editor.) But as they say in late-night infomercials: wait, there's more  ...One final strange behaviour I noticed, and I have no clue if this is directly related to the underlying interrupt issue or not. I load B version of the test and run it - all is well. I then load C version, and the first time I try to run it, I get the following error: [33] SetPin QE_A_pin, intB, INT_QE, PULLUP Error: Invalid character: - Again, CLEAR does not help. I have to do a hardware reset (no other changes), then a RUN of C works fine - no syntax error. (And then, of course, subsequent runs demonstrate the interrupt error.) This syntax error occurs in both 5.05.10 and 5.07.00b12. And, in both cases, the syntax error only happens when load/running B followed by C. If I load/run C first, followed by B, there are no syntax errors. (I realize that there could not be a QE related syntax error in B anyway, since all of the code is commented out. But the point is, no syntax errors are encountered at all.) A few final details, in case they make any difference: I am using a Nucleo V2 with jumpers removed/configured as per @KeepIS. I am not using a Nucleo Backpack board. I am using MMEdit. Even though I can see MMEdit issuing a NEW command, I tried explicitly executing NEW between loading the B and C sample code, and I still got the syntax error. (That pretty much covers pre-answering all of the questions I can anticipate.) Both of these things certainly seem to be off the beaten path. It took me a little while to figure out what was going on, and to do some careful testing to make sure I wasn't just my own enemy. I hope I have provided you with enough info, @matherp, in order to figure out why this is happening. If not, I will be happy to answer any other questions you might have, and I look forward to your findings. Cheers, Brant |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Brant Thanks for the report and diagnostic. I know the problem and will fix in the next beta |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
Peter help |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
What? I'm not changing the keyboard initialisation - sorry. If you set option mouse without a workable mouse then you get an error when entering the editor or filemanager - just disable the option On the bug you have found some strange combination of static and passing a function to a function and the same variable name in both functions that isn't being catered for properly. This one is probably above my pay grade. Can you demonstrate it without using mm.cmdline$ so that I can test on a normal Micromite? If it fails on that as well it is one for Geoff Edited 2021-05-28 04:00 by matherp |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
Happy to be of service, Peter. Of course, I had the easy part.Thanks for all of your work in the *mite world. Brant |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Is that addressed to me? If not then it sounds very similar to https://www.thebackshed.com/forum/ViewTopic.php?TID=13459&PID=169306 except for "the same variable name in both functions" bit. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Thought it wasn't but misread and it is. My request still applies - if possible produce a version that demonstrates the issue without use of mm.cmdline$ so I can see if it is a generic MMbasic issue or specific to CMM2. The point about same variable was both functions use s$ in their definition |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Brant: Sorry for the delay The problem occurred on the CMM2 as well and was more difficult than I thought Please could you check this version |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
Peter: No need to apologise. You are a pretty busy fellow, keeping all of your *mite ports up-to-date. I am sorry that it turned out to be a tougher nut to crack than you anticipated, but I take a little comfort in knowing that the returns on your investment spilled over into the CMM2. Although I am not a user of CMM2, "what goes around, comes around" as they say - and the CMM2 development has certainly generated some nice upgrades to the 'plain' H7 version of ARMmite (since you were kind enough to back-port them). So it feels good to (indirectly) help the CMM2 users. I have tested the b13 version (which you pointed to in the other thread), and everything appears to function as expected now. That extends to there no longer being a syntax error when loading a new program over the top of an existing one. Well done  (as always), and many thanks (as always). |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
