You have to hunt down that beast. Horses and dogs and all.

Don't you have an emulator around? Looking into the SFRs, registers, internal registers would be handy, trace memory woudl be a bonus.

A couple of questions/ideas:

First, what combination of priorities you have tried? I assume, you tried timer0 interrupt priority low and one or both serial interrupt priorities high.


Are you sure? You can probably output the timer value the same way as you output the stack pointer.


Waiting for "few hours" to chack for some idea sounds like going nuts to me. I would try to speed this up further. I know that modifying the code is a risk of inducing further errors that might mask the original, but I would take that risk. I would increase serial data rate. I would add empty loops into the isrs. I would increase timer reload/interrupt rate.

Is there any data processing in the isrs? Is there any critical combination that takes too long to process? Try using only that data. Is the timer interrupt processing data? Give him as much as it can take. Try to send garbage data. If it has enhanced UART, send him data with framing errors (use 1 more bit for transmission and set it to 0). If you check parity, try sending parity errors. If you assume packets of some maximum length, try sending invalid length.

I would be not sure about the (un)corrupted stack. A runaway pointer can do strange things :-( What about monitoring the complete content of stack? Try also monitor the peak stack usage - try to establish a "maxsp" variable and in the highest priority interrupt check if sp>maxsp and if so, store sp into maxsp; then monitor maxsp. Is the 1k stack flag on? Is it still on after the stall? Are there any data above the stack (that stack could possibly run into them).


Why on earth are you clearing TF0??? If a higher priority interrupt longer than 20ms kicks in between reloading tl0/th0 and clearing tf0, you can loose an interrupt, the next coming after 65536 cycles. Is this OK to have a longer time between timer interrupts (e.g. if you fill a buffer by data in serial interrupt and empty it in timer interrupt, assuming the timer is often enough the buffer can be short and if ocassionally the timer interrupt takes longer, the buffer can overflow)?
Do you stop the timer during reload?
There is also no point to enable timer inerrupt and timer run in the isr, unless you don't disable them there (but it should also make no harm except the isr gets longer a bit).
Try also count the isr enters/exits (inc a variable on enter and dec on exit) and monitor this value.

Jan Waclawek