|
Problem Description
|
|
When an emulator is set up to catch an exception (exceptions that correspond to a 1 in the ETM parameter), including the cases of software and hardware breakpoint, the target should not be allowed to execute any part of the exception handler.
Depending on how fast the CPU is running, sometimes the E500 core will execute the first one or two instructions, of the exception service routine, before being stopped by the emulator. This is considered unwanted code execution. One possible unwanted side-effect might be a register may be modified. This may have detrimental effect on subsequent code execution, such as stepping or running after hitting a breakpoint. |
|
|
|
Problem Solution
|
|
For this reason, the exception service routines in question need to be patched. The following 2 instructions should be inserted at the beginning of the exception service routines to be trapped.
isync nop If the processor cannot be stopped in time, executing these two instructions should have no adverse effects on the code. Exception service routines in vxWorks contain stub code and labels at a relative offset from the vectors. This is done intentionally so that users can call the APIs based on these relative offsets. These include, but not limited to, excVecGet/excVecSet, exc*Connect, possibly vxMemProbe. Inserting instructions at the beginning of the exception service routine breaks these APIs. Given the fact that vxWorks exception handlers are structured this way, the isync/nop patch modification should only be used as temporary remedy for code debugging purpose. During this debug phase, users should make sure that they don't call the APIs in question. Also, since these APIs are called during the system boot process, the code modifications should only be done after boot-up. In summary, here is a short procedure for this. 1. Use the emulator to boot the board and launch vxWorks. 2. Manually halt it by clicking on the Suspend button in the Debug window. 3. From the Register window, expand the Interrupt register group to find out the starting addresses for the exception service routines in question. 4. From the Memory window, enter an address to display it. Enter 0x60000000 for the first location, and 0x4C00012C for the second one. Repeat this for each of the exception service routines in question. Since emulator is set up to catch these exceptions, these exception service routines will never get a chance to execute beyond the first couple of instructions. 5. Set any breakpoints if so desired, before clicking on the Resume button in the Debug window to let it run again. Since these addresses usually don't change, you can use a script file to make it easier: sml addr1 4c00012c sml addr1+4 60000000 |
*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。
发布文章