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

Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??

I am having a heck of a time trying to get the old LPCUSB code to work on my LPC2366 board. Rev D NXP silicon. This worked great on the LPC2144 chip but I can not for the life of me get this to initialize the hardware without Data abort exceptions on the LPC2366. I can sometimes get past the data aborts if I use the JTAG and stop it here and there and then continue, but will still not connect.

I know that others have gotten LPCUSB to work on these parts but am hoping that there is maybe some new knowledge here, not found on our archives.

I believe that I have handled the Register addressing changes correctly. The USB peripheral appears to be getting clocks too, AFAIK. Problem is that I cannot exactly catch the data abort with the JTAG in the exact spot that it is happening.

IRQ's have to be enabled in order for me to get the Data Abort also.

It looks like the last R14, Link Register (LR) before the abort was in the VCOM_init(); code, but I know it is getting past this point, somewhat.

IAR's JTAG debugging windows suggest that I have an interrupt pending by showing USB_INT_REQ_LP and USB_need_clk as high.

A couple of differences I notice are the USB CLOCK now comes from a divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and some registers have been re-located, compared to the LPC214X parts.

Also, WHY is it that IAR had to change their REGISTER defines to UPPER CASE from the combined UPper and Lower case they used to have for the REGISTER definitions used in the LPC23xx user manual ?? That also makes it hard to upgrade to a newer part.

Any hints are graciously welcome.

Thanks,
boB

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



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

--- In l...@yahoogroups.com, "bobtransformer" wrote:
>
> A couple of differences I notice are the USB CLOCK now comes from
> a divider on the OUTPUT of the regular PLL, rather than its OWN
> PLL, and some registers have been re-located, compared to the
> LPC214X parts.
>

There were very significant changes to the way PLL, VIC etc. works going from LPC21xx to LPC23xx. Read the NXP Application Note:

AN10576 "Migrating to the LPC2300/2400 family" and make sure that you have accounted for everything mentioned there:

http://www.standardics.nxp.com/products/lpc2000/lpc23xx/~LPC2368/#Literature

--
Chris Burrows
CFB Software
Armaide: LPC2xxx Oberon-07 Development System
http://www.armaide.com

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



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

--- In l...@yahoogroups.com, "bobtransformer" wrote:
> Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??
>
> I am having a heck of a time trying to get the old LPCUSB code to work on my LPC2366 board. Rev D NXP silicon. This worked great on the LPC2144 chip but I can not for the life of me get this to initialize the hardware without Data abort exceptions on the LPC2366. I can sometimes get past the data aborts if I use the JTAG and stop it here and there and then continue, but will still not connect.
>
> I know that others have gotten LPCUSB to work on these parts but am hoping that there is maybe some new knowledge here, not found on our archives.
>
> I believe that I have handled the Register addressing changes correctly. The USB peripheral appears to be getting clocks too, AFAIK. Problem is that I cannot exactly catch the data abort with the JTAG in the exact spot that it is happening.
>
> IRQ's have to be enabled in order for me to get the Data Abort also.
>
> It looks like the last R14, Link Register (LR) before the abort was in the VCOM_init(); code, but I know it is getting past this point, somewhat.
>
> IAR's JTAG debugging windows suggest that I have an interrupt pending by showing USB_INT_REQ_LP and USB_need_clk as high.
>
> A couple of differences I notice are the USB CLOCK now comes from a divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and some registers have been re-located, compared to the LPC214X parts.
>
> Also, WHY is it that IAR had to change their REGISTER defines to UPPER CASE from the combined UPper and Lower case they used to have for the REGISTER definitions used in the LPC23xx user manual ?? That also makes it hard to upgrade to a newer part.
>
> Any hints are graciously welcome.
>
> Thanks,
> boB
>

My problem wouldn't be related to a -0.173% inaccuracy from being right on 48.0 MHz, would it ?? I am using a 12.5 MHz clock oscillator in this project which means that 288 MHz is 23.04 times 12.5 MHz. Nahhhh... It can't be ~THAT~ finicky, can it ??

boB

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



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

--- In l...@yahoogroups.com, "cfbsoftware1" wrote:
> --- In l...@yahoogroups.com, "bobtransformer" wrote:
> >
> > A couple of differences I notice are the USB CLOCK now comes from
> > a divider on the OUTPUT of the regular PLL, rather than its OWN
> > PLL, and some registers have been re-located, compared to the
> > LPC214X parts.
> > There were very significant changes to the way PLL, VIC etc. works going from LPC21xx to LPC23xx. Read the NXP Application Note:
>
> AN10576 "Migrating to the LPC2300/2400 family" and make sure that you have accounted for everything mentioned there:
>
> http://www.standardics.nxp.com/products/lpc2000/lpc23xx/~LPC2368/#Literature
>
> --
> Chris Burrows
> CFB Software
> Armaide: LPC2xxx Oberon-07 Development System
> http://www.armaide.com
>

Thanks Chris.
I aware of the different PLL and USB clocking scheme and think it is simpler than it was before.

This app note still leaves a LOT of things out, like USB register mapping and PWM operational differences, for example. That is, as far as I can tell.

I will continue to bang my head on this.

Much appreciated !

boB

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



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

If it's any help to your confidence, I have LPCUSB working fine on an
lpc2468. I did also upgrade to the latest LPCUSB that includes some
suggestions from Chinzei to do with bulk mode, but I doubt this is your
problem (they are improvements rather than go/no-go).
Yes, you need to deal with the different PINSEL, and different clocking.
Since the 2468 also has a USB host, you also have to configure and
program the device/host arrangement and the clocks in new registers.

Cheers,
Bruce
-----Original Message-----
From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
Of bobtransformer
Sent: Saturday, 7 November 2009 1:58 PM
To: l...@yahoogroups.com
Subject: [lpc2000] LPCUSB on LPC23xx not working still....
Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??

I am having a heck of a time trying to get the old LPCUSB code to work
on my LPC2366 board. Rev D NXP silicon. This worked great on the
LPC2144 chip but I can not for the life of me get this to initialize the
hardware without Data abort exceptions on the LPC2366. I can sometimes
get past the data aborts if I use the JTAG and stop it here and there
and then continue, but will still not connect.

I know that others have gotten LPCUSB to work on these parts but am
hoping that there is maybe some new knowledge here, not found on our
archives.

I believe that I have handled the Register addressing changes correctly.
The USB peripheral appears to be getting clocks too, AFAIK. Problem is
that I cannot exactly catch the data abort with the JTAG in the exact
spot that it is happening.

IRQ's have to be enabled in order for me to get the Data Abort also.

It looks like the last R14, Link Register (LR) before the abort was in
the VCOM_init(); code, but I know it is getting past this point,
somewhat.

IAR's JTAG debugging windows suggest that I have an interrupt pending by
showing USB_INT_REQ_LP and USB_need_clk as high.

A couple of differences I notice are the USB CLOCK now comes from a
divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and
some registers have been re-located, compared to the LPC214X parts.

Also, WHY is it that IAR had to change their REGISTER defines to UPPER
CASE from the combined UPper and Lower case they used to have for the
REGISTER definitions used in the LPC23xx user manual ?? That also makes
it hard to upgrade to a newer part.

Any hints are graciously welcome.

Thanks,
boB

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


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

--- In l...@yahoogroups.com, "Bruce Paterson" wrote:
>
> If it's any help to your confidence, I have LPCUSB working fine on an
> lpc2468. I did also upgrade to the latest LPCUSB that includes some
> suggestions from Chinzei to do with bulk mode, but I doubt this is your
> problem (they are improvements rather than go/no-go).
> Yes, you need to deal with the different PINSEL, and different clocking.
> Since the 2468 also has a USB host, you also have to configure and
> program the device/host arrangement and the clocks in new registers.
>
> Cheers,
> Bruce
Thank you Bruce ! That is definitely encouraging !

I am only using the USB device mode and not OTG or Host mode.
This is the mode I was using LPCUSB in on the LPC2144 which is working great.

Today I am trying to find out why, when I set breakpoints with the JTAG, the code continues on past the global IRQ enable, but if I do not set the breakpoint, and then stop the code, I get stuck in a Data Abort vector loop...

Then, if I reset the CPSR with the SPSR, it seems to indicate to me that the code at least got past the __interrupt_enable and to the rest of main() before the data abort.

I am NOT getting a breakpoint hit on at the USB Interrupt entry point but the VICRawIntr USB bit IS set, (USB Interrupt pending), and VICVECTADDR0 is pointing to the proper USB interrupt code location.

Right after Global IRQ __interrupt_enable(), I have a breakpoint set to USBHwConnect(TRUE); which succesfully break here. Continuing from there, (F5), code continues running to the rest of main() into some LED blink code but no interrupts occur. (interrupts are enabled and USB is pending)

....................

After writing the above notes, but NOT posting this message yet...

I notice that I am NOT able to set a breakpoint anywhere inside the IRQ HANDLER routine.

Then, I noticed that IRQ Vector at 0x0018 is pointing to the Data Abort loop, as is most (or all) of the other vector addresses !

These 2 things are possibly bringing me closer to some resolution, but then WHY are I NOT getting stuck at Data Abort after single-stepping, BUT the VIC registers clearly show that I should be getting an interrupt because the USB RAW INTERRUPT and Enable bits are set, and CPSR I bit is clear ???

Very strange, I think.

What is it with the JTAG and why does it interfere so strangely ???
Continuing on now...

Thanks,
boB

> -----Original Message-----
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
> Of bobtransformer
> Sent: Saturday, 7 November 2009 1:58 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] LPCUSB on LPC23xx not working still....
> Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??
>
> I am having a heck of a time trying to get the old LPCUSB code to work
> on my LPC2366 board. Rev D NXP silicon. This worked great on the
> LPC2144 chip but I can not for the life of me get this to initialize the
> hardware without Data abort exceptions on the LPC2366. I can sometimes
> get past the data aborts if I use the JTAG and stop it here and there
> and then continue, but will still not connect.
>
> I know that others have gotten LPCUSB to work on these parts but am
> hoping that there is maybe some new knowledge here, not found on our
> archives.
>
> I believe that I have handled the Register addressing changes correctly.
> The USB peripheral appears to be getting clocks too, AFAIK. Problem is
> that I cannot exactly catch the data abort with the JTAG in the exact
> spot that it is happening.
>
> IRQ's have to be enabled in order for me to get the Data Abort also.
>
> It looks like the last R14, Link Register (LR) before the abort was in
> the VCOM_init(); code, but I know it is getting past this point,
> somewhat.
>
> IAR's JTAG debugging windows suggest that I have an interrupt pending by
> showing USB_INT_REQ_LP and USB_need_clk as high.
>
> A couple of differences I notice are the USB CLOCK now comes from a
> divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and
> some registers have been re-located, compared to the LPC214X parts.
>
> Also, WHY is it that IAR had to change their REGISTER defines to UPPER
> CASE from the combined UPper and Lower case they used to have for the
> REGISTER definitions used in the LPC23xx user manual ?? That also makes
> it hard to upgrade to a newer part.
>
> Any hints are graciously welcome.
>
> Thanks,
> boB
> ------------------------------------



(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, "Bruce Paterson" wrote:
> >
> > If it's any help to your confidence, I have LPCUSB working fine on an
> > lpc2468. I did also upgrade to the latest LPCUSB that includes some
> > suggestions from Chinzei to do with bulk mode, but I doubt this is your
> > problem (they are improvements rather than go/no-go).
> > Yes, you need to deal with the different PINSEL, and different clocking.
> > Since the 2468 also has a USB host, you also have to configure and
> > program the device/host arrangement and the clocks in new registers.
> >
> > Cheers,
> > Bruce
> Thank you Bruce ! That is definitely encouraging !
>
> I am only using the USB device mode and not OTG or Host mode.
> This is the mode I was using LPCUSB in on the LPC2144 which is working great.
>
> Today I am trying to find out why, when I set breakpoints with the JTAG, the code continues on past the global IRQ enable, but if I do not set the breakpoint, and then stop the code, I get stuck in a Data Abort vector loop...
>
> Then, if I reset the CPSR with the SPSR, it seems to indicate to me that the code at least got past the __interrupt_enable and to the rest of main() before the data abort.
>
> I am NOT getting a breakpoint hit on at the USB Interrupt entry point but the VICRawIntr USB bit IS set, (USB Interrupt pending), and VICVECTADDR0 is pointing to the proper USB interrupt code location.
>
> Right after Global IRQ __interrupt_enable(), I have a breakpoint set to USBHwConnect(TRUE); which succesfully break here. Continuing from there, (F5), code continues running to the rest of main() into some LED blink code but no interrupts occur. (interrupts are enabled and USB is pending)
>
> ....................
>
> After writing the above notes, but NOT posting this message yet...
>
> I notice that I am NOT able to set a breakpoint anywhere inside the IRQ HANDLER routine.
>
> Then, I noticed that IRQ Vector at 0x0018 is pointing to the Data Abort loop, as is most (or all) of the other vector addresses !
>
> These 2 things are possibly bringing me closer to some resolution, but then WHY are I NOT getting stuck at Data Abort after single-stepping, BUT the VIC registers clearly show that I should be getting an interrupt because the USB RAW INTERRUPT and Enable bits are set, and CPSR I bit is clear ???
>
> Very strange, I think.
>
> What is it with the JTAG and why does it interfere so strangely ???
> Continuing on now...
>
> Thanks,
> boB
>
In addition, to my previous posting, this is what I am seeing in my C-spy/JTAG debug screen for the interrupt vectors at low memory.
Why would I see the message, "USR_MODE:" sitting at 0x10 and 0x14??
Notice that everything seems to be pointing to the Abort Handler, except for __iar_program_start
My .icf file has the usual line,

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
The compiler obviously knows that I cannot set a breakpoint at the IRQ handler. Why might I be having all these Abort Handler references ?

Mucho-Thank-You

boB
LDR PC,Reset_Addr ; Reset
__vector:
__iar_init$$done:
0x0: 0xe59ff018 LDR pc, Reset_Addr [0x20] ; __iar_program_start
LDR PC,Undefined_Addr ; Undefined instructions
0x4: 0xe59ff018 LDR pc, Undefined_Addr [0x24] ; Abort_Handler
LDR PC,SWI_Addr ; Software interrupt (SWI/SVC)
0x8: 0xe59ff018 LDR pc, SWI_Addr [0x28] ; Abort_Handler
LDR PC,Prefetch_Addr ; Prefetch abort
0xc: 0xe59ff018 LDR pc, Prefetch_Addr [0x2c] ; Abort_Handler
LDR PC,Abort_Addr ; Data abort
USR_MODE:
0x10: 0xe59ff018 LDR pc, Abort_Addr [0x30] ; Abort_Handler
0x14: 0xb8a06f60 STMLT r0!, {r5, r6, r8-r11, sp, lr}
LDR PC,IRQ_Addr ; IRQ
0x18: 0xe59ff014 LDR pc, IRQ_Addr [0x34] ; Abort_Handler
LDR PC,FIQ_Addr ; FIQ
0x1c: 0xe59ff014 LDR pc, FIQ_Addr [0x38] ; Abort_Handler
Reset_Addr:
0x20: 0x00000200 DC32 __iar_program_start
Undefined_Addr:
0x24: 0x000025e0 DC32 Abort_Handler
SWI_Addr:
0x28: 0x000025e0 DC32 Abort_Handler
Prefetch_Addr:
0x2c: 0x000025e0 DC32 Abort_Handler
Abort_Addr:
0x30: 0x000025e0 DC32 Abort_Handler
IRQ_Addr:
0x34: 0x000025e0 DC32 Abort_Handler
FIQ_Addr:
0x38: 0x000025e0 DC32 Abort_Handler
0x3c: 0xffffffff [ARM instr]
0x40: 0xffffffff [ARM instr]

>
> > -----Original Message-----
> > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
> > Of bobtransformer
> > Sent: Saturday, 7 November 2009 1:58 PM
> > To: l...@yahoogroups.com
> > Subject: [lpc2000] LPCUSB on LPC23xx not working still....
> >
> >
> > Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??
> >
> > I am having a heck of a time trying to get the old LPCUSB code to work
> > on my LPC2366 board. Rev D NXP silicon. This worked great on the
> > LPC2144 chip but I can not for the life of me get this to initialize the
> > hardware without Data abort exceptions on the LPC2366. I can sometimes
> > get past the data aborts if I use the JTAG and stop it here and there
> > and then continue, but will still not connect.
> >
> > I know that others have gotten LPCUSB to work on these parts but am
> > hoping that there is maybe some new knowledge here, not found on our
> > archives.
> >
> > I believe that I have handled the Register addressing changes correctly.
> > The USB peripheral appears to be getting clocks too, AFAIK. Problem is
> > that I cannot exactly catch the data abort with the JTAG in the exact
> > spot that it is happening.
> >
> > IRQ's have to be enabled in order for me to get the Data Abort also.
> >
> > It looks like the last R14, Link Register (LR) before the abort was in
> > the VCOM_init(); code, but I know it is getting past this point,
> > somewhat.
> >
> > IAR's JTAG debugging windows suggest that I have an interrupt pending by
> > showing USB_INT_REQ_LP and USB_need_clk as high.
> >
> > A couple of differences I notice are the USB CLOCK now comes from a
> > divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and
> > some registers have been re-located, compared to the LPC214X parts.
> >
> > Also, WHY is it that IAR had to change their REGISTER defines to UPPER
> > CASE from the combined UPper and Lower case they used to have for the
> > REGISTER definitions used in the LPC23xx user manual ?? That also makes
> > it hard to upgrade to a newer part.
> >
> > Any hints are graciously welcome.
> >
> > Thanks,
> > boB
> >
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> >



(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, "Bruce Paterson" wrote:
> > >
> > > If it's any help to your confidence, I have LPCUSB working fine on an
> > > lpc2468. I did also upgrade to the latest LPCUSB that includes some
> > > suggestions from Chinzei to do with bulk mode, but I doubt this is your
> > > problem (they are improvements rather than go/no-go).
> > > Yes, you need to deal with the different PINSEL, and different clocking.
> > > Since the 2468 also has a USB host, you also have to configure and
> > > program the device/host arrangement and the clocks in new registers.
> > >
> > > Cheers,
> > > Bruce
> >
> >
> > Thank you Bruce ! That is definitely encouraging !
> >
> > I am only using the USB device mode and not OTG or Host mode.
> > This is the mode I was using LPCUSB in on the LPC2144 which is working great.
> >
> > Today I am trying to find out why, when I set breakpoints with the JTAG, the code continues on past the global IRQ enable, but if I do not set the breakpoint, and then stop the code, I get stuck in a Data Abort vector loop...
> >
> > Then, if I reset the CPSR with the SPSR, it seems to indicate to me that the code at least got past the __interrupt_enable and to the rest of main() before the data abort.
> >
> > I am NOT getting a breakpoint hit on at the USB Interrupt entry point but the VICRawIntr USB bit IS set, (USB Interrupt pending), and VICVECTADDR0 is pointing to the proper USB interrupt code location.
> >
> > Right after Global IRQ __interrupt_enable(), I have a breakpoint set to USBHwConnect(TRUE); which succesfully break here. Continuing from there, (F5), code continues running to the rest of main() into some LED blink code but no interrupts occur. (interrupts are enabled and USB is pending)
> >
> > ....................
> >
> > After writing the above notes, but NOT posting this message yet...
> >
> > I notice that I am NOT able to set a breakpoint anywhere inside the IRQ HANDLER routine.
Well, Looking at my OTHER LPC2366 and IAR EW version 5.4 project that IS working, (no USB though), I remember that the IRQ funtion name MUST MATCH that name that is in the STARTUP (cstartup) file !!!
It's __root __irq __arm void IRQ_Handler(void)..... My function name was irq_handler(void) as it has always been in the past EW versions.

It's still not working (yet), but I expect to have this running pretty soon, now. I suppose it doesn't hurt to have some case history stuff in the archives of this sort for others (and myself) to refer to in the future.
Thanks,
boB

> >
> > Then, I noticed that IRQ Vector at 0x0018 is pointing to the Data Abort loop, as is most (or all) of the other vector addresses !
> >
> > These 2 things are possibly bringing me closer to some resolution, but then WHY are I NOT getting stuck at Data Abort after single-stepping, BUT the VIC registers clearly show that I should be getting an interrupt because the USB RAW INTERRUPT and Enable bits are set, and CPSR I bit is clear ???
> >
> > Very strange, I think.
> >
> > What is it with the JTAG and why does it interfere so strangely ???
> >
> >
> > Continuing on now...
> >
> > Thanks,
> > boB
> >
> In addition, to my previous posting, this is what I am seeing in my C-spy/JTAG debug screen for the interrupt vectors at low memory.
> Why would I see the message, "USR_MODE:" sitting at 0x10 and 0x14??
> Notice that everything seems to be pointing to the Abort Handler, except for __iar_program_start
> My .icf file has the usual line,
>
> place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
> The compiler obviously knows that I cannot set a breakpoint at the IRQ handler. Why might I be having all these Abort Handler references ?
>
> Mucho-Thank-You
>
> boB
> LDR PC,Reset_Addr ; Reset
> __vector:
> __iar_init$$done:
> 0x0: 0xe59ff018 LDR pc, Reset_Addr [0x20] ; __iar_program_start
> LDR PC,Undefined_Addr ; Undefined instructions
> 0x4: 0xe59ff018 LDR pc, Undefined_Addr [0x24] ; Abort_Handler
> LDR PC,SWI_Addr ; Software interrupt (SWI/SVC)
> 0x8: 0xe59ff018 LDR pc, SWI_Addr [0x28] ; Abort_Handler
> LDR PC,Prefetch_Addr ; Prefetch abort
> 0xc: 0xe59ff018 LDR pc, Prefetch_Addr [0x2c] ; Abort_Handler
> LDR PC,Abort_Addr ; Data abort
> USR_MODE:
> 0x10: 0xe59ff018 LDR pc, Abort_Addr [0x30] ; Abort_Handler
> 0x14: 0xb8a06f60 STMLT r0!, {r5, r6, r8-r11, sp, lr}
> LDR PC,IRQ_Addr ; IRQ
> 0x18: 0xe59ff014 LDR pc, IRQ_Addr [0x34] ; Abort_Handler
> LDR PC,FIQ_Addr ; FIQ
> 0x1c: 0xe59ff014 LDR pc, FIQ_Addr [0x38] ; Abort_Handler
> Reset_Addr:
> 0x20: 0x00000200 DC32 __iar_program_start
> Undefined_Addr:
> 0x24: 0x000025e0 DC32 Abort_Handler
> SWI_Addr:
> 0x28: 0x000025e0 DC32 Abort_Handler
> Prefetch_Addr:
> 0x2c: 0x000025e0 DC32 Abort_Handler
> Abort_Addr:
> 0x30: 0x000025e0 DC32 Abort_Handler
> IRQ_Addr:
> 0x34: 0x000025e0 DC32 Abort_Handler
> FIQ_Addr:
> 0x38: 0x000025e0 DC32 Abort_Handler
> 0x3c: 0xffffffff [ARM instr]
> 0x40: 0xffffffff [ARM instr]
>
>
> >
> >
> >
> > > -----Original Message-----
> > > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
> > > Of bobtransformer
> > > Sent: Saturday, 7 November 2009 1:58 PM
> > > To: l...@yahoogroups.com
> > > Subject: [lpc2000] LPCUSB on LPC23xx not working still....
> > >
> > >
> > > Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??
> > >
> > > I am having a heck of a time trying to get the old LPCUSB code to work
> > > on my LPC2366 board. Rev D NXP silicon. This worked great on the
> > > LPC2144 chip but I can not for the life of me get this to initialize the
> > > hardware without Data abort exceptions on the LPC2366. I can sometimes
> > > get past the data aborts if I use the JTAG and stop it here and there
> > > and then continue, but will still not connect.
> > >
> > > I know that others have gotten LPCUSB to work on these parts but am
> > > hoping that there is maybe some new knowledge here, not found on our
> > > archives.
> > >
> > > I believe that I have handled the Register addressing changes correctly.
> > > The USB peripheral appears to be getting clocks too, AFAIK. Problem is
> > > that I cannot exactly catch the data abort with the JTAG in the exact
> > > spot that it is happening.
> > >
> > > IRQ's have to be enabled in order for me to get the Data Abort also.
> > >
> > > It looks like the last R14, Link Register (LR) before the abort was in
> > > the VCOM_init(); code, but I know it is getting past this point,
> > > somewhat.
> > >
> > > IAR's JTAG debugging windows suggest that I have an interrupt pending by
> > > showing USB_INT_REQ_LP and USB_need_clk as high.
> > >
> > > A couple of differences I notice are the USB CLOCK now comes from a
> > > divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and
> > > some registers have been re-located, compared to the LPC214X parts.
> > >
> > > Also, WHY is it that IAR had to change their REGISTER defines to UPPER
> > > CASE from the combined UPper and Lower case they used to have for the
> > > REGISTER definitions used in the LPC23xx user manual ?? That also makes
> > > it hard to upgrade to a newer part.
> > >
> > > Any hints are graciously welcome.
> > >
> > > Thanks,
> > > boB
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > >



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

Ahhhh
One thing I neglected to mention; I'm not running it in interrupt mode.
Perhaps try running it in polling mode, and if you get that working,
move onto ints.
The reason I'm not using interrupt mode is a problem to do with
integration of the common IRQ between code for the host port and LPCUSB
slave code. I could run either in interrupt mode with the other
disabled, but both was a disaster. Can't recall the exact issues.

Cheers,
Bruce

-----Original Message-----
From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
Of bobtransformer
Sent: Monday, 9 November 2009 2:09 PM
To: l...@yahoogroups.com
Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....

--- In l...@yahoogroups.com, "bobtransformer" wrote:
>
> --- In l...@yahoogroups.com, "Bruce Paterson"
wrote:
> >
> > If it's any help to your confidence, I have LPCUSB working fine on
an
> > lpc2468. I did also upgrade to the latest LPCUSB that includes some
> > suggestions from Chinzei to do with bulk mode, but I doubt this is
your
> > problem (they are improvements rather than go/no-go).
> > Yes, you need to deal with the different PINSEL, and different
clocking.
> > Since the 2468 also has a USB host, you also have to configure and
> > program the device/host arrangement and the clocks in new registers.
> >
> > Cheers,
> > Bruce
> Thank you Bruce ! That is definitely encouraging !
>
> I am only using the USB device mode and not OTG or Host mode.
> This is the mode I was using LPCUSB in on the LPC2144 which is working
great.
>
> Today I am trying to find out why, when I set breakpoints with the
JTAG, the code continues on past the global IRQ enable, but if I do not
set the breakpoint, and then stop the code, I get stuck in a Data Abort
vector loop...
>
> Then, if I reset the CPSR with the SPSR, it seems to indicate to me
that the code at least got past the __interrupt_enable and to the rest
of main() before the data abort.
>
> I am NOT getting a breakpoint hit on at the USB Interrupt entry point
but the VICRawIntr USB bit IS set, (USB Interrupt pending), and
VICVECTADDR0 is pointing to the proper USB interrupt code location.
>
> Right after Global IRQ __interrupt_enable(), I have a breakpoint set
to USBHwConnect(TRUE); which succesfully break here. Continuing from
there, (F5), code continues running to the rest of main() into some LED
blink code but no interrupts occur. (interrupts are enabled and USB is
pending)
>
> ....................
>
> After writing the above notes, but NOT posting this message yet...
>
> I notice that I am NOT able to set a breakpoint anywhere inside the
IRQ HANDLER routine.
>
> Then, I noticed that IRQ Vector at 0x0018 is pointing to the Data
Abort loop, as is most (or all) of the other vector addresses !
>
> These 2 things are possibly bringing me closer to some resolution, but
then WHY are I NOT getting stuck at Data Abort after single-stepping,
BUT the VIC registers clearly show that I should be getting an interrupt
because the USB RAW INTERRUPT and Enable bits are set, and CPSR I bit is
clear ???
>
> Very strange, I think.
>
> What is it with the JTAG and why does it interfere so strangely ???
> Continuing on now...
>
> Thanks,
> boB
>
In addition, to my previous posting, this is what I am seeing in my
C-spy/JTAG debug screen for the interrupt vectors at low memory.
Why would I see the message, "USR_MODE:" sitting at 0x10 and 0x14??
Notice that everything seems to be pointing to the Abort Handler, except
for __iar_program_start
My .icf file has the usual line,

place at address mem:__ICFEDIT_intvec_start__ { readonly section
.intvec };
The compiler obviously knows that I cannot set a breakpoint at the IRQ
handler. Why might I be having all these Abort Handler references ?

Mucho-Thank-You

boB
LDR PC,Reset_Addr ; Reset
__vector:
__iar_init$$done:
0x0: 0xe59ff018 LDR pc, Reset_Addr [0x20] ;
__iar_program_start
LDR PC,Undefined_Addr ; Undefined instructions
0x4: 0xe59ff018 LDR pc, Undefined_Addr [0x24] ;
Abort_Handler
LDR PC,SWI_Addr ; Software interrupt (SWI/SVC)
0x8: 0xe59ff018 LDR pc, SWI_Addr [0x28] ;
Abort_Handler
LDR PC,Prefetch_Addr ; Prefetch abort
0xc: 0xe59ff018 LDR pc, Prefetch_Addr [0x2c] ;
Abort_Handler
LDR PC,Abort_Addr ; Data abort
USR_MODE:
0x10: 0xe59ff018 LDR pc, Abort_Addr [0x30] ;
Abort_Handler
0x14: 0xb8a06f60 STMLT r0!, {r5, r6, r8-r11, sp, lr}
LDR PC,IRQ_Addr ; IRQ
0x18: 0xe59ff014 LDR pc, IRQ_Addr [0x34] ;
Abort_Handler
LDR PC,FIQ_Addr ; FIQ
0x1c: 0xe59ff014 LDR pc, FIQ_Addr [0x38] ;
Abort_Handler
Reset_Addr:
0x20: 0x00000200 DC32 __iar_program_start
Undefined_Addr:
0x24: 0x000025e0 DC32 Abort_Handler
SWI_Addr:
0x28: 0x000025e0 DC32 Abort_Handler
Prefetch_Addr:
0x2c: 0x000025e0 DC32 Abort_Handler
Abort_Addr:
0x30: 0x000025e0 DC32 Abort_Handler
IRQ_Addr:
0x34: 0x000025e0 DC32 Abort_Handler
FIQ_Addr:
0x38: 0x000025e0 DC32 Abort_Handler
0x3c: 0xffffffff [ARM instr]
0x40: 0xffffffff [ARM instr]

>
> > -----Original Message-----
> > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On
Behalf
> > Of bobtransformer
> > Sent: Saturday, 7 November 2009 1:58 PM
> > To: l...@yahoogroups.com
> > Subject: [lpc2000] LPCUSB on LPC23xx not working still....
> >
> >
> > Has there been any new-ish activity with LPCUSB on the LPC23xx parts
??
> >
> > I am having a heck of a time trying to get the old LPCUSB code to
work
> > on my LPC2366 board. Rev D NXP silicon. This worked great on the
> > LPC2144 chip but I can not for the life of me get this to initialize
the
> > hardware without Data abort exceptions on the LPC2366. I can
sometimes
> > get past the data aborts if I use the JTAG and stop it here and
there
> > and then continue, but will still not connect.
> >
> > I know that others have gotten LPCUSB to work on these parts but am
> > hoping that there is maybe some new knowledge here, not found on our
> > archives.
> >
> > I believe that I have handled the Register addressing changes
correctly.
> > The USB peripheral appears to be getting clocks too, AFAIK. Problem
is
> > that I cannot exactly catch the data abort with the JTAG in the
exact
> > spot that it is happening.
> >
> > IRQ's have to be enabled in order for me to get the Data Abort also.
> >
> > It looks like the last R14, Link Register (LR) before the abort was
in
> > the VCOM_init(); code, but I know it is getting past this point,
> > somewhat.
> >
> > IAR's JTAG debugging windows suggest that I have an interrupt
pending by
> > showing USB_INT_REQ_LP and USB_need_clk as high.
> >
> > A couple of differences I notice are the USB CLOCK now comes from a
> > divider on the OUTPUT of the regular PLL, rather than its OWN PLL,
and
> > some registers have been re-located, compared to the LPC214X parts.
> >
> > Also, WHY is it that IAR had to change their REGISTER defines to
UPPER
> > CASE from the combined UPper and Lower case they used to have for
the
> > REGISTER definitions used in the LPC23xx user manual ?? That also
makes
> > it hard to upgrade to a newer part.
> >
> > Any hints are graciously welcome.
> >
> > Thanks,
> > boB
> >
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> >



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

--- In l...@yahoogroups.com, "Bruce Paterson" wrote:
>
> Ahhhh
> One thing I neglected to mention; I'm not running it in interrupt mode.
> Perhaps try running it in polling mode, and if you get that working,
> move onto ints.
> The reason I'm not using interrupt mode is a problem to do with
> integration of the common IRQ between code for the host port and LPCUSB
> slave code. I could run either in interrupt mode with the other
> disabled, but both was a disaster. Can't recall the exact issues.
>
> Cheers,
> Bruce
>
I know that earlier Revs of sily-con had bugs that required you to poll the Vbus (I think) pin of the LPC23xx. Fortunately we have Rev D parts and supposedly they have very few bugs now.

My original project using LPCUSB was running is IRQ mode and didn't seem to have any problems in that respect.

I may just have to try your polling method though. I am seeing the IRQ handler get called but the VICADDRESS is set to 0x0000000 and it's GOTTA be the USB that is calling this ! But, the IRQ code sees it as a null vector and just exits. I'll figure this out somehow, but what is strange is that in the main() while(1) loop, the CPSR I bit is clear, (IRQ ENABLED), and the Raw interrupt USB bit is set and the USB interrupt is still set but the IRQ interrupt does NOT get called again at that point. Maybe I'm not exiting my IRQ code properly, but it's the same IRQ code I use succesfuly for everything else.

Thanks again for letting me blab on about this. You can bet that I will keep you posted ! If nothing else, it helps me think better, sometimes. I'll try to keep it sane though.

boB

> -----Original Message-----
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
> Of bobtransformer
> Sent: Monday, 9 November 2009 2:09 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....
>
> --- In l...@yahoogroups.com, "bobtransformer" wrote:
> >
> >
> >
> > --- In l...@yahoogroups.com, "Bruce Paterson"
> wrote:
> > >
> > > If it's any help to your confidence, I have LPCUSB working fine on
> an
> > > lpc2468. I did also upgrade to the latest LPCUSB that includes some
> > > suggestions from Chinzei to do with bulk mode, but I doubt this is
> your
> > > problem (they are improvements rather than go/no-go).
> > > Yes, you need to deal with the different PINSEL, and different
> clocking.
> > > Since the 2468 also has a USB host, you also have to configure and
> > > program the device/host arrangement and the clocks in new registers.
> > >
> > > Cheers,
> > > Bruce
> >
> >
> > Thank you Bruce ! That is definitely encouraging !
> >
> > I am only using the USB device mode and not OTG or Host mode.
> > This is the mode I was using LPCUSB in on the LPC2144 which is working
> great.
> >
> > Today I am trying to find out why, when I set breakpoints with the
> JTAG, the code continues on past the global IRQ enable, but if I do not
> set the breakpoint, and then stop the code, I get stuck in a Data Abort
> vector loop...
> >
> > Then, if I reset the CPSR with the SPSR, it seems to indicate to me
> that the code at least got past the __interrupt_enable and to the rest
> of main() before the data abort.
> >
> > I am NOT getting a breakpoint hit on at the USB Interrupt entry point
> but the VICRawIntr USB bit IS set, (USB Interrupt pending), and
> VICVECTADDR0 is pointing to the proper USB interrupt code location.
> >
> > Right after Global IRQ __interrupt_enable(), I have a breakpoint set
> to USBHwConnect(TRUE); which succesfully break here. Continuing from
> there, (F5), code continues running to the rest of main() into some LED
> blink code but no interrupts occur. (interrupts are enabled and USB is
> pending)
> >
> > ....................
> >
> > After writing the above notes, but NOT posting this message yet...
> >
> > I notice that I am NOT able to set a breakpoint anywhere inside the
> IRQ HANDLER routine.
> >
> > Then, I noticed that IRQ Vector at 0x0018 is pointing to the Data
> Abort loop, as is most (or all) of the other vector addresses !
> >
> > These 2 things are possibly bringing me closer to some resolution, but
> then WHY are I NOT getting stuck at Data Abort after single-stepping,
> BUT the VIC registers clearly show that I should be getting an interrupt
> because the USB RAW INTERRUPT and Enable bits are set, and CPSR I bit is
> clear ???
> >
> > Very strange, I think.
> >
> > What is it with the JTAG and why does it interfere so strangely ???
> >
> >
> > Continuing on now...
> >
> > Thanks,
> > boB
> >
> In addition, to my previous posting, this is what I am seeing in my
> C-spy/JTAG debug screen for the interrupt vectors at low memory.
> Why would I see the message, "USR_MODE:" sitting at 0x10 and 0x14??
> Notice that everything seems to be pointing to the Abort Handler, except
> for __iar_program_start
> My .icf file has the usual line,
>
> place at address mem:__ICFEDIT_intvec_start__ { readonly section
> .intvec };
> The compiler obviously knows that I cannot set a breakpoint at the IRQ
> handler. Why might I be having all these Abort Handler references ?
>
> Mucho-Thank-You
>
> boB
> LDR PC,Reset_Addr ; Reset
> __vector:
> __iar_init$$done:
> 0x0: 0xe59ff018 LDR pc, Reset_Addr [0x20] ;
> __iar_program_start
> LDR PC,Undefined_Addr ; Undefined instructions
> 0x4: 0xe59ff018 LDR pc, Undefined_Addr [0x24] ;
> Abort_Handler
> LDR PC,SWI_Addr ; Software interrupt (SWI/SVC)
> 0x8: 0xe59ff018 LDR pc, SWI_Addr [0x28] ;
> Abort_Handler
> LDR PC,Prefetch_Addr ; Prefetch abort
> 0xc: 0xe59ff018 LDR pc, Prefetch_Addr [0x2c] ;
> Abort_Handler
> LDR PC,Abort_Addr ; Data abort
> USR_MODE:
> 0x10: 0xe59ff018 LDR pc, Abort_Addr [0x30] ;
> Abort_Handler
> 0x14: 0xb8a06f60 STMLT r0!, {r5, r6, r8-r11, sp, lr}
> LDR PC,IRQ_Addr ; IRQ
> 0x18: 0xe59ff014 LDR pc, IRQ_Addr [0x34] ;
> Abort_Handler
> LDR PC,FIQ_Addr ; FIQ
> 0x1c: 0xe59ff014 LDR pc, FIQ_Addr [0x38] ;
> Abort_Handler
> Reset_Addr:
> 0x20: 0x00000200 DC32 __iar_program_start
> Undefined_Addr:
> 0x24: 0x000025e0 DC32 Abort_Handler
> SWI_Addr:
> 0x28: 0x000025e0 DC32 Abort_Handler
> Prefetch_Addr:
> 0x2c: 0x000025e0 DC32 Abort_Handler
> Abort_Addr:
> 0x30: 0x000025e0 DC32 Abort_Handler
> IRQ_Addr:
> 0x34: 0x000025e0 DC32 Abort_Handler
> FIQ_Addr:
> 0x38: 0x000025e0 DC32 Abort_Handler
> 0x3c: 0xffffffff [ARM instr]
> 0x40: 0xffffffff [ARM instr]
>
>
> >
> >
> >
> > > -----Original Message-----
> > > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On
> Behalf
> > > Of bobtransformer
> > > Sent: Saturday, 7 November 2009 1:58 PM
> > > To: l...@yahoogroups.com
> > > Subject: [lpc2000] LPCUSB on LPC23xx not working still....
> > >
> > >
> > > Has there been any new-ish activity with LPCUSB on the LPC23xx parts
> ??
> > >
> > > I am having a heck of a time trying to get the old LPCUSB code to
> work
> > > on my LPC2366 board. Rev D NXP silicon. This worked great on the
> > > LPC2144 chip but I can not for the life of me get this to initialize
> the
> > > hardware without Data abort exceptions on the LPC2366. I can
> sometimes
> > > get past the data aborts if I use the JTAG and stop it here and
> there
> > > and then continue, but will still not connect.
> > >
> > > I know that others have gotten LPCUSB to work on these parts but am
> > > hoping that there is maybe some new knowledge here, not found on our
> > > archives.
> > >
> > > I believe that I have handled the Register addressing changes
> correctly.
> > > The USB peripheral appears to be getting clocks too, AFAIK. Problem
> is
> > > that I cannot exactly catch the data abort with the JTAG in the
> exact
> > > spot that it is happening.
> > >
> > > IRQ's have to be enabled in order for me to get the Data Abort also.
> > >
> > > It looks like the last R14, Link Register (LR) before the abort was
> in
> > > the VCOM_init(); code, but I know it is getting past this point,
> > > somewhat.
> > >
> > > IAR's JTAG debugging windows suggest that I have an interrupt
> pending by
> > > showing USB_INT_REQ_LP and USB_need_clk as high.
> > >
> > > A couple of differences I notice are the USB CLOCK now comes from a
> > > divider on the OUTPUT of the regular PLL, rather than its OWN PLL,
> and
> > > some registers have been re-located, compared to the LPC214X parts.
> > >
> > > Also, WHY is it that IAR had to change their REGISTER defines to
> UPPER
> > > CASE from the combined UPper and Lower case they used to have for
> the
> > > REGISTER definitions used in the LPC23xx user manual ?? That also
> makes
> > > it hard to upgrade to a newer part.
> > >
> > > Any hints are graciously welcome.
> > >
> > > Thanks,
> > > boB
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > >

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(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, "Bruce Paterson" wrote:
> >
> > Ahhhh
> > One thing I neglected to mention; I'm not running it in interrupt mode.
> > Perhaps try running it in polling mode, and if you get that working,
> > move onto ints.
> > The reason I'm not using interrupt mode is a problem to do with
> > integration of the common IRQ between code for the host port and LPCUSB
> > slave code. I could run either in interrupt mode with the other
> > disabled, but both was a disaster. Can't recall the exact issues.
> >
> > Cheers,
> > Bruce
> >
> I know that earlier Revs of sily-con had bugs that required you to poll the Vbus (I think) pin of the LPC23xx. Fortunately we have Rev D parts and supposedly they have very few bugs now.
>
> My original project using LPCUSB was running is IRQ mode and didn't seem to have any problems in that respect.
>
> I may just have to try your polling method though. I am seeing the IRQ handler get called but the VICADDRESS is set to 0x0000000 and it's GOTTA be the USB that is calling this ! But, the IRQ code sees it as a null vector and just exits. I'll figure this out somehow, but what is strange is that in the main() while(1) loop, the CPSR I bit is clear, (IRQ ENABLED), and the Raw interrupt USB bit is set and the USB interrupt is still set but the IRQ interrupt does NOT get called again at that point. Maybe I'm not exiting my IRQ code properly, but it's the same IRQ code I use succesfuly for everything else.

Update on this not re-entering the IRQ when all the right bits are set or cleared for it to do this...

It Does re-enter (and not get to the USB handler) !! ( remember, I have a VICADDRESS of 0x0000 for some reason)...

If I don't set any breakpoints, and just stop and see what it's doing once in a while, it's in the IRQ handler ! That is, until I "single step" through the IRQ handler until it exits. THEN it stops re-entering the IRQ handler loop and just blinks the LEDs in main() !!

What the heck is up with the JTAG and IAR C-Spy ???

boB

>
> Thanks again for letting me blab on about this. You can bet that I will keep you posted ! If nothing else, it helps me think better, sometimes. I'll try to keep it sane though.
>
> boB
> > -----Original Message-----
> > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
> > Of bobtransformer
> > Sent: Monday, 9 November 2009 2:09 PM
> > To: l...@yahoogroups.com
> > Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....
> >
> >
> >
> > --- In l...@yahoogroups.com, "bobtransformer" wrote:
> > >
> > >
> > >
> > > --- In l...@yahoogroups.com, "Bruce Paterson"
> > wrote:
> > > >
> > > > If it's any help to your confidence, I have LPCUSB working fine on
> > an
> > > > lpc2468. I did also upgrade to the latest LPCUSB that includes some
> > > > suggestions from Chinzei to do with bulk mode, but I doubt this is
> > your
> > > > problem (they are improvements rather than go/no-go).
> > > > Yes, you need to deal with the different PINSEL, and different
> > clocking.
> > > > Since the 2468 also has a USB host, you also have to configure and
> > > > program the device/host arrangement and the clocks in new registers.
> > > >
> > > > Cheers,
> > > > Bruce
> > >
> > >
> > > Thank you Bruce ! That is definitely encouraging !
> > >
> > > I am only using the USB device mode and not OTG or Host mode.
> > > This is the mode I was using LPCUSB in on the LPC2144 which is working
> > great.
> > >
> > > Today I am trying to find out why, when I set breakpoints with the
> > JTAG, the code continues on past the global IRQ enable, but if I do not
> > set the breakpoint, and then stop the code, I get stuck in a Data Abort
> > vector loop...
> > >
> > > Then, if I reset the CPSR with the SPSR, it seems to indicate to me
> > that the code at least got past the __interrupt_enable and to the rest
> > of main() before the data abort.
> > >
> > > I am NOT getting a breakpoint hit on at the USB Interrupt entry point
> > but the VICRawIntr USB bit IS set, (USB Interrupt pending), and
> > VICVECTADDR0 is pointing to the proper USB interrupt code location.
> > >
> > > Right after Global IRQ __interrupt_enable(), I have a breakpoint set
> > to USBHwConnect(TRUE); which succesfully break here. Continuing from
> > there, (F5), code continues running to the rest of main() into some LED
> > blink code but no interrupts occur. (interrupts are enabled and USB is
> > pending)
> > >
> > > ....................
> > >
> > > After writing the above notes, but NOT posting this message yet...
> > >
> > > I notice that I am NOT able to set a breakpoint anywhere inside the
> > IRQ HANDLER routine.
> > >
> > > Then, I noticed that IRQ Vector at 0x0018 is pointing to the Data
> > Abort loop, as is most (or all) of the other vector addresses !
> > >
> > > These 2 things are possibly bringing me closer to some resolution, but
> > then WHY are I NOT getting stuck at Data Abort after single-stepping,
> > BUT the VIC registers clearly show that I should be getting an interrupt
> > because the USB RAW INTERRUPT and Enable bits are set, and CPSR I bit is
> > clear ???
> > >
> > > Very strange, I think.
> > >
> > > What is it with the JTAG and why does it interfere so strangely ???
> > >
> > >
> > > Continuing on now...
> > >
> > > Thanks,
> > > boB
> > >
> >
> >
> > In addition, to my previous posting, this is what I am seeing in my
> > C-spy/JTAG debug screen for the interrupt vectors at low memory.
> > Why would I see the message, "USR_MODE:" sitting at 0x10 and 0x14??
> > Notice that everything seems to be pointing to the Abort Handler, except
> > for __iar_program_start
> > My .icf file has the usual line,
> >
> > place at address mem:__ICFEDIT_intvec_start__ { readonly section
> > .intvec };
> >
> >
> > The compiler obviously knows that I cannot set a breakpoint at the IRQ
> > handler. Why might I be having all these Abort Handler references ?
> >
> > Mucho-Thank-You
> >
> > boB
> >
> >
> > LDR PC,Reset_Addr ; Reset
> > __vector:
> > __iar_init$$done:
> > 0x0: 0xe59ff018 LDR pc, Reset_Addr [0x20] ;
> > __iar_program_start
> > LDR PC,Undefined_Addr ; Undefined instructions
> > 0x4: 0xe59ff018 LDR pc, Undefined_Addr [0x24] ;
> > Abort_Handler
> > LDR PC,SWI_Addr ; Software interrupt (SWI/SVC)
> > 0x8: 0xe59ff018 LDR pc, SWI_Addr [0x28] ;
> > Abort_Handler
> > LDR PC,Prefetch_Addr ; Prefetch abort
> > 0xc: 0xe59ff018 LDR pc, Prefetch_Addr [0x2c] ;
> > Abort_Handler
> > LDR PC,Abort_Addr ; Data abort
> > USR_MODE:
> > 0x10: 0xe59ff018 LDR pc, Abort_Addr [0x30] ;
> > Abort_Handler
> > 0x14: 0xb8a06f60 STMLT r0!, {r5, r6, r8-r11, sp, lr}
> > LDR PC,IRQ_Addr ; IRQ
> > 0x18: 0xe59ff014 LDR pc, IRQ_Addr [0x34] ;
> > Abort_Handler
> > LDR PC,FIQ_Addr ; FIQ
> > 0x1c: 0xe59ff014 LDR pc, FIQ_Addr [0x38] ;
> > Abort_Handler
> > Reset_Addr:
> > 0x20: 0x00000200 DC32 __iar_program_start
> > Undefined_Addr:
> > 0x24: 0x000025e0 DC32 Abort_Handler
> > SWI_Addr:
> > 0x28: 0x000025e0 DC32 Abort_Handler
> > Prefetch_Addr:
> > 0x2c: 0x000025e0 DC32 Abort_Handler
> > Abort_Addr:
> > 0x30: 0x000025e0 DC32 Abort_Handler
> > IRQ_Addr:
> > 0x34: 0x000025e0 DC32 Abort_Handler
> > FIQ_Addr:
> > 0x38: 0x000025e0 DC32 Abort_Handler
> > 0x3c: 0xffffffff [ARM instr]
> > 0x40: 0xffffffff [ARM instr]
> >
> >
> >
> >
> >
> >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On
> > Behalf
> > > > Of bobtransformer
> > > > Sent: Saturday, 7 November 2009 1:58 PM
> > > > To: l...@yahoogroups.com
> > > > Subject: [lpc2000] LPCUSB on LPC23xx not working still....
> > > >
> > > >
> > > > Has there been any new-ish activity with LPCUSB on the LPC23xx parts
> > ??
> > > >
> > > > I am having a heck of a time trying to get the old LPCUSB code to
> > work
> > > > on my LPC2366 board. Rev D NXP silicon. This worked great on the
> > > > LPC2144 chip but I can not for the life of me get this to initialize
> > the
> > > > hardware without Data abort exceptions on the LPC2366. I can
> > sometimes
> > > > get past the data aborts if I use the JTAG and stop it here and
> > there
> > > > and then continue, but will still not connect.
> > > >
> > > > I know that others have gotten LPCUSB to work on these parts but am
> > > > hoping that there is maybe some new knowledge here, not found on our
> > > > archives.
> > > >
> > > > I believe that I have handled the Register addressing changes
> > correctly.
> > > > The USB peripheral appears to be getting clocks too, AFAIK. Problem
> > is
> > > > that I cannot exactly catch the data abort with the JTAG in the
> > exact
> > > > spot that it is happening.
> > > >
> > > > IRQ's have to be enabled in order for me to get the Data Abort also.
> > > >
> > > > It looks like the last R14, Link Register (LR) before the abort was
> > in
> > > > the VCOM_init(); code, but I know it is getting past this point,
> > > > somewhat.
> > > >
> > > > IAR's JTAG debugging windows suggest that I have an interrupt
> > pending by
> > > > showing USB_INT_REQ_LP and USB_need_clk as high.
> > > >
> > > > A couple of differences I notice are the USB CLOCK now comes from a
> > > > divider on the OUTPUT of the regular PLL, rather than its OWN PLL,
> > and
> > > > some registers have been re-located, compared to the LPC214X parts.
> > > >
> > > > Also, WHY is it that IAR had to change their REGISTER defines to
> > UPPER
> > > > CASE from the combined UPper and Lower case they used to have for
> > the
> > > > REGISTER definitions used in the LPC23xx user manual ?? That also
> > makes
> > > > it hard to upgrade to a newer part.
> > > >
> > > > Any hints are graciously welcome.
> > > >
> > > > Thanks,
> > > > boB
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------------------
> > > >
> > > >



(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, "Bruce Paterson" wrote:
> > >
> > > Ahhhh
> > > One thing I neglected to mention; I'm not running it in interrupt mode.
> > > Perhaps try running it in polling mode, and if you get that working,
> > > move onto ints.
> > > The reason I'm not using interrupt mode is a problem to do with
> > > integration of the common IRQ between code for the host port and LPCUSB
> > > slave code. I could run either in interrupt mode with the other
> > > disabled, but both was a disaster. Can't recall the exact issues.
> > >
> > > Cheers,
> > > Bruce
> > >
> >
> >
> > I know that earlier Revs of sily-con had bugs that required you to poll the Vbus (I think) pin of the LPC23xx. Fortunately we have Rev D parts and supposedly they have very few bugs now.
> >
> > My original project using LPCUSB was running is IRQ mode and didn't seem to have any problems in that respect.
> >
> > I may just have to try your polling method though. I am seeing the IRQ handler get called but the VICADDRESS is set to 0x0000000 and it's GOTTA be the USB that is calling this ! But, the IRQ code sees it as a null vector and just exits. I'll figure this out somehow, but what is strange is that in the main() while(1) loop, the CPSR I bit is clear, (IRQ ENABLED), and the Raw interrupt USB bit is set and the USB interrupt is still set but the IRQ interrupt does NOT get called again at that point. Maybe I'm not exiting my IRQ code properly, but it's the same IRQ code I use succesfuly for everything else.
>
> Update on this not re-entering the IRQ when all the right bits are set or cleared for it to do this...
>
> It Does re-enter (and not get to the USB handler) !! ( remember, I have a VICADDRESS of 0x0000 for some reason)...
>
> If I don't set any breakpoints, and just stop and see what it's doing once in a while, it's in the IRQ handler ! That is, until I "single step" through the IRQ handler until it exits. THEN it stops re-entering the IRQ handler loop and just blinks the LEDs in main() !!
>
> What the heck is up with the JTAG and IAR C-Spy ???
>
> boB
>
I don't know about the JTAG weirdness BUT I found my VICADRESS problem. My stupid fault of course, not putting the USB Interrupt function address into VICVACADDR22 ! I must be thinking of some old LPC part or never did have it engrained into my head-bits in the first place !

Now it may be as simple as plugging in the USB cable !

boB

>
> >
> > Thanks again for letting me blab on about this. You can bet that I will keep you posted ! If nothing else, it helps me think better, sometimes. I'll try to keep it sane though.
> >
> > boB
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf
> > > Of bobtransformer
> > > Sent: Monday, 9 November 2009 2:09 PM
> > > To: l...@yahoogroups.com
> > > Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....
> > >
> > >
> > >
> > > --- In l...@yahoogroups.com, "bobtransformer" wrote:
> > > >
> > > >
> > > >
> > > > --- In l...@yahoogroups.com, "Bruce Paterson"
> > > wrote:
> > > > >
> > > > > If it's any help to your confidence, I have LPCUSB working fine on
> > > an
> > > > > lpc2468. I did also upgrade to the latest LPCUSB that includes some
> > > > > suggestions from Chinzei to do with bulk mode, but I doubt this is
> > > your
> > > > > problem (they are improvements rather than go/no-go).
> > > > > Yes, you need to deal with the different PINSEL, and different
> > > clocking.
> > > > > Since the 2468 also has a USB host, you also have to configure and
> > > > > program the device/host arrangement and the clocks in new registers.
> > > > >
> > > > > Cheers,
> > > > > Bruce
> > > >
> > > >
> > > > Thank you Bruce ! That is definitely encouraging !
> > > >
> > > > I am only using the USB device mode and not OTG or Host mode.
> > > > This is the mode I was using LPCUSB in on the LPC2144 which is working
> > > great.
> > > >
> > > > Today I am trying to find out why, when I set breakpoints with the
> > > JTAG, the code continues on past the global IRQ enable, but if I do not
> > > set the breakpoint, and then stop the code, I get stuck in a Data Abort
> > > vector loop...
> > > >
> > > > Then, if I reset the CPSR with the SPSR, it seems to indicate to me
> > > that the code at least got past the __interrupt_enable and to the rest
> > > of main() before the data abort.
> > > >
> > > > I am NOT getting a breakpoint hit on at the USB Interrupt entry point
> > > but the VICRawIntr USB bit IS set, (USB Interrupt pending), and
> > > VICVECTADDR0 is pointing to the proper USB interrupt code location.
> > > >
> > > > Right after Global IRQ __interrupt_enable(), I have a breakpoint set
> > > to USBHwConnect(TRUE); which succesfully break here. Continuing from
> > > there, (F5), code continues running to the rest of main() into some LED
> > > blink code but no interrupts occur. (interrupts are enabled and USB is
> > > pending)
> > > >
> > > > ....................
> > > >
> > > > After writing the above notes, but NOT posting this message yet...
> > > >
> > > > I notice that I am NOT able to set a breakpoint anywhere inside the
> > > IRQ HANDLER routine.
> > > >
> > > > Then, I noticed that IRQ Vector at 0x0018 is pointing to the Data
> > > Abort loop, as is most (or all) of the other vector addresses !
> > > >
> > > > These 2 things are possibly bringing me closer to some resolution, but
> > > then WHY are I NOT getting stuck at Data Abort after single-stepping,
> > > BUT the VIC registers clearly show that I should be getting an interrupt
> > > because the USB RAW INTERRUPT and Enable bits are set, and CPSR I bit is
> > > clear ???
> > > >
> > > > Very strange, I think.
> > > >
> > > > What is it with the JTAG and why does it interfere so strangely ???
> > > >
> > > >
> > > > Continuing on now...
> > > >
> > > > Thanks,
> > > > boB
> > > >
> > >
> > >
> > > In addition, to my previous posting, this is what I am seeing in my
> > > C-spy/JTAG debug screen for the interrupt vectors at low memory.
> > > Why would I see the message, "USR_MODE:" sitting at 0x10 and 0x14??
> > > Notice that everything seems to be pointing to the Abort Handler, except
> > > for __iar_program_start
> > > My .icf file has the usual line,
> > >
> > > place at address mem:__ICFEDIT_intvec_start__ { readonly section
> > > .intvec };
> > >
> > >
> > > The compiler obviously knows that I cannot set a breakpoint at the IRQ
> > > handler. Why might I be having all these Abort Handler references ?
> > >
> > > Mucho-Thank-You
> > >
> > > boB
> > >
> > >
> > > LDR PC,Reset_Addr ; Reset
> > > __vector:
> > > __iar_init$$done:
> > > 0x0: 0xe59ff018 LDR pc, Reset_Addr [0x20] ;
> > > __iar_program_start
> > > LDR PC,Undefined_Addr ; Undefined instructions
> > > 0x4: 0xe59ff018 LDR pc, Undefined_Addr [0x24] ;
> > > Abort_Handler
> > > LDR PC,SWI_Addr ; Software interrupt (SWI/SVC)
> > > 0x8: 0xe59ff018 LDR pc, SWI_Addr [0x28] ;
> > > Abort_Handler
> > > LDR PC,Prefetch_Addr ; Prefetch abort
> > > 0xc: 0xe59ff018 LDR pc, Prefetch_Addr [0x2c] ;
> > > Abort_Handler
> > > LDR PC,Abort_Addr ; Data abort
> > > USR_MODE:
> > > 0x10: 0xe59ff018 LDR pc, Abort_Addr [0x30] ;
> > > Abort_Handler
> > > 0x14: 0xb8a06f60 STMLT r0!, {r5, r6, r8-r11, sp, lr}
> > > LDR PC,IRQ_Addr ; IRQ
> > > 0x18: 0xe59ff014 LDR pc, IRQ_Addr [0x34] ;
> > > Abort_Handler
> > > LDR PC,FIQ_Addr ; FIQ
> > > 0x1c: 0xe59ff014 LDR pc, FIQ_Addr [0x38] ;
> > > Abort_Handler
> > > Reset_Addr:
> > > 0x20: 0x00000200 DC32 __iar_program_start
> > > Undefined_Addr:
> > > 0x24: 0x000025e0 DC32 Abort_Handler
> > > SWI_Addr:
> > > 0x28: 0x000025e0 DC32 Abort_Handler
> > > Prefetch_Addr:
> > > 0x2c: 0x000025e0 DC32 Abort_Handler
> > > Abort_Addr:
> > > 0x30: 0x000025e0 DC32 Abort_Handler
> > > IRQ_Addr:
> > > 0x34: 0x000025e0 DC32 Abort_Handler
> > > FIQ_Addr:
> > > 0x38: 0x000025e0 DC32 Abort_Handler
> > > 0x3c: 0xffffffff [ARM instr]
> > > 0x40: 0xffffffff [ARM instr]
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On
> > > Behalf
> > > > > Of bobtransformer
> > > > > Sent: Saturday, 7 November 2009 1:58 PM
> > > > > To: l...@yahoogroups.com
> > > > > Subject: [lpc2000] LPCUSB on LPC23xx not working still....
> > > > >
> > > > >
> > > > > Has there been any new-ish activity with LPCUSB on the LPC23xx parts
> > > ??
> > > > >
> > > > > I am having a heck of a time trying to get the old LPCUSB code to
> > > work
> > > > > on my LPC2366 board. Rev D NXP silicon. This worked great on the
> > > > > LPC2144 chip but I can not for the life of me get this to initialize
> > > the
> > > > > hardware without Data abort exceptions on the LPC2366. I can
> > > sometimes
> > > > > get past the data aborts if I use the JTAG and stop it here and
> > > there
> > > > > and then continue, but will still not connect.
> > > > >
> > > > > I know that others have gotten LPCUSB to work on these parts but am
> > > > > hoping that there is maybe some new knowledge here, not found on our
> > > > > archives.
> > > > >
> > > > > I believe that I have handled the Register addressing changes
> > > correctly.
> > > > > The USB peripheral appears to be getting clocks too, AFAIK. Problem
> > > is
> > > > > that I cannot exactly catch the data abort with the JTAG in the
> > > exact
> > > > > spot that it is happening.
> > > > >
> > > > > IRQ's have to be enabled in order for me to get the Data Abort also.
> > > > >
> > > > > It looks like the last R14, Link Register (LR) before the abort was
> > > in
> > > > > the VCOM_init(); code, but I know it is getting past this point,
> > > > > somewhat.
> > > > >
> > > > > IAR's JTAG debugging windows suggest that I have an interrupt
> > > pending by
> > > > > showing USB_INT_REQ_LP and USB_need_clk as high.
> > > > >
> > > > > A couple of differences I notice are the USB CLOCK now comes from a
> > > > > divider on the OUTPUT of the regular PLL, rather than its OWN PLL,
> > > and
> > > > > some registers have been re-located, compared to the LPC214X parts.
> > > > >
> > > > > Also, WHY is it that IAR had to change their REGISTER defines to
> > > UPPER
> > > > > CASE from the combined UPper and Lower case they used to have for
> > > the
> > > > > REGISTER definitions used in the LPC23xx user manual ?? That also
> > > makes
> > > > > it hard to upgrade to a newer part.
> > > > >
> > > > > Any hints are graciously welcome.
> > > > >
> > > > > Thanks,
> > > > > boB
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------
> > > > >
> > > > >



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

> Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??

As Bertrik write in his LPCUSB page ( http://wiki.sikken.nl/index.php?title=LPCUSB )
"Check out the latest sources from the SVN archive: type 'svn co https://lpcusb.svn.sourceforge.net/svnroot/lpcusb/trunk "

The latest one, Revision 178, supports LPC23xx already.

Tsuneo
--- In l...@yahoogroups.com, "bobtransformer" wrote:
> Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??
>
> I am having a heck of a time trying to get the old LPCUSB code to work on my LPC2366 board. Rev D NXP silicon. This worked great on the LPC2144 chip but I can not for the life of me get this to initialize the hardware without Data abort exceptions on the LPC2366. I can sometimes get past the data aborts if I use the JTAG and stop it here and there and then continue, but will still not connect.
>
> I know that others have gotten LPCUSB to work on these parts but am hoping that there is maybe some new knowledge here, not found on our archives.
>
> I believe that I have handled the Register addressing changes correctly. The USB peripheral appears to be getting clocks too, AFAIK. Problem is that I cannot exactly catch the data abort with the JTAG in the exact spot that it is happening.
>
> IRQ's have to be enabled in order for me to get the Data Abort also.
>
> It looks like the last R14, Link Register (LR) before the abort was in the VCOM_init(); code, but I know it is getting past this point, somewhat.
>
> IAR's JTAG debugging windows suggest that I have an interrupt pending by showing USB_INT_REQ_LP and USB_need_clk as high.
>
> A couple of differences I notice are the USB CLOCK now comes from a divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and some registers have been re-located, compared to the LPC214X parts.
>
> Also, WHY is it that IAR had to change their REGISTER defines to UPPER CASE from the combined UPper and Lower case they used to have for the REGISTER definitions used in the LPC23xx user manual ?? That also makes it hard to upgrade to a newer part.
>
> Any hints are graciously welcome.
>
> Thanks,
> boB
>

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



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

--- In l...@yahoogroups.com, "t_chinzei" wrote:
>
> > Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??
>
> As Bertrik write in his LPCUSB page ( http://wiki.sikken.nl/index.php?title=LPCUSB )
> "Check out the latest sources from the SVN archive: type 'svn co https://lpcusb.svn.sourceforge.net/svnroot/lpcusb/trunk "
>
> The latest one, Revision 178, supports LPC23xx already.
>
> Tsuneo
Thank you Tsuneo !

I did finally get it to run. One of my problems was that I had timer0 interrupt enabled with no code ! That, I think, was causing the randomness of the Data Aborts...

The other problems had mostly to do wit ALSO migrating to the newer, 5.x version of the IAR EWARM compiler/linker. It's a real stinker to upgrade the chip as well as the compiler at the same time. Can get confusing.

I will check out the newer version though..

Thank you !
boB

> --- In l...@yahoogroups.com, "bobtransformer" wrote:
> >
> >
> > Has there been any new-ish activity with LPCUSB on the LPC23xx parts ??
> >
> > I am having a heck of a time trying to get the old LPCUSB code to work on my LPC2366 board. Rev D NXP silicon. This worked great on the LPC2144 chip but I can not for the life of me get this to initialize the hardware without Data abort exceptions on the LPC2366. I can sometimes get past the data aborts if I use the JTAG and stop it here and there and then continue, but will still not connect.
> >
> > I know that others have gotten LPCUSB to work on these parts but am hoping that there is maybe some new knowledge here, not found on our archives.
> >
> > I believe that I have handled the Register addressing changes correctly. The USB peripheral appears to be getting clocks too, AFAIK. Problem is that I cannot exactly catch the data abort with the JTAG in the exact spot that it is happening.
> >
> > IRQ's have to be enabled in order for me to get the Data Abort also.
> >
> > It looks like the last R14, Link Register (LR) before the abort was in the VCOM_init(); code, but I know it is getting past this point, somewhat.
> >
> > IAR's JTAG debugging windows suggest that I have an interrupt pending by showing USB_INT_REQ_LP and USB_need_clk as high.
> >
> > A couple of differences I notice are the USB CLOCK now comes from a divider on the OUTPUT of the regular PLL, rather than its OWN PLL, and some registers have been re-located, compared to the LPC214X parts.
> >
> > Also, WHY is it that IAR had to change their REGISTER defines to UPPER CASE from the combined UPper and Lower case they used to have for the REGISTER definitions used in the LPC23xx user manual ?? That also makes it hard to upgrade to a newer part.
> >
> > Any hints are graciously welcome.
> >
> > Thanks,
> > boB
>

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



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