NMI routine sdk_wDev_ProcessFiq seems to be written in C, meets ABI
calling conventions for callee-saved registers. Not sure why SDK
handlers saved them.
NMI handler now also meets the ABI requirement that stack is 16 byte
aligned (doesn't seem strictly necessary, but can't hurt.)
RTOS Timer tick handler is now the same as any other ISR.
This causes a few subtle behaviour changes that seem OK but are worth noting:
* RTOS tick handler sdk__xt_timer_int() is now called from one stack
frame deeper (inside _xt_isr_handler()), whereas before it was called
from the level above in UserHandleInterrupt. I can't see any way that
the extra ~40 bytes of stack use here hurt, though.
* sdk__xt_timer_int() was previous called after all other interrupts
flagged in the handler, now it's called before the TIMER FRC1 & FRC2
handlers. The tick handler doesn't appear to do anything particularly
timing intensive, though.
* GPIO interrupt (value 3) is now lower priority than the SPI
interrupt (value 2), whereas before it would have been called before
SPI if both interrupts triggered at once.
CallNMIExceptionHandler was saving/restoring registers to the wrong offsets,
causing it to potentially corrupt the first two slots of the
LoadStoreErrorHandler's save area.
The downside here is needing to use #include so the 'beq' in the
exception vector can land on it directly, save an instruction.
There might be a better way to do this, but it seems hard to "curate"
the order that symbols appear in each section.
As discussed in #11
Known limitations:
- Only supports l8ui/l16ui
- Unoptimised load routine
- Not called from DoubleExceptionHandler but should be
- Doesn't restore state properly when falling through to fatal exception handler
Not actually a problem with the current linker script as the address is
predetermined there at start of IRAM, but might as well be accurate
about it.
As per advice from @foogod on esp8266-re mailing list:
https://groups.google.com/d/msg/esp8266-re/1ljIY3Zttbo/HvzHSWOLCgAJ
