2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

I am working in the USB INIT section of my transition from LPC2144 to
the LPC2366 (USB worked in the 2144) and as soon as a 00000
is written to the USB device interrupt enable register, it pops
right over to int vector 0x10 Data Abort. A "0" to that register
shouldn't do anything, should it ?? The Vic Protection register
has been written as 0 early on in the initialization code if USER/PRIVELEDGED mode should make any difference.

What kinds of things could cause a vector to Abort in this case ?

Thanks,
boB
USBDEVINTEN = 0; //0xFFE0C204

causes a data abort interrupt.

0x0000 0010 Data Abort (data access memory fault)

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

LPC23xx User Manual Chapter 15, Section 10 ?

When software wishes to access registers in one of the controllers, it should first ensure
that the respective controller's 48 MHz clock is enabled by setting its CLK_EN bit in the
OTGClkCtrl register and then poll the corresponding CLK_ON bit in OTGClkSt until set.
Once set, the controller's clock will remain enabled until CLK_EN is cleared by software.
Accessing the register of a controller when its 48 MHz clock is not enabled will result in a
data abort exception

Regards,
-daniel

From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf Of bobtransformer
Sent: Thursday, November 05, 2009 3:10 PM
To: l...@yahoogroups.com
Subject: [lpc2000] Weird again... Writing 0 to USBDEVINTEN causing a Data Abort interrupt

I am working in the USB INIT section of my transition from LPC2144 to
the LPC2366 (USB worked in the 2144) and as soon as a 00000
is written to the USB device interrupt enable register, it pops
right over to int vector 0x10 Data Abort. A "0" to that register
shouldn't do anything, should it ?? The Vic Protection register
has been written as 0 early on in the initialization code if USER/PRIVELEDGED mode should make any difference.

What kinds of things could cause a vector to Abort in this case ?

Thanks,
boB

USBDEVINTEN = 0; //0xFFE0C204

causes a data abort interrupt.

0x0000 0010 Data Abort (data access memory fault)
[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

LPC214x has a dedicated PLL for USB. LPC23xx uses one PLL
for both system clock and USB clock. So, it's crucial to make
sure USB clock is 48Mhz.

Daniel is right assessing your data abort issue.

regards,
Tom
--- In l...@yahoogroups.com, Daniel Widyanto wrote:
>
> LPC23xx User Manual Chapter 15, Section 10 ?
>
> When software wishes to access registers in one of the controllers, it should first ensure
> that the respective controller's 48 MHz clock is enabled by setting its CLK_EN bit in the
> OTGClkCtrl register and then poll the corresponding CLK_ON bit in OTGClkSt until set.
> Once set, the controller's clock will remain enabled until CLK_EN is cleared by software.
> Accessing the register of a controller when its 48 MHz clock is not enabled will result in a
> data abort exception
>
> Regards,
> -daniel
>
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf Of bobtransformer
> Sent: Thursday, November 05, 2009 3:10 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Weird again... Writing 0 to USBDEVINTEN causing a Data Abort interrupt
>
> I am working in the USB INIT section of my transition from LPC2144 to
> the LPC2366 (USB worked in the 2144) and as soon as a 00000
> is written to the USB device interrupt enable register, it pops
> right over to int vector 0x10 Data Abort. A "0" to that register
> shouldn't do anything, should it ?? The Vic Protection register
> has been written as 0 early on in the initialization code if USER/PRIVELEDGED mode should make any difference.
>
> What kinds of things could cause a vector to Abort in this case ?
>
> Thanks,
> boB
>
> USBDEVINTEN = 0; //0xFFE0C204
>
> causes a data abort interrupt.
>
> 0x0000 0010 Data Abort (data access memory fault)
> [Non-text portions of this message have been removed]
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Dezheng" wrote:
>
> LPC214x has a dedicated PLL for USB. LPC23xx uses one PLL
> for both system clock and USB clock. So, it's crucial to make
> sure USB clock is 48Mhz.
>
> Daniel is right assessing your data abort issue.
>
> regards,
> Tom
>

Yes, that was this problem. I'm not using OTG USB, but the LPC2366 has a NEW register... A USB Clock ENable register that needs to be set. SO, addressing that issue (pun intended) fixed THAT particular problem. Thank you !!!!
NOW, I have another Weird JTAG issue. In my INITialization code, (same stuff that used to work in the LPC2144 version), not the line
0xb78: 0xe584c004 STR r12, [r4, #0x4] <<--- MUST STEP OVER THIS INSTRUCTION !
If I set a JTAG BREAKPOINT on this line, or any line after this, and then press F5 to continue, or F11 to step and then F5, the program continues to run.

If I set a breakpoint any time BEFORE this instruction, which sets the
VICINTENABLE_bit.TIMER0 = 1; it crashes into a Data Abort interrupt loop. I've added some NOPs for debug purposes. This makes no sense to me.

A __disable_interrupt(); has been done way before this instruction.
I also tried a delay loop but didn't do anything. Can't seem to catch this in the act !

I figure it must be another difference between the LPC23xx and LPC214x line of processors, but this has me stumped.
Now, I added some NOPs after this and I can't get it to work anymore.

Is there an IAR bug with the Segger J-LINK maybe or this processor line ??
Any ideas here ?? This is VERY frustrating.

Thank you,
boB

asm("nop");
0xb68: 0xe1a00000 MOV r0, r0

asm("nop");
0xb6c: 0xe1a00000 MOV r0, r0

VICINTENABLE_bit.TIMER0 = 1; //BREAKPOINT DOES NOT CONTINUE
0xb70: 0xe594c004 LDR r12, [r4, #0x4]
0xb74: 0xe38cc010 ORR r12, r12, #16 ; 0x10
0xb78: 0xe584c004 STR r12, [r4, #0x4] <<--- MUST STEP OVER THIS INSTRUCTION !
T0TCR = 1; // Enable timer0 SET JTAG BREAKPOINT HERE OR AFTER and it KEEPS ON GOING....
0xb7c: 0xe5853000 STR r3, [r5]
LED4Off
0xb80: 0xe3a0c980 MOV r12, #2097152 ; 0x200000
0xb84: 0xe582c018 STR r12, [r2, #0x18]
LED5Off

>
> --- In l...@yahoogroups.com, Daniel Widyanto wrote:
> >
> > LPC23xx User Manual Chapter 15, Section 10 ?
> >
> > When software wishes to access registers in one of the controllers, it should first ensure
> > that the respective controller's 48 MHz clock is enabled by setting its CLK_EN bit in the
> > OTGClkCtrl register and then poll the corresponding CLK_ON bit in OTGClkSt until set.
> > Once set, the controller's clock will remain enabled until CLK_EN is cleared by software.
> > Accessing the register of a controller when its 48 MHz clock is not enabled will result in a
> > data abort exception
> >
> > Regards,
> > -daniel
> >
> > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf Of bobtransformer
> > Sent: Thursday, November 05, 2009 3:10 PM
> > To: l...@yahoogroups.com
> > Subject: [lpc2000] Weird again... Writing 0 to USBDEVINTEN causing a Data Abort interrupt
> >
> > I am working in the USB INIT section of my transition from LPC2144 to
> > the LPC2366 (USB worked in the 2144) and as soon as a 00000
> > is written to the USB device interrupt enable register, it pops
> > right over to int vector 0x10 Data Abort. A "0" to that register
> > shouldn't do anything, should it ?? The Vic Protection register
> > has been written as 0 early on in the initialization code if USER/PRIVELEDGED mode should make any difference.
> >
> > What kinds of things could cause a vector to Abort in this case ?
> >
> > Thanks,
> > boB
> >
> > USBDEVINTEN = 0; //0xFFE0C204
> >
> > causes a data abort interrupt.
> >
> > 0x0000 0010 Data Abort (data access memory fault)
> >
> >
> > [Non-text portions of this message have been removed]
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "bobtransformer" wrote:
>
> --- In l...@yahoogroups.com, "Dezheng" wrote:
> >
> > LPC214x has a dedicated PLL for USB. LPC23xx uses one PLL
> > for both system clock and USB clock. So, it's crucial to make
> > sure USB clock is 48Mhz.
> >
> > Daniel is right assessing your data abort issue.
> >
> > regards,
> > Tom
> > Yes, that was this problem. I'm not using OTG USB, but the LPC2366 has a NEW register... A USB Clock ENable register that needs to be set. SO, addressing that issue (pun intended) fixed THAT particular problem. Thank you !!!!
> NOW, I have another Weird JTAG issue. In my INITialization code, (same stuff that used to work in the LPC2144 version), not the line
> 0xb78: 0xe584c004 STR r12, [r4, #0x4] <<--- MUST STEP OVER THIS INSTRUCTION !
> If I set a JTAG BREAKPOINT on this line, or any line after this, and then press F5 to continue, or F11 to step and then F5, the program continues to run.
>
> If I set a breakpoint any time BEFORE this instruction, which sets the
> VICINTENABLE_bit.TIMER0 = 1; it crashes into a Data Abort interrupt loop. I've added some NOPs for debug purposes. This makes no sense to me.
>
> A __disable_interrupt(); has been done way before this instruction.
> I also tried a delay loop but didn't do anything. Can't seem to catch this in the act !
>
> I figure it must be another difference between the LPC23xx and LPC214x line of processors, but this has me stumped.
> Now, I added some NOPs after this and I can't get it to work anymore.
>
> Is there an IAR bug with the Segger J-LINK maybe or this processor line ??
> Any ideas here ?? This is VERY frustrating.
>
> Thank you,
> boB
Now I'm seeing CPSR set to 0x60000092 and SPSR at 0x6000001F when it crashes to Data Abort loop after hitting F5 to continue running.

It appears to step through, just doesn't RUN now. And now I can't duplicate the last message's problem. This is very strange...

boB

>
> asm("nop");
> 0xb68: 0xe1a00000 MOV r0, r0
>
> asm("nop");
> 0xb6c: 0xe1a00000 MOV r0, r0
>
> VICINTENABLE_bit.TIMER0 = 1; //BREAKPOINT DOES NOT CONTINUE
> 0xb70: 0xe594c004 LDR r12, [r4, #0x4]
> 0xb74: 0xe38cc010 ORR r12, r12, #16 ; 0x10
> 0xb78: 0xe584c004 STR r12, [r4, #0x4] <<--- MUST STEP OVER THIS INSTRUCTION !
> T0TCR = 1; // Enable timer0 SET JTAG BREAKPOINT HERE OR AFTER and it KEEPS ON GOING....
> 0xb7c: 0xe5853000 STR r3, [r5]
> LED4Off
> 0xb80: 0xe3a0c980 MOV r12, #2097152 ; 0x200000
> 0xb84: 0xe582c018 STR r12, [r2, #0x18]
> LED5Off
>
> >
> > --- In l...@yahoogroups.com, Daniel Widyanto wrote:
> > >
> > > LPC23xx User Manual Chapter 15, Section 10 ?
> > >
> > > When software wishes to access registers in one of the controllers, it should first ensure
> > > that the respective controller's 48 MHz clock is enabled by setting its CLK_EN bit in the
> > > OTGClkCtrl register and then poll the corresponding CLK_ON bit in OTGClkSt until set.
> > > Once set, the controller's clock will remain enabled until CLK_EN is cleared by software.
> > > Accessing the register of a controller when its 48 MHz clock is not enabled will result in a
> > > data abort exception
> > >
> > > Regards,
> > > -daniel
> > >
> > > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf Of bobtransformer
> > > Sent: Thursday, November 05, 2009 3:10 PM
> > > To: l...@yahoogroups.com
> > > Subject: [lpc2000] Weird again... Writing 0 to USBDEVINTEN causing a Data Abort interrupt
> > >
> > > I am working in the USB INIT section of my transition from LPC2144 to
> > > the LPC2366 (USB worked in the 2144) and as soon as a 00000
> > > is written to the USB device interrupt enable register, it pops
> > > right over to int vector 0x10 Data Abort. A "0" to that register
> > > shouldn't do anything, should it ?? The Vic Protection register
> > > has been written as 0 early on in the initialization code if USER/PRIVELEDGED mode should make any difference.
> > >
> > > What kinds of things could cause a vector to Abort in this case ?
> > >
> > > Thanks,
> > > boB
> > >
> > > USBDEVINTEN = 0; //0xFFE0C204
> > >
> > > causes a data abort interrupt.
> > >
> > > 0x0000 0010 Data Abort (data access memory fault)
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "bobtransformer" wrote:
>
> --- In l...@yahoogroups.com, "bobtransformer" wrote:
> >
> >
> >
> > --- In l...@yahoogroups.com, "Dezheng" wrote:
> > >
> > > LPC214x has a dedicated PLL for USB. LPC23xx uses one PLL
> > > for both system clock and USB clock. So, it's crucial to make
> > > sure USB clock is 48Mhz.
> > >
> > > Daniel is right assessing your data abort issue.
> > >
> > > regards,
> > > Tom
> > >
> >
> > Yes, that was this problem. I'm not using OTG USB, but the LPC2366 has a NEW register... A USB Clock ENable register that needs to be set. SO, addressing that issue (pun intended) fixed THAT particular problem. Thank you !!!!
> >
> >
> > NOW, I have another Weird JTAG issue. In my INITialization code, (same stuff that used to work in the LPC2144 version), not the line
> > 0xb78: 0xe584c004 STR r12, [r4, #0x4] <<--- MUST STEP OVER THIS INSTRUCTION !
> >
> >
> > If I set a JTAG BREAKPOINT on this line, or any line after this, and then press F5 to continue, or F11 to step and then F5, the program continues to run.
> >
> > If I set a breakpoint any time BEFORE this instruction, which sets the
> > VICINTENABLE_bit.TIMER0 = 1; it crashes into a Data Abort interrupt loop. I've added some NOPs for debug purposes. This makes no sense to me.
> >
> > A __disable_interrupt(); has been done way before this instruction.
> > I also tried a delay loop but didn't do anything. Can't seem to catch this in the act !
> >
> > I figure it must be another difference between the LPC23xx and LPC214x line of processors, but this has me stumped.
> >
> >
> > Now, I added some NOPs after this and I can't get it to work anymore.
> >
> > Is there an IAR bug with the Segger J-LINK maybe or this processor line ??
> >
> >
> > Any ideas here ?? This is VERY frustrating.
> >
> > Thank you,
> > boB
> >
> >
> Now I'm seeing CPSR set to 0x60000092 and SPSR at 0x6000001F when it crashes to Data Abort loop after hitting F5 to continue running.
>
Nevermind that... I'm just going nuts I guess. Will fight this
JTAG and LPC-USB frustration during the weekend.

Changing processors AND compilers (--> IAR 5.4) at the same time is not something I recommend to anyone.

Still, thanks for the help on this forum !

boB

> It appears to step through, just doesn't RUN now. And now I can't duplicate the last message's problem. This is very strange...
>
> boB
> >
> > asm("nop");
> > 0xb68: 0xe1a00000 MOV r0, r0
> >
> > asm("nop");
> > 0xb6c: 0xe1a00000 MOV r0, r0
> >
> > VICINTENABLE_bit.TIMER0 = 1; //BREAKPOINT DOES NOT CONTINUE
> > 0xb70: 0xe594c004 LDR r12, [r4, #0x4]
> > 0xb74: 0xe38cc010 ORR r12, r12, #16 ; 0x10
> > 0xb78: 0xe584c004 STR r12, [r4, #0x4] <<--- MUST STEP OVER THIS INSTRUCTION !
> >
> >
> > T0TCR = 1; // Enable timer0 SET JTAG BREAKPOINT HERE OR AFTER and it KEEPS ON GOING....
> > 0xb7c: 0xe5853000 STR r3, [r5]
> > LED4Off
> > 0xb80: 0xe3a0c980 MOV r12, #2097152 ; 0x200000
> > 0xb84: 0xe582c018 STR r12, [r2, #0x18]
> > LED5Off
> >
> >
> >
> >
> >
> > >
> > > --- In l...@yahoogroups.com, Daniel Widyanto wrote:
> > > >
> > > > LPC23xx User Manual Chapter 15, Section 10 ?
> > > >
> > > > When software wishes to access registers in one of the controllers, it should first ensure
> > > > that the respective controller's 48 MHz clock is enabled by setting its CLK_EN bit in the
> > > > OTGClkCtrl register and then poll the corresponding CLK_ON bit in OTGClkSt until set.
> > > > Once set, the controller's clock will remain enabled until CLK_EN is cleared by software.
> > > > Accessing the register of a controller when its 48 MHz clock is not enabled will result in a
> > > > data abort exception
> > > >
> > > > Regards,
> > > > -daniel
> > > >
> > > > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf Of bobtransformer
> > > > Sent: Thursday, November 05, 2009 3:10 PM
> > > > To: l...@yahoogroups.com
> > > > Subject: [lpc2000] Weird again... Writing 0 to USBDEVINTEN causing a Data Abort interrupt
> > > >
> > > > I am working in the USB INIT section of my transition from LPC2144 to
> > > > the LPC2366 (USB worked in the 2144) and as soon as a 00000
> > > > is written to the USB device interrupt enable register, it pops
> > > > right over to int vector 0x10 Data Abort. A "0" to that register
> > > > shouldn't do anything, should it ?? The Vic Protection register
> > > > has been written as 0 early on in the initialization code if USER/PRIVELEDGED mode should make any difference.
> > > >
> > > > What kinds of things could cause a vector to Abort in this case ?
> > > >
> > > > Thanks,
> > > > boB
> > > >
> > > > USBDEVINTEN = 0; //0xFFE0C204
> > > >
> > > > causes a data abort interrupt.
> > > >
> > > > 0x0000 0010 Data Abort (data access memory fault)
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )