We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a 1ms fixed time interrupt scanning and debouncing a couple of switches, and a 1200 baud port receiving blocks of 17 chars 4 times a sec. Asynchronously at 5 times/sec, I'm assembling an 8 character string to display on an 8 character DM display. This code now uses a vsprintf statement, and occasionally the output string gets leftshifted one character in the buffer. Surrounding the vsprintf call by EA=0 and EA=1 solves the problem, but the resulting delay to my fixed time interrupt messes up the switch scan. Anybody have any clues on why vsprintf is getting upset, and how to get around it? Thanks in advance.
Julian, Without knowing the specifics of what interrupts that you are using and how they are set up, this may or may not help. My first guess, based on the fact that the problem only occurs sometimes and disabling interrupts removes the problem, is the timer ISR is being interrupted by another ISR or vice versa. You should be able to eliminate this problem by making sure that the timer that is critical to your switch scan is set to the highest possible priority and that it uses a register bank that is not used by any other ISRs (or at least any ISR that have the same or higher priority) or functions in your code. Also, if the vsprintf() is being called from the ISR, you may want to see if you can come up with a scheme to get this pulled out of there. It uses variable arguements, can be time consuming and could cause a variety of stack and state problems that would not be a problem outside of an ISR. I can come up with some other possibilities if this doesn't help any. If this is the case, please include whether code is SMALL, COMPACT or LARGE, what other interrupts you are using, and if you are using any directives or pragmas that effect function calling such as NOAREGS, MAXARGS set to a small value, etc. First time that I have offered my two cents and I hope it is helpful. I have never participated in any discussion forums and I am therefore not familiar with the etiquette or proper protocol of responding. Please let me know if this reply is not appropriate in any way whatsoever. Brian
Brian, Your etiquette is perfect, and your suggestions valid, thank you :-) There are only two interrupts. The fixed time interrupt that handles the switches is at the higher priority setting, and the serial interrupt at the lower. They both have separate and unique "using" modifiers. The vsprintf is not in an interrupt, for obvious reasons, but having to disable interrupts while it is running is almost as disasterous to the behavior of the system. Code is SMALL, no pragmas or directives. I'm using a Metalink iceMaster-PE emulator. Looking at the internal memory display when I interrupts execution, I see the top 16 bytes up to 0xFF are red, meaning that they got changed recently. This indicates that I've blown the stack. Hmmm ... Thanks for the ideas, if you have any more, I'd love to here them.
Julian, The stack is looking suspect, but if you don't find a problem there, the next thing you could check out is the format strings. In light of the fact you are using vsprintf and not sprintf I am assuming different format strings are being used depending on situation at hand. Is one particular format string causing the drop char problem? Any possibility that there is a type size mismatch between format specifier and arguement being passed in? ( ex. sprintf(szBuff, "%d", by) will muck things up. I got stung with this one a while back.) Using vsprintf doubtfully allows you to cast you arguements, but you can use the optional b,h and l type modifiers in the format strings that you are using or generating to work around this mismatch problem. Brian
I did check the arg sizing - yes, I've been burned by that before myself. Here's what I'm going to do next:- I have a classic serial rcv interrupt handler loading a circular buffer, and an async unloader with its own buffer getting info to display. This is using up tons of space, and I only have 17 bytes of stack left. As I have a fixed format coming in the serial port, I'll combine the two functions into the interrupt routine, which will save some buffer handling time and a gob of memory, relatively speaking ;-> The interrupt time will go up slightly, but I only get four 17-char blocks every second @ 1200 baud, so I should be OK. I've got to get the stack under control, otherwise I don't have a snowball's chance of success. Thanks again for your suggestion.