 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 : Open/Close weirdo....
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
This has me a little confused. I have two subs that I call as and when needed, to log system errors and other system activity. They usually work fine, but tonight they have started doing odd things. The two routines are:  ...and the error I am getting from this code is:  ...yet, if I run these directly from the command prompt, there is no problem:  It's damn peculiar. I have searched for all instances of "#4" in the code using MMEDIT's search feature, and have confirmed that each and every time that handle #4 is opened, it is always closed again. It is never left open. Note also that as part of the SUB being called, I close that handle before leaving the routine. The next time I call that routine, I get this error message about the handle already being open.  BUT, I can call either sub from the command line as many times as I like - no error message, but when the code is running, I do. This suggests that I have accidentally left handle #4 open somewhere else, but according to my MMEDIT search for "#4", anywhere I open it, it also gets closed. 2AM so time to stop - my brain is not working so well at this time of night, but if anyone has any ideas of things for me to look for, I would appreciate the prod. EDIT: One last thing before bed, I tried simply putting in a "Close #4" just before the open command, but then I get a different error: "File number is not open.", along with mm.errno being 16. If I remove that CLOSE #4 and run the code again, I get the other error about the file already being open - WTF?!  It can't be both.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
In case you might call one as a result of an error, that might cause it. (Suppose DEBUG was garbage, or ON ERROR something or ...) You could reduce the window for such by moving the CLOSE up a line and by setting TXT$ before the OPEN. John |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
Hi Grogster. What PIC is this running on? check also that you don't have errors in your error handler (unlikely if it has been unaltered for some time) - if you get an error and jump to your handler, which also has an error, which jumps to your handler... you would be trying to open the same stream number multiple times. I have learned that when I get weird crap start to happen in stuff that has been running for ages, I flash the PIC. Has fixed me up a couple of times. It seems the 32MXs like to corrupt their core every so often. Is this the same system you had your odd GUI problem with? h |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 844 |
Hi Grogster, If I add a tick timer as below and call your sub while they are being used in the main loop then the errors you are experiencing show up. SETTICK 500, tick1 sub tick1 WRITE_ERRLOG("HELLO WORLD two") end sub I think the PRINT #4,TXT$ statement is processor friendly and knows it could take awhile so completes in the background. This means any interrupts (e.g settick,touch down etc) can be serviced while its writing to file. If one on these also writes an error then the SUB is called again before its finished, so the file OPEN/CLOSE confusion happens. The code below works by having two separate functions. ADD_ERROR(a$) which puts any pending errors into a list, and WRITE_ERRORLOG() which is only ever called from the main loop and writes the errors in the list to file. Run the code below and you will see it mostly wring 1 error, but as the tick happens is writes 3 at once. hope this makes sense. Regards Gerry Latest F4 Latest H7 |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
Hi all.  Thanks for the replies.[Quote=CaptainBoing]s this the same system you had your odd GUI problem with?[/Quote] Yes, but that problem was TOTALLY my fault, as I was deleting controls as soon as you touched them, in order to create new ones on the new page. I now define all the controls, and use the GUI SETUP commands to organise all my pages, and this is working much, much better. Nice thinking - that will be it exactly!  I am not using any tick timers in this code, all processing is done in the main loop, and the serial port buffer acts beautifully as a message queue, allowing them to build up there if they have to, and they will be processed once the code makes it back to the main loop. That way, no messages are dropped or missed, as the serial port queue holds on to them for me.  Ahhhh, those beautiful serial port buffers.....I AM however, using touch interrupts, so I will study this in a bit more detail, as I THINK I know how this is happening now that you mention the above - touching the "OK" button on the LCD when a message arrives, will push the code back to the main menu, at which point it processes the next message, and COULD loop to the errors or system log subs, and try to open the file when it is not finished with it yet from the last message. I think I will fix this by adding something like: GUI INTERRUPT 0 and DO:LOOP UNTIL LOF(#4)=255 to FORCE the logging routines to complete cleanly and close the file BEFORE being allowed to exit the sub, or respond to touch again. I would have thought that writing to the SD card would have been so fast as to not have to really worry about this issue, but there you go. I will keep the thread updated. Smoke makes things work. When the smoke gets out, it stops! |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
If writing to a SD card is non-blocking then there should be a way to poll for its status so that you have the possibility to know when it is finished. If it is really non-blocking then a CLOSE should be blocking. so that you are sure that after the close all data is written and the file properly closed. I think this one is for Geoff as what you experience is not how it should be. Microblocks. Build with logic. |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
@G I am pretty sure it is a re-entrance problem as I can simulate here with the same error message (MMX running 5.3) By setting a flag to indicate the handle is open prior to the open and clearing it after the close, a test within each routine to wait until the other user of handle #4 has finnished then makes sure there are no conflicts. The test code below shows how it would work. ' Testing File re-entrance code MAIN: Print "Call error log subroutine at "+Time$ SetTick 1000,tick t1$="test1" '*** clear the file handle flag for initial use handle_open_flag = 0 '*** do ' now call error log routine write_errorlog t1$ ' we should have hung in there for 5 secs but we will get ' an interrupt in 1 sec to run sys log Pause 100 loop End ' we just want an interrupt every second to test the re-entrance Sub tick write_syslog t1$ End Sub '----------------------- ' ERROR LOGGING ROUTINE '----------------------- Sub WRITE_ERRORLOG(T1$) print "writing error log at "+time$ Local TXT$ Chdir "\LOG\" '*** open file handle test do while handle_open_flag=1 loop handle_open_flag=1 '**** Open "ERRORS.LOG" For APPEND As #4 TXT$="["+Date$+", "+Time$+"] - "+TXT$ Print #4,TXT$ If DEBUG Then Print "ERROR LOG - "+TXT$ '** ' pause here to allow simulated re-entrance from tick interrupt ' delete this pause for normal usage Pause 5000 '** Close #4 ' *** now clear the open file handle flag handle_open_flag=0 '*** End Sub '------------------------ ' SYSTEM LOGGING ROUTINE '------------------------ Sub WRITE_SYSLOG(T1$) Local TXT$ print "Writing sys log at "+time$ Chdir "\LOG\" '*** open file handle test do while handle_open_flag=1 loop handle_open_flag=1 '**** Open "SYSTEM.LOG" For APPEND As #4 TXT$="["+Date$+", "+Time$+"] - "+TXT$ Print #4,TXT$ If DEBUG Then Print "SYSTEM LOG - "+TXT$ Close #4 ' *** now clear the open file handle flag handle_open_flag=0 '*** End Sub Cheers Doug ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
@ Jean - Yes, I too would love to know if the SD writing is non-blocking or not. My own personal guess is that it is NOT, in that it will be buffered so the main program can carry on with other things. How that works exactly, we would need Geoff or Peter(matherp) to comment on as they know the source well(so does kiiid). My guess would be that the PRINT #4 command posts the data to the BUFFER and not the card, and the CLOSE #4 flushes the buffer to the file, and closes it. However, flushing the buffer and closing the file takes a little time, and I think this could be where we are having the issue. @ Doug - Yes, that looks like an ideal way to get around the issue, and I will implement that concept in the next few days. Special thanks to you for taking the time to play with the code, and discover the errors that I was getting. That makes me feel better in that it is a provable error, and thus we now have a workaround. I will let the forums know how I get on. Smoke makes things work. When the smoke gets out, it stops! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8582 |
I've recently moved the Micromite eXtreme to FatFs rather than the original Microchip file system. This definitely works on the Basis that writes take place to a buffer and that is flushed to disk whenever the buffer is full (512 bytes) or at a file close. FatFs also implements a SYNC command which forces a buffer flush without closing the file. It would be easy to implement this as an additional capability, possibly as an option as part of the OPEN command. Geoff is looking to also move to FatFs for V5.4 so it probably isn't worth doing anything on the Microchip stack. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
Understood. Thanks for that information. For now, we have a work-around, so I will implement that for now and that should get me out of the problem I was having. I also agree with you - probably not worth adding anything to the Microchip stack, if Geoff is considering a change in the filesystem code anyway. Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
