This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem with SI-Labs Special Function Registers and RTX51Tiny

I'm wondering if anybody else has run into a problem with RTXTiny51 and the SiLabs processor. I'm using the C8052F62 processor, am using a LOT of the peripherals and have IO lines and interrupt routines all over the place. The SiLabs devices, having a lot of peripherals, have paged Special Function Registers, and - the crux of the difficulty - have a neat little stack mechanism for storing the current SFR page and automatically setting the proper one during an interrupt. The SRF page pointer is pushed onto a special hardware stack at an interrupt and popped again at the next RTI.
RTXTiny not being optimized for the SI Labs processors and the SFRPAGE register, one has to set the SFRPAGE to page 0 before making any RTXTiny Call so that it will talk properly to the Timer 0. So far, so good. A tech note suggests setting the SFR page before any Timer 0 accesses in Conf_tny.A51, but there's a problem with that as discussed below.
I've been chasing down another rather subtle problem and the fix has me stymied. The RTX51Tiny timer call is entered, obviously enough, with an interrupt by the Timer 0 overflow. If you look carefully at the code in Conf_Tny.A51 the return from the user code (the macro at the top into which one can stick your own stuff to be executed every clock tick) at the top of the file returns with an RETI; more stuff having to do with checking the status of suspended tasks is executed further down and then the routine returns to whence it came originally with a RET.
This all means that if the timer interupt happens to occur just after you've set the SFR register to something other than 0, the SFR page is popped from the NEXTSFR register into the SFRPAGE register prematurely - at the return from the user code macro - and screws up the TR0 calls in the rest of the task-checking code. If you follow the tech-note suggestion and set the SFRPAGE to 0 at each Timer 0 function, then it won't be correct (again, if the interrupt happens after you've set the SFRPAGE but before you've actually used it) when the interrupt returns to the original code.
The code is rather complex, there are interactions with the task management system, and swapping the RETI and RET commands around ends up with the program in an infinite loop the first time that you call an RTX51 wait() function. I need to investigate further, but seems like something causes the interrupt to talk to the wrong register page.
Any assistance would be appreciated.