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...

2)
When running the application in debug mode from the Crossworks IDE
the firmware runs and the USB device is recognized, but when i just
connect the device without the debugger running the USB device is not
recognized. How do i program the device using Crossworks, so it will
run without the debugger?

Any help would be appreciated... Start a New Thread

--- 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. Start a New Thread