#76403 - Mighty Max - Tue Mar 21, 2006 11:03 am
Heya,
i've worked with exceptions of different kind and how they could be catched on the CPU the last week.
I intend to use this for implementing soft & hardcoded breakpoints. Together with the multithreading there could be a live-debugger thread that lets you look what went wrong on the hardware & changes memory to resolve the problem & return the execution.
I've created a version of the Multithreader that does a breakpoint (before it even starts the multithreading) via an undefined instruction. It also would stall the system with a message when reading from/writing to invalid locations.
Sorce & .nds:
http://mightymax.org/MultiThreading.rar
The handling is pretty easy and works allmost like the IRQ handling:
At 0x27FFD9C is the pointer to the custom exception handler. If there is a 0 stored there, the bios just ignores the exception and jumps back to the execution.
it prepares the call with storing some information in the RAM just below the pointer:
Causing location at 0x027FFD98
Saved stack at 0x027FFD94
Old ARM mode at 0x027FFD90
Old cp15 status at 0x027FFD8C
additionally it disables the MPU & sets the FIQ & IRQ bit in CPSR to disable all interrupts.
When the exception handler is called, it does not get a valid value in LR to return to. Therefor we either have to rebuild the LR, or just do the same as would happen without us beeing called.
This is done in the EnterException in the .s:
There is one last obstackle still to use it. Whenever you are in the C routine to handle this exception. It will crash on the call to console functions. The solution: enable the MPU again before calling them, and it works fine again.
If you don't want it enabled & still need to print out, you will need to reinitialize the console.
I've commented the example code, it should explain the things done
Now,
have fun with exception handling.
_________________
GBAMP Multiboot
i've worked with exceptions of different kind and how they could be catched on the CPU the last week.
I intend to use this for implementing soft & hardcoded breakpoints. Together with the multithreading there could be a live-debugger thread that lets you look what went wrong on the hardware & changes memory to resolve the problem & return the execution.
I've created a version of the Multithreader that does a breakpoint (before it even starts the multithreading) via an undefined instruction. It also would stall the system with a message when reading from/writing to invalid locations.
Sorce & .nds:
http://mightymax.org/MultiThreading.rar
The handling is pretty easy and works allmost like the IRQ handling:
At 0x27FFD9C is the pointer to the custom exception handler. If there is a 0 stored there, the bios just ignores the exception and jumps back to the execution.
it prepares the call with storing some information in the RAM just below the pointer:
Causing location at 0x027FFD98
Saved stack at 0x027FFD94
Old ARM mode at 0x027FFD90
Old cp15 status at 0x027FFD8C
additionally it disables the MPU & sets the FIQ & IRQ bit in CPSR to disable all interrupts.
When the exception handler is called, it does not get a valid value in LR to return to. Therefor we either have to rebuild the LR, or just do the same as would happen without us beeing called.
This is done in the EnterException in the .s:
Code: |
EnterException: // store context LDR r12,=ExceptionLocalStorage STMIA r12,{r0-r11,r13} // assign a stack LDR r12,=ExceptionStack LDR r13,[r12] // Get C function & call it LDR r12,=ExceptionC LDR r12,[r12,#0] ADD r14,r15,#0 BXNE r12 // restore context LDR r12,=ExceptionLocalStorage LDMIA r12,{r0-r11,r13} // do the bios code .word 0xE8BD5000 .word 0xEE01CF10 .word 0xE16FF00E .word 0xE8BD5000 .word 0xE25EF004 ExceptionC: .word 0x00000000 ExceptionStack: .word 0x00000000 ExceptionLocalStorage: .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 .word 0x00000000 |
There is one last obstackle still to use it. Whenever you are in the C routine to handle this exception. It will crash on the call to console functions. The solution: enable the MPU again before calling them, and it works fine again.
If you don't want it enabled & still need to print out, you will need to reinitialize the console.
I've commented the example code, it should explain the things done
Now,
have fun with exception handling.
_________________
GBAMP Multiboot