![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Top]](icons/top.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
This section describes particular features and routines that are specific to ARM targets in one of the following ways:
These routines make assumptions about the standard prologue for routines. If routines are written in assembly language, or in another language that generates a different prologue, unexpected results may occur.
tt( ) does not report the parameters to C functions as it cannot determine these from the code generated by the compiler.
|
CAUTION: The Thumb kernel is compiled without backtrace structures. This means that tt( ) does not work within kernel routines and cret( ) occasionally does the wrong thing. Thumb breakpoints and single-stepping work even if the code is compiled without backtrace structures. One solution for debugging is to use ARM state and then switch to Thumb state for your final debugging and production.
|
||||||||||||||||||
The cacheLock( ) and cacheUnlock( ) routines always return ERROR (see Caches). Use of the cache and MMU are very closely linked on ARM processors. Consequently, if cacheLib is used, vmLib is also required. In addition, the cacheLib and vmLib calls need to be coordinated, see Memory Management Unit.
Many ARM processors have no debug or trace mode and no support for hardware-assisted debugging. Because of this, VxWorks for ARM uses only software breakpoints. When you set a software breakpoint, VxWorks replaces an instruction with a known undefined instruction. VxWorks restores the original code when the breakpoint is removed; if memory is examined or disassembled, the original code is shown.
The routine intLock( ) returns the I bit from the CPSR as the lock-out key for the interrupt level prior to the call to intLock( ). The routine intUnlock( ) takes this value as a parameter. For ARM, these routines control the CPU interrupt mask directly. They do not manipulate the interrupt levels in the interrupt controller chip.
ARM processors generally have no on-chip interrupt controllers to handle the interrupts multiplexed on the IRQ pin. Control of interrupts is a BSP-specific matter. All of these routines are connected by function pointers to routines which must be provided in ARM BSPs by a standard interrupt controller driver. For general information on interrupt controller drivers, see Wind Technical Note #46. For special requirements or limitations, see the appropriate interrupt controller device driver documents.
STATUS intLibInit(nLevels, nVecs, mode)
This routine initializes the interrupt architecture library. It is usually called from sysHwInit2( ) in the BSP code. The mode argument specifies whether interrupts are handled in preemptive mode (INT_PREEMPT_MODEL) or non-preemptive mode (INT_NON_PREEMPT_MODEL).
The intEnable( ) and intDisable( ) calls affect the masking of interrupts in the BSP interrupt controller and do not affect the CPU interrupt mask.
The interrupt stack display produced by checkStack( )in the target shell shows two interrupt stacks. For details, see section Interrupt stacks.
As mentioned above for cacheLib, caching and virtual memory are linked on ARM processors. Use of vmLib requires that cacheLib be included as well and that calls to the two libraries be coordinated. See Memory Management Unit.
The vxMemProbe( ) routine, which probes an address for a bus error, is supported by trapping data aborts. If the BSP hardware does not generate data aborts when illegal addresses are accessed, vxMemProbe( ) does not return the expected results, The BSP can provide an alternate routine by inserting the address of the alternate routine in the global variable _func_vxMemProbeHook.