--- In l..., "mavonino" wrote:
>
> Hi,
>
> Im running a modified version of Keils HID example using the
> Crossworks compiler.
>
> My main function looks like this
>
> int main (void) {
>
> libarm_enable_irq();
>
> SCS |= 0x01; //Enable Fast GPIO on P0 and P1
>
> USB_Init(); /* USB Initialization */
> USB_Connect(TRUE); /* USB Connect */
>
> while (1)
> {
> //do work
> }
> }
>
> 1)
> Im having some real problems because it seems i randomly end up in
> dabort_handler in the startup code (philips_lpc230x_startup.s)
> sometimes i just modify a few lines in the while(1) loop and it
> suddenly works. How do i figure out what causes the dabort_handler?
> It seems rather random...
>
On page A2-17 of the "ARM Architecture Reference Manual" the processor
action taken during a Data Abort are described in detail. If you add
a break point at the data abort vector, or in the assembly language
abort handler stub, you should be able to see the processor state at
the point the abort occured. In particular, the banked(Data Abort)
R14 register will contain the address of the instruction that caused
the abort. A likely cause is a data read/write of an undefined memory
location. It is possibly due to stack problems, since those kinds of
problems do produce random *appearing* results.