VSCP (http://www.vscp.org) has been working in this direction
http://www.vscp.org/wiki/doku.php/vscp/spec/phy/vscp_over_ethernet   But
AFAI know ther has not been any real testsystems yet. It should work though.

Cheers
/Ake

On Tue, Nov 3, 2009 at 5:39 PM, chetan_r_prabhu <chetan_r_prabhu@...
> wrote:

>
>
> Hi there,
> Iam a novice wrt ethernet and iam starting to learn the same by using
> LPC2378 based Keil MCB2300 board, to control a device(just On/Off
> functionality).
> Please could you tell me if i could achieve this by implementing a ethernet
> driver and an application on top of it or is it that i would need a TCPip
> stack.
> Also, if TCPip stack isn't needed then, when and for what type of situation
> one would need to include it.
>
> regards,
> CRP
>
>
>



--
---
Ake Hedman
eurosource, http://www.eurosource.se


[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, "raju_nem" <rajun.dsp@...> wrote:
>
>
> HI rstofer
>
>
> Thank u for u r information.i copied IRQ WRAPPER in to startup file and  below
statements also.
>
>
>
>

> void IRQ_Routine (void)   __attribute__ ((interrupt("IRQ")));

^^^^^ DELETE THIS PROTOTYPE AND THE RELATED FUNCTION ^^^^^

> > void FIQ_Routine (void)   __attribute__ ((interrupt("FIQ")));
> > void SWI_Routine (void)   __attribute__ ((interrupt("SWI")));
> > void UNDEF_Routine (void) __attribute__ ((interrupt("UNDEF")));
>
>

^^^^^ KEEP THESE PROTOTYPES AND RELATED FUNCTIONS ^^^^^


Look again at how the vectors need to be changed:


_vectors:       ldr     PC, Reset_Addr
                 ldr     PC, Undef_Addr
                 ldr     PC, SWI_Addr
                 ldr     PC, PAbt_Addr
                 ldr     PC, DAbt_Addr
                 nop 						 ldr PC, IRQ_Addr <--- LOOK AT THIS!
                 ldr     PC, FIQ_Addr

Reset_Addr:     .word   Reset_Handler
Undef_Addr:     .word   UNDEF_Routine
SWI_Addr:       .word   SWI_Routine
PAbt_Addr:      .word   UNDEF_Routine
DAbt_Addr:      .word   UNDEF_Routine
IRQ_Addr: .word IRQ_Wrapper <--- LOOK AT THIS!
FIQ_Addr:       .word   FIQ_Routine
                 .word   0

Note that the IRQ vector picks up the address of the IRQ_Wrapper stored in the
word at IRQ_Addr

You already included this:

IRQ_Wrapper:
  stmfd sp!, { lr }
  mrs lr, spsr
  stmfd sp!, { r4-r5, lr }
  ldr r4, =VICVECTADDR
  ldr r5, [r4]
  msr cpsr_c, #MODE_SVC|F_BIT
  stmfd sp!, { r0-r3, r12, lr }
  mov lr, pc
  mov pc, r5
  ldmfd sp!, { r0-r3, r12, lr }
  msr cpsr_c, #MODE_IRQ|I_BIT|F_BIT
  str lr, [r4]
  ldmfd sp!, { r4-r5, lr }
  msr spsr_cxsf, lr
  ldmfd sp!, { lr }
  subs pc, lr, #0x4

Richard

Here's what to expect from these cells with a 20uA load...
 
ML-2020   90 days
ML-1220   55 days
ML-920    18 days
ML-614      8 days
ML-612      5 days
 
The other cells in this family didn't have uA/day graphs in them.
 
BTW:  20uA is extremely high for a RTC in backup mode.  Parts I've dealt with
are routinely 500nA.
 
...kevin
   
--- On Mon, 11/9/09, bobtransformer <bgudgel@...> wrote:


From: bobtransformer <bgudgel@...>
Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
To: lpc2000@yahoogroups.com
Date: Monday, November 9, 2009, 10:59 AM


 





--- In lpc2000@yahoogroups .com, "f_bracalenti_ technika_ it" <f.bracalenti@
...> wrote:
>
>
> The Panasonic ML614R specification say:
> Continuous standard load (mA) = 0.01 ( 10uA )
> RTC current of LPC2XXX is approximately 18uA ! !
>
> Fabrizio
>

OK then.... How about using 2 (two) ML6124R batteries in parallel !
A bit overboard, but could work.

boB

> --- In lpc2000@yahoogroups .com, Kevin Braun <kbraun@> wrote:
> >
> > Oops!!!
> > I shot my mouth too soon.  You do need an isolation diode to the 3.3V
rail.  Use a low leakage schottky like the SD101.
> >  
> > ...kevin
> >
> > --- On Sat, 11/7/09, Kevin Braun <kbraun@> wrote:
> >
> >
> > From: Kevin Braun <kbraun@>
> > Subject: Re: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > To: lpc2000@yahoogroups .com
> > Date: Saturday, November 7, 2009, 11:34 AM
> >
> >
> >
> >
> >
> >
> >
> > Bob,
> > You charge them with 3.3V.  If you use 5V, you'll need a 3.3V Zener or
Regulator.  Remember, you're charging them with 10's of microamps of
current.  As the cell gets close to full, it consumes less current until it
reaches the 3.3V rail.
> >  
> > In most circuits, you'd susbstiute the isolation diode with a resistor. 
That's it. The size of the resistor depends on the cell you choose and it's
maximum allowable charging current.  Just follow the directions :-) 
> >  
> > If you are doing a production circuit and have to deal with UL/CSA or TUV,
then use two resistors of equal value.  That satisfies UL's requirement
should one resistor short out.
> >  
> > ...kevin
> >
> > --- On Sat, 11/7/09, bobtransformer <bgudgel@> wrote:
> >
> >
> > From: bobtransformer <bgudgel@>
> > Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > To: lpc2000@yahoogroups .com
> > Date: Saturday, November 7, 2009, 10:50 AM
> >
> >
> >  
> >
> >
> >
> >
> >
> > --- In lpc2000@yahoogroups .com, Kevin Braun <kbraun@> wrote:
> > >
> > > I'm surprised no one has considered using rechargeable lithium coin
cells.  I've been using the Panasonic ML series (DigiKey) in products
for years in RTC applications.  They keep at full charge while power is
applied.  A dead battery (2.5V) usually takes about 24 hours to
fully recharge.  From 3.3V, all you need is a current limiting charge
resistor, replacing the usual isolation diode in the circuit.
> > >  !
> > > ...kevin
> >
> > Now, that may just be the best idea I've heard yet !
> > Would take a slightly more complicated circuit, but probably
> > not to bad. You may have to charge it off your 5 volt line
> > somehow though. Maybe not ?
> >
> > boB
> >
> > >
> > > --- On Sat, 11/7/09, kevin_townsend2 <kevin@> wrote:
> > >
> > >
> > > From: kevin_townsend2 <kevin@>
> > > Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > > To: lpc2000@yahoogroups .com
> > > Date: Saturday, November 7, 2009, 7:35 AM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Bob/Leo:
> > >
> > > Thanks for the input. I was planning on doing the same when power is
available to preserve the batteries. If I can get a year out of them, though,
that should be reasonable.
> > >
> > > Kevin.
> > >
> > > --- In lpc2000@yahoogroups .com, "bobtransformer" <bgudgel@ > wrote:
> > > >
> > > >
> > > >
> > > > --- In lpc2000@yahoogroups .com, "Leo" <leomecma@> wrote:
> > > > >
> > > > > One year if the battery is sourcing all time. 200mA (CR2032) and 20uA
internal RTC.
> > > > >
> > > > > leomecma
> > > > >
> > > >
> > > >
> > > >
> > > > I measure the operating current into a LPC2366 part as 18 microAmps.
(0.0000178 A) (0.178V/10K) The CR2032 battery is 230 mA-hour capacity so that
should work out to be (theoretically) about 12,900 hours... Or, 1 and 1/2 years
! (17 months)
> > > >
> > > > I haven't seen mine last for more than a few months on an LPC2103, but I
never did measure the current draw on that part.
> > > >
> > > > We will be shipping products with some kind of insulator between the
battery and holder just to make sure. I also use diodes to power the micro when
power is available so I don't drain the coin cell.
> > > >
> > > > boB
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: kevin_townsend2
> > > > > To: lpc2000@yahoogroups .com
> > > > > Sent: Friday, November 06, 2009 9:56 PM
> > > > > Subject: [lpc2000] Life Expectancy of CR2032 Battery w/RTC
> > > > >
> > > > >
> > > > >
> > > > > I was wondering if anyone here has any concrete experience with how
long you can expect a (decent quality) CR2032 to work connected to RTXC/VBAT on
something like a 2148? I was using RTC to wake the device up regularly, send
some data, and then drop back into low power mode, but I don't really know how
long I should expect the battery to survive ... obviously one day or another the
device just isn't going to 'wake up' anymore. I would assume something like 1-2
years should be OK?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>








[Non-text portions of this message have been removed]

Having an issue with my descriptor.  In the VirtualCom demo package,
sizeof(USB_CONFIGURATION_DESC) = 9.  When I run my code, the size is 10,
which is causing a enumeration failure.  Same structure in both sets of
code.  Is there a setting that pads or doesn't pad structures on byte
boundaries?  I know it's something like this, because if I either have 3
or 4 bytes in my structure, the sizeof is 4.  In the VirtualCom, 3 bytes
is size 3.
--
Sutton

HI rstofer


Thank u for u r information.i copied IRQ WRAPPER in to startup file and  below
statements also.




void IRQ_Routine (void)   __attribute__ ((interrupt("IRQ")));
> void FIQ_Routine (void)   __attribute__ ((interrupt("FIQ")));
> void SWI_Routine (void)   __attribute__ ((interrupt("SWI")));
> void UNDEF_Routine (void) __attribute__ ((interrupt("UNDEF")));



Same thing is happening.i.e initially in the main while loop,whatever is there
for printing,it is printing.Once interrupt occures,it is going to isr
function,and this isr function is excuting infinetly,i.e it is not coming to
main while loop at all.


What am doing is, for every sec rtc get interrupted and it going to isr,it is
printing the correspond time for every sec in isr.but i when
i copied that IRQ WAPPER function in to start up file,the isr is excuting
infinetly,it is printing same time mutliple times instead printing every sec.For
example

RTC time is 11:01:1

RTC time is 11:01:1

RTC time is 11:01:1

RTC time is 11:01:1

RTC time is 11:01:1

RTC time is 11:01:2

RTC time is 11:01:2

RTC time is 11:01:2

RTC time is 11:01:2


RTC time is 11:01:2

.etc



u told that donot put printf calls inside the isr functions.just for testing
purpose i am using the printf in rtc isr function.


what may be solution for above problem?Not coming to main function where it is
interrupted,is this compiler problem? help me,thanks inadvance.

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@...> wrote:
>
>
>
> --- In lpc2000@yahoogroups.com, "raju_nem" <rajun.dsp@> wrote:
> >
> >
> > Hi,rtstofer
> >
> > void IRQ_Routine (void) {
> >  while (1) ;
> > }
> >
> > void FIQ_Routine (void)  {
> >  while (1) ;
> > }
> >
> > void SWI_Routine (void)  {
> >  while (1) ;
> > }
> >
> >
> > void UNDEF_Routine (void) {
> >  while (1) ;
> > }
> >
> >
> > in the above routines while(1) is there,is this creating problem?
> > --- In lpc2000@yahoogroups.com, "raju_nem" <rajun.dsp@> wrote:
>
>
> When the RTC interrupts, the VIC provides the address of the handler.  That's
why you modified the startup vectors.  So, unless something else is going on
(another interrupt), none of those interrupt routines are ever executed.
>
> OTOH, none of those interrupt routines are valid without the proper prototype
and I didn't provide those.  I stuck the functions in this code just to get it
to compile.  The code, as given, never uses interrupts.  IOW, these functions
are both invalid and not used.
>
> The prototypes would look like:
>
> void IRQ_Routine (void)   __attribute__ ((interrupt("IRQ")));
> void FIQ_Routine (void)   __attribute__ ((interrupt("FIQ")));
> void SWI_Routine (void)   __attribute__ ((interrupt("SWI")));
> void UNDEF_Routine (void) __attribute__ ((interrupt("UNDEF")));
>
> You can add these prototypes to the top of your file if you wish but it won't
change anything.  Since the functions never return and GCC doesn't handle nested
interrupts, once one of these functions gets called, the chip will just loop
forever.
>
> The prototype for your RTC interrupt handler should look like:
>
> void  readRTC_irq (void) __attribute__ (( interrupt ));
>
> I don't think people have been successful putting printf() calls inside of
interrupt functions.  At least it isn't really recommended.
>
> There is another problem.  GCC interrupt functions don't always work for every
incantation of the compiler.  Even then, they don't allow for nested interrupts
(interrupts are disabled throughout the handler).  So, whenever an interrupt
function appears to fail, assume the problem is with GCC (or a particular
version).
>
> The solution is to get rid of the __attribute__ stuff entirely.  This also
makes the code somewhat more portable in that there are no GCC specific
attributes.
>
> In the Files folder there is a file ARM2106Timer.zip  In the startup file,
there is some code (IRQWrapper) that provides the proper entry and exit code for
interrupt routines.  It also allows priority nesting.  Note that the IRQ vector
is changed to branch indirectly to the IRQ wrapper.
>
> Look at the prototype for void T0_ISR in interrupt.h:
>
> void T0_ISR(void);
>
> It doesn't get much cleaner than that!
>
> Now that you have the interrupt working, it is time to clean up the code. 
Consider changing the startup code to include the wrapper and somehow moving the
printf() calls outside the interrupt handler.
>
> Richard
>

--- In lpc2000@yahoogroups.com, "f_bracalenti_technika_it" <f.bracalenti@...>
wrote:
>
>
>  The Panasonic ML614R specification say:
>  Continuous standard load (mA) = 0.01  ( 10uA )
>  RTC current of LPC2XXX is approximately 18uA ! !
>
>  Fabrizio
>

OK then....  How about using 2 (two) ML6124R batteries in parallel !
A bit overboard, but could work.

boB



> --- In lpc2000@yahoogroups.com, Kevin Braun <kbraun@> wrote:
> >
> > Oops!!!
> > I shot my mouth too soon.  You do need an isolation diode to the 3.3V
rail.  Use a low leakage schottky like the SD101.
> >  
> > ...kevin
> >
> > --- On Sat, 11/7/09, Kevin Braun <kbraun@> wrote:
> >
> >
> > From: Kevin Braun <kbraun@>
> > Subject: Re: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > To: lpc2000@yahoogroups.com
> > Date: Saturday, November 7, 2009, 11:34 AM
> >
> >
> >
> >
> >
> >
> >
> > Bob,
> > You charge them with 3.3V.  If you use 5V, you'll need a 3.3V Zener or
Regulator.  Remember, you're charging them with 10's of microamps of current. 
As the cell gets close to full, it consumes less current until it reaches the
3.3V rail.
> >  
> > In most circuits, you'd susbstiute the isolation diode with a resistor. 
That's it. The size of the resistor depends on the cell you choose and it's
maximum allowable charging current.  Just follow the directions :-) 
> >  
> > If you are doing a production circuit and have to deal with UL/CSA or TUV,
then use two resistors of equal value.  That satisfies UL's requirement should
one resistor short out.
> >  
> > ...kevin
> >
> > --- On Sat, 11/7/09, bobtransformer <bgudgel@> wrote:
> >
> >
> > From: bobtransformer <bgudgel@>
> > Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > To: lpc2000@yahoogroups.com
> > Date: Saturday, November 7, 2009, 10:50 AM
> >
> >
> >  
> >
> >
> >
> >
> >
> > --- In lpc2000@yahoogroups .com, Kevin Braun <kbraun@> wrote:
> > >
> > > I'm surprised no one has considered using rechargeable lithium coin
cells.  I've been using the Panasonic ML series (DigiKey) in products for
years in RTC applications.  They keep at full charge while power is
applied.  A dead battery (2.5V) usually takes about 24 hours to fully
recharge.  From 3.3V, all you need is a current limiting charge resistor,
replacing the usual isolation diode in the circuit.
> > >  !
> > > ...kevin
> >
> > Now, that may just be the best idea I've heard yet !
> > Would take a slightly more complicated circuit, but probably
> > not to bad. You may have to charge it off your 5 volt line
> > somehow though. Maybe not ?
> >
> > boB
> >
> > >
> > > --- On Sat, 11/7/09, kevin_townsend2 <kevin@> wrote:
> > >
> > >
> > > From: kevin_townsend2 <kevin@>
> > > Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > > To: lpc2000@yahoogroups .com
> > > Date: Saturday, November 7, 2009, 7:35 AM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Bob/Leo:
> > >
> > > Thanks for the input. I was planning on doing the same when power is
available to preserve the batteries. If I can get a year out of them, though,
that should be reasonable.
> > >
> > > Kevin.
> > >
> > > --- In lpc2000@yahoogroups .com, "bobtransformer" <bgudgel@ > wrote:
> > > >
> > > >
> > > >
> > > > --- In lpc2000@yahoogroups .com, "Leo" <leomecma@> wrote:
> > > > >
> > > > > One year if the battery is sourcing all time. 200mA (CR2032) and 20uA
internal RTC.
> > > > >
> > > > > leomecma
> > > > >
> > > >
> > > >
> > > >
> > > > I measure the operating current into a LPC2366 part as 18 microAmps.
(0.0000178 A) (0.178V/10K) The CR2032 battery is 230 mA-hour capacity so that
should work out to be (theoretically) about 12,900 hours... Or, 1 and 1/2 years
! (17 months)
> > > >
> > > > I haven't seen mine last for more than a few months on an LPC2103, but I
never did measure the current draw on that part.
> > > >
> > > > We will be shipping products with some kind of insulator between the
battery and holder just to make sure. I also use diodes to power the micro when
power is available so I don't drain the coin cell.
> > > >
> > > > boB
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: kevin_townsend2
> > > > > To: lpc2000@yahoogroups .com
> > > > > Sent: Friday, November 06, 2009 9:56 PM
> > > > > Subject: [lpc2000] Life Expectancy of CR2032 Battery w/RTC
> > > > >
> > > > >
> > > > >
> > > > > I was wondering if anyone here has any concrete experience with how
long you can expect a (decent quality) CR2032 to work connected to RTXC/VBAT on
something like a 2148? I was using RTC to wake the device up regularly, send
some data, and then drop back into low power mode, but I don't really know how
long I should expect the battery to survive ... obviously one day or another the
device just isn't going to 'wake up' anymore. I would assume something like 1-2
years should be OK?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@...> wrote:

> You can find the compiler program names about half way down the Makefile:
>
> CC = arm-elf-gcc
> CPP = arm-elf-g++
> OBJCOPY = arm-elf-objcopy
> OBJDUMP = arm-elf-objdump
> SIZE = arm-elf-size
> NM = arm-elf-nm
>
> Richard
>

That would be the distribution Makefile in the Main subdirectory.

Richard

--- In lpc2000@yahoogroups.com, "suresh" <suribobby86@...> wrote:
>
> Hi,
>
>
>             I  want to interface fim3030 fingerprint module to lpc2148.I
> want to send commands   to  fp module.I have done with sitches.
> Plz any one can help me
>
>
>
> Thanks & regards,
> suresh
>

Should be pretty easy!  Sparkfun has the datasheet and a document re: the serial
protocol.  http://www.sparkfun.com/commerce/product_info.php?products_id=8839

There are plenty of examples in the Files folder for LPC2148 code.

Richard

----- Original Message -----
From: "k5nwa" <k5nwa@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, November 09, 2009 4:03 AM
Subject: Re: [lpc2000]


> At 09:13 PM 11/8/2009, you wrote:
>>----- Original Message -----
>>From: "k5nwa" <k5nwa@...>
>>To: <lpc2000@yahoogroups.com>
>>Sent: Monday, November 09, 2009 12:03 AM
>>Subject: [lpc2000]
>>
>>
>> > Anyone have a board package for CrossWorks for the Olimex STM32
>> > boards that they are willing to share?
>> >
>> > I'm extremely green with ARM and having to create one when one is not
>> > familiar with the CPU will most likely be an extremely frustrating
>> > experience.
>>
>>You don't need a package, just create a generic LPC2000 project. I didn;t
>>have any problems doing that for the EA LPC2148 Quickstart module and
>>prototypin g board.
>>
>>Leon
>
> It's not a LPC processor, probably not very close since it's a Cortex 3
> cpu.

You still don't need a package, though.

Leon

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@...> wrote:

> In message 45846 I pointed out how to import and build Logomatic in Eclipse. 
I posted a ZIP file with the entire project.  I hope you downloaded it at the
time.  I have since deleted it.  I don't leave stuff in the Files folder very
long.  Two, maybe three days tops.
>
> Basically, when you import Logomatic, at the top level all you have are 3
directories: lib, LPCUSB and main.  You have no code and no makefile at the top
level.  In the 'main' subdirectory there is a makefile that will build the
entire project including all the code in the other directories.  This project
structure probably doesn't work all that well for Eclipse.



Well, duh,  I forgot that I moved a copy of the workspace directory to this
computer.  It's a Win7 box so I can't build the projects but I do have a backup
copy.

So, I have posted Logomatic to the Files folder.  Get it while it's hot!

I also had to export a PATH for the Makefile in the 'Main' subdirectory to use. 
But I was using the same toolchain so I didn't make any changes to the
distribution.

Again, import this to Eclipse such that the 3 subdirs and the Makefile are all
that shows up at the top level of the project.

You can find the compiler program names about half way down the Makefile:

CC = arm-elf-gcc
CPP = arm-elf-g++
OBJCOPY = arm-elf-objcopy
OBJDUMP = arm-elf-objdump
SIZE = arm-elf-size
NM = arm-elf-nm

Richard

I saw that Digikey also won't ship those batteries outside the US (probably
because of some new airmail restrictions in Lithium).  They looked interesting,
but it seems fate (or maybe just some EU technocrats) are pushing me towards
standard CR2032 cells.

Kevin.

--- In lpc2000@yahoogroups.com, "f_bracalenti_technika_it" <f.bracalenti@...>
wrote:
>
>
>  The Panasonic ML614R specification say:
>  Continuous standard load (mA) = 0.01  ( 10uA )
>  RTC current of LPC2XXX is approximately 18uA ! !
>
>  Fabrizio
>
> --- In lpc2000@yahoogroups.com, Kevin Braun <kbraun@> wrote:
> >
> > Oops!!!
> > I shot my mouth too soon.  You do need an isolation diode to the 3.3V
rail.  Use a low leakage schottky like the SD101.
> >  
> > ...kevin
> >
> > --- On Sat, 11/7/09, Kevin Braun <kbraun@> wrote:
> >
> >
> > From: Kevin Braun <kbraun@>
> > Subject: Re: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > To: lpc2000@yahoogroups.com
> > Date: Saturday, November 7, 2009, 11:34 AM
> >
> >
> >
> >
> >
> >
> >
> > Bob,
> > You charge them with 3.3V.  If you use 5V, you'll need a 3.3V Zener or
Regulator.  Remember, you're charging them with 10's of microamps of current. 
As the cell gets close to full, it consumes less current until it reaches the
3.3V rail.
> >  
> > In most circuits, you'd susbstiute the isolation diode with a resistor. 
That's it. The size of the resistor depends on the cell you choose and it's
maximum allowable charging current.  Just follow the directions :-) 
> >  
> > If you are doing a production circuit and have to deal with UL/CSA or TUV,
then use two resistors of equal value.  That satisfies UL's requirement should
one resistor short out.
> >  
> > ...kevin
> >
> > --- On Sat, 11/7/09, bobtransformer <bgudgel@> wrote:
> >
> >
> > From: bobtransformer <bgudgel@>
> > Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > To: lpc2000@yahoogroups.com
> > Date: Saturday, November 7, 2009, 10:50 AM
> >
> >
> >  
> >
> >
> >
> >
> >
> > --- In lpc2000@yahoogroups .com, Kevin Braun <kbraun@> wrote:
> > >
> > > I'm surprised no one has considered using rechargeable lithium coin
cells.  I've been using the Panasonic ML series (DigiKey) in products for
years in RTC applications.  They keep at full charge while power is
applied.  A dead battery (2.5V) usually takes about 24 hours to fully
recharge.  From 3.3V, all you need is a current limiting charge resistor,
replacing the usual isolation diode in the circuit.
> > >  !
> > > ...kevin
> >
> > Now, that may just be the best idea I've heard yet !
> > Would take a slightly more complicated circuit, but probably
> > not to bad. You may have to charge it off your 5 volt line
> > somehow though. Maybe not ?
> >
> > boB
> >
> > >
> > > --- On Sat, 11/7/09, kevin_townsend2 <kevin@> wrote:
> > >
> > >
> > > From: kevin_townsend2 <kevin@>
> > > Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > > To: lpc2000@yahoogroups .com
> > > Date: Saturday, November 7, 2009, 7:35 AM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Bob/Leo:
> > >
> > > Thanks for the input. I was planning on doing the same when power is
available to preserve the batteries. If I can get a year out of them, though,
that should be reasonable.
> > >
> > > Kevin.
> > >
> > > --- In lpc2000@yahoogroups .com, "bobtransformer" <bgudgel@ > wrote:
> > > >
> > > >
> > > >
> > > > --- In lpc2000@yahoogroups .com, "Leo" <leomecma@> wrote:
> > > > >
> > > > > One year if the battery is sourcing all time. 200mA (CR2032) and 20uA
internal RTC.
> > > > >
> > > > > leomecma
> > > > >
> > > >
> > > >
> > > >
> > > > I measure the operating current into a LPC2366 part as 18 microAmps.
(0.0000178 A) (0.178V/10K) The CR2032 battery is 230 mA-hour capacity so that
should work out to be (theoretically) about 12,900 hours... Or, 1 and 1/2 years
! (17 months)
> > > >
> > > > I haven't seen mine last for more than a few months on an LPC2103, but I
never did measure the current draw on that part.
> > > >
> > > > We will be shipping products with some kind of insulator between the
battery and holder just to make sure. I also use diodes to power the micro when
power is available so I don't drain the coin cell.
> > > >
> > > > boB
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: kevin_townsend2
> > > > > To: lpc2000@yahoogroups .com
> > > > > Sent: Friday, November 06, 2009 9:56 PM
> > > > > Subject: [lpc2000] Life Expectancy of CR2032 Battery w/RTC
> > > > >
> > > > >
> > > > >
> > > > > I was wondering if anyone here has any concrete experience with how
long you can expect a (decent quality) CR2032 to work connected to RTXC/VBAT on
something like a 2148? I was using RTC to wake the device up regularly, send
some data, and then drop back into low power mode, but I don't really know how
long I should expect the battery to survive ... obviously one day or another the
device just isn't going to 'wake up' anymore. I would assume something like 1-2
years should be OK?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

Suresh,

I doubt you'll get any useful replies because your question is too open.

if I were to ask you to help me 'because I have a problem' - how would you
help me?

You need to be more specific about what you have tried and what did and did
not work.

What are 'sitches'?

Remember, you know all about what you are trying to do and the history of
how you got there.

We only know about what you are doing from what you tell us.



                                                 .Laurie:{)





From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf Of
suresh
Sent: Monday, 9 November 2009 8:33 PM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Finger print module interfacing with lpc2148





Hi,


I want to interface fim3030 fingerprint module to lpc2148.I
want to send commands to fp module.I have done with sitches.
Plz any one can help me



Thanks & regards,
suresh

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

Hi,


             I  want to interface fim3030 fingerprint module to lpc2148.I
want to send commands   to  fp module.I have done with sitches.
Plz any one can help me



Thanks & regards,
suresh

[Non-text portions of this message have been removed]

Hi,

> Anyone have a board package for CrossWorks for the Olimex STM32
> boards that they are willing to share?
>
> I'm extremely green with ARM and having to create one when one is not
> familiar with the CPU will most likely be an extremely frustrating
> experience.

Apart from the LPC2000 forum stuff, you can just use a generic STM32
package; it won't flash LEDs or respond to buttons, that's what a BSP gets
you, but it does get you off the ground with putting things into flash,
getting the processor to main(), and so on.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!

The Panasonic ML614R specification say:
  Continuous standard load (mA) = 0.01  ( 10uA )
  RTC current of LPC2XXX is approximately 18uA ! !

  Fabrizio

--- In lpc2000@yahoogroups.com, Kevin Braun <kbraun@...> wrote:
>
> Oops!!!
> I shot my mouth too soon.  You do need an isolation diode to the 3.3V rail. 
Use a low leakage schottky like the SD101.
>  
> ...kevin
>
> --- On Sat, 11/7/09, Kevin Braun <kbraun@...> wrote:
>
>
> From: Kevin Braun <kbraun@...>
> Subject: Re: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> To: lpc2000@yahoogroups.com
> Date: Saturday, November 7, 2009, 11:34 AM
>
>
>
>
>
>
>
> Bob,
> You charge them with 3.3V.  If you use 5V, you'll need a 3.3V Zener or
Regulator.  Remember, you're charging them with 10's of microamps of current. 
As the cell gets close to full, it consumes less current until it reaches the
3.3V rail.
>  
> In most circuits, you'd susbstiute the isolation diode with a resistor. 
That's it. The size of the resistor depends on the cell you choose and it's
maximum allowable charging current.  Just follow the directions :-) 
>  
> If you are doing a production circuit and have to deal with UL/CSA or TUV,
then use two resistors of equal value.  That satisfies UL's requirement should
one resistor short out.
>  
> ...kevin
>
> --- On Sat, 11/7/09, bobtransformer <bgudgel@...> wrote:
>
>
> From: bobtransformer <bgudgel@...>
> Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> To: lpc2000@yahoogroups.com
> Date: Saturday, November 7, 2009, 10:50 AM
>
>
>  
>
>
>
>
>
> --- In lpc2000@yahoogroups .com, Kevin Braun <kbraun@> wrote:
> >
> > I'm surprised no one has considered using rechargeable lithium coin
cells.  I've been using the Panasonic ML series (DigiKey) in products for
years in RTC applications.  They keep at full charge while power is
applied.  A dead battery (2.5V) usually takes about 24 hours to fully
recharge.  From 3.3V, all you need is a current limiting charge resistor,
replacing the usual isolation diode in the circuit.
> >  !
> > ...kevin
>
> Now, that may just be the best idea I've heard yet !
> Would take a slightly more complicated circuit, but probably
> not to bad. You may have to charge it off your 5 volt line
> somehow though. Maybe not ?
>
> boB
>
> >
> > --- On Sat, 11/7/09, kevin_townsend2 <kevin@> wrote:
> >
> >
> > From: kevin_townsend2 <kevin@>
> > Subject: [lpc2000] Re: Life Expectancy of CR2032 Battery w/RTC
> > To: lpc2000@yahoogroups .com
> > Date: Saturday, November 7, 2009, 7:35 AM
> >
> >
> >  
> >
> >
> >
> > Bob/Leo:
> >
> > Thanks for the input. I was planning on doing the same when power is
available to preserve the batteries. If I can get a year out of them, though,
that should be reasonable.
> >
> > Kevin.
> >
> > --- In lpc2000@yahoogroups .com, "bobtransformer" <bgudgel@ > wrote:
> > >
> > >
> > >
> > > --- In lpc2000@yahoogroups .com, "Leo" <leomecma@> wrote:
> > > >
> > > > One year if the battery is sourcing all time. 200mA (CR2032) and 20uA
internal RTC.
> > > >
> > > > leomecma
> > > >
> > >
> > >
> > >
> > > I measure the operating current into a LPC2366 part as 18 microAmps.
(0.0000178 A) (0.178V/10K) The CR2032 battery is 230 mA-hour capacity so that
should work out to be (theoretically) about 12,900 hours... Or, 1 and 1/2 years
! (17 months)
> > >
> > > I haven't seen mine last for more than a few months on an LPC2103, but I
never did measure the current draw on that part.
> > >
> > > We will be shipping products with some kind of insulator between the
battery and holder just to make sure. I also use diodes to power the micro when
power is available so I don't drain the coin cell.
> > >
> > > boB
> > >
> > >
> > >
> > >
> > > >
> > > > ----- Original Message -----
> > > > From: kevin_townsend2
> > > > To: lpc2000@yahoogroups .com
> > > > Sent: Friday, November 06, 2009 9:56 PM
> > > > Subject: [lpc2000] Life Expectancy of CR2032 Battery w/RTC
> > > >
> > > >
> > > >
> > > > I was wondering if anyone here has any concrete experience with how long
you can expect a (decent quality) CR2032 to work connected to RTXC/VBAT on
something like a 2148? I was using RTC to wake the device up regularly, send
some data, and then drop back into low power mode, but I don't really know how
long I should expect the battery to survive ... obviously one day or another the
device just isn't going to 'wake up' anymore. I would assume something like 1-2
years should be OK?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Go to www.Codesourcery.com and download the latest professional edition
toolchain. They have the boards supported from Keil. You can modify the
scripts for your own board.

Go to St forum and search for codesourcery, there is one project from
lanchon "cs-stm32-1.0.rc2". Download and modify for your board.

Regards,
Ravi


On Mon, Nov 9, 2009 at 12:41 PM, 42Bastian <deep-thought@...> wrote:

>
>
> k5nw
>
>
> > It's not a LPC processor, probably not very close since it's a Cortex 3
> cpu.
>
> Ha, you got it. That's the LPC2000 group :-)
>
> Anyway, go to ST and check for their support libraries, AFAIK they come
> with example projects.
>
> --
> 42Bastian
> ------------------
> Parts of this email are written with invisible ink.
>
> Note: SPAM-only account, direct mail to bs42@...
>
>


[Non-text portions of this message have been removed]

k5nw

> It's not a LPC processor, probably not very close since it's a Cortex 3 cpu.

Ha, you got it. That's the LPC2000 group :-)

Anyway, go to ST and check for their support libraries, AFAIK they come
with example projects.

--
42Bastian
------------------
Parts of this email are written with invisible ink.

Note: SPAM-only account, direct mail to bs42@...

--- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@...> wrote:
>
>
>
> --- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@> wrote:
> >
> >
> >
> > --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> > > Of bobtransformer
> > > Sent: Monday, 9 November 2009 2:09 PM
> > > To: lpc2000@yahoogroups.com
> > > Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....
> > >
> > >
> > >
> > > --- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@> wrote:
> > > >
> > > >
> > > >
> > > > --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On
> > > Behalf
> > > > > Of bobtransformer
> > > > > Sent: Saturday, 7 November 2009 1:58 PM
> > > > > To: lpc2000@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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------
> > > > >
> > > > > Yahoo! Groups Links
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> >
>

--- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@...> wrote:
>
>
>
> --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> > Of bobtransformer
> > Sent: Monday, 9 November 2009 2:09 PM
> > To: lpc2000@yahoogroups.com
> > Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....
> >
> >
> >
> > --- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@> wrote:
> > >
> > >
> > >
> > > --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On
> > Behalf
> > > > Of bobtransformer
> > > > Sent: Saturday, 7 November 2009 1:58 PM
> > > > To: lpc2000@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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------------------
> > > >
> > > > Yahoo! Groups Links
> > > >
> > >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
>

hi there,
I am new in writing embedded systemn program.
I am using Keil C software on this MCB2100.
Can anyone tell me where can i set and input my own data through CAN for
transmit? is it through TPDO mapping parameter? or PDO?

At 09:13 PM 11/8/2009, you wrote:
>----- Original Message -----
>From: "k5nwa" <k5nwa@...>
>To: <lpc2000@yahoogroups.com>
>Sent: Monday, November 09, 2009 12:03 AM
>Subject: [lpc2000]
>
>
> > Anyone have a board package for CrossWorks for the Olimex STM32
> > boards that they are willing to share?
> >
> > I'm extremely green with ARM and having to create one when one is not
> > familiar with the CPU will most likely be an extremely frustrating
> > experience.
>
>You don't need a package, just create a generic LPC2000 project. I didn;t
>have any problems doing that for the EA LPC2148 Quickstart module and
>prototypin g board.
>
>Leon

It's not a LPC processor, probably not very close since it's a Cortex 3 cpu.


Cecil
k5nwa
www.softrockradio.org www.qrpradio.com
<  http://parts.softrockradio.org/  >

Never take life seriously. Nobody gets out alive anyway.

[Non-text portions of this message have been removed]

--- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> Of bobtransformer
> Sent: Monday, 9 November 2009 2:09 PM
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....
>
>
>
> --- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@> wrote:
> >
> >
> >
> > --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On
> Behalf
> > > Of bobtransformer
> > > Sent: Saturday, 7 November 2009 1:58 PM
> > > To: lpc2000@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
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>

--- In lpc2000@yahoogroups.com, Bruce Lindsay <lindsayb37@...> wrote:
>
> Since this is related I'll keep it in the same topic.
>
> I am getting a couple of errors in the Logomatic project. I am using
> Richards make file to build with. The errors are:
>
> make: *** [all] Error 2
>
> make[1]: *** No rule to make target `lpc2148-FLASH.ld', needed by
> `Logomatic.elf'.
>
> Here is my make file.
>
>

Make can't find lpc2148-FLASH.ld in the project directory or the current
directory when make is executing.

When you do 'make', 'all' is the default target and 'all' depends on ${LDSCRIPT}
which is a macro for the name of the linker script lpc2148-FLASH.ld

But the real problem is that you shouldn't be using that makefile at all.  It
only builds main.c and Logomatic is a lot more than that.

In message 45846 I pointed out how to import and build Logomatic in Eclipse.  I
posted a ZIP file with the entire project.  I hope you downloaded it at the
time.  I have since deleted it.  I don't leave stuff in the Files folder very
long.  Two, maybe three days tops.

Basically, when you import Logomatic, at the top level all you have are 3
directories: lib, LPCUSB and main.  You have no code and no makefile at the top
level.  In the 'main' subdirectory there is a makefile that will build the
entire project including all the code in the other directories.  This project
structure probably doesn't work all that well for Eclipse.

So, what I did was create a Makefile at the top level that did nothing except
change into the main subdirectory and recursively call 'make'.

I won't have access to my Linux box for several days so I can't retrieve the
file and I doubt very much that the I can recreate the shell code off the top of
my head.  So, I might try instead:

--------------------
.PHONY all

all:
  cd main
  make -C
--------------------

The target 'all' doesn't have any dependencies and all it does is change
directories and call make.

This results in a top level Makefile to satisfy Eclipse and it keeps the
Logomatic directory structure intact.

It is very likely that you will need to change the Makefile within the 'main'
subdirectory to use your toolchain.  That change was not required on my system. 
Be very sparing in your changes.

The whole reason I imported the code as it was presented was that I didn't want
to make ANY changes to the Logomatic files.  The Makefile, as I recall, was far
above my pay grade.

Richard

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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of bobtransformer
Sent: Monday, 9 November 2009 2:09 PM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: LPCUSB on LPC23xx not working still....



--- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@...> wrote:
>
>
>
> --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On
Behalf
> > Of bobtransformer
> > Sent: Saturday, 7 November 2009 1:58 PM
> > To: lpc2000@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
> >
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
>




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

Yahoo! Groups Links

Since this is related I'll keep it in the same topic.

I am getting a couple of errors in the Logomatic project. I am using
Richards make file to build with. The errors are:

make: *** [all] Error 2

make[1]: *** No rule to make target `lpc2148-FLASH.ld', needed by
`Logomatic.elf'.

Here is my make file.

********************************************************************************\
*******
********************************************************************************\
*******

# $Id: Makefile,v 1.0 2006/04/06 06:55:34 RTS Exp $

DATE     = `date "+%c"`
NAME     = LPC2148_Logomatic_V2
TARGET   = Logomatic
LDSCRIPT = lpc2148-FLASH.ld

LOCATION = /home/bruce/CodeSourcery/Sourcery_G++_Lite/

CC      = ${LOCATION}/bin/arm-none-eabi-gcc
LD      = ${LOCATION}/bin/arm-none-eabi-ld
AR      = ${LOCATION}/bin/arm-none-eabi-ar
AS      = ${LOCATION}/bin/arm-none-eabi-as
CP      = ${LOCATION}/bin/arm-none-eabi-objcopy
OD        = ${LOCATION}/bin/arm-none-eabi-objdump
SZ        = ${LOCATION}/bin/arm-none-eabi-size

ARCHIVE1  = ${LOCATION}/arm-none-eabi/lib
ARCHIVE2  = ${LOCATION}/lib/gcc/arm-none-eabi/4.3.3
ARCHIVE3  = /home/bruce/ARMworkspace/Logomatic/lib
ARCHIVE4  = /home/bruce/ARMworkspace/Logomatic/LPCUSB
LIBRARIES = -L${ARCHIVE1} -lc -lg -L$(ARCHIVE2) -lgcc -L$(ARCHIVE3)
-lgcc -L$(ARCHIVE4) -lgcc

# in -adnhls the 'd' turns off debugging info and the 'n' turns off page
formatting
CFLAGS    = -I./ -c -fno-common -O0 -g -Wa,-adnhls=$*.lst -Wall
AFLAGS    = -ahls -mapcs-32
LDFLAGS   =  -Map ${TARGET}.map -T${LDSCRIPT}
CPFLAGS   = -O ihex
##ODFLAGS   = -x --syms
ODFLAGS   = -h -S -t
#LIBS      = -lc -lgcc

SRCS =    main.c

OBJS =  $(SRCS:.c=.o)

all                :     depend
                     make ${TARGET}.hex sizes list

clean            :
                     @-rm *.o *.lst *.dmp *.hex *.map *.out *.elf *.bin >
/dev/null 2>&1


sizes            :    ${TARGET}.elf
                     ${SZ} ${TARGET}.elf

list            :    ${TARGET}.elf
                     ${OD} ${ODFLAGS} ${TARGET}.elf > ${TARGET}.lss


program            :    ${TARGET}.hex
                     lpc21isp ${TARGET}.hex /dev/ttyS0 38400 12000


${TARGET}.elf     :     ${LDSCRIPT} crt.o ${OBJS}
                     ${LD} ${LDFLAGS} -o ${TARGET}.elf crt.o ${OBJS}
${LIBRARIES}

${TARGET}.hex    :    ${TARGET}.elf
                     ${CP} -R.dma -O ihex ${TARGET}.elf ${TARGET}.hex

${TARGET}.srec    :    ${TARGET}.elf
                     ${CP} -O srec ${TARGET}.elf ${TARGET}.srec

${TARGET}.bin    :    ${TARGET}.elf
                     ${CP} -O binary ${TARGET}.elf ${TARGET}.bin

crt.o            :    crt.s
                     $(AS) $(AFLAGS) -o crt.o crt.s > crt.lst

$(OBJS)            :    %.o: %.c
                     $(CC) -c $(CFLAGS) $< -o $@

depend            :
                     @cp Makefile Makefile.bak
                     @awk '/# .Id/,/^# DO NOT DELETE/' Makefile >
Makefile.new
                     @${CC} ${CFLAGS} -MM ${SRCS} >> Makefile.new
                     @if ! diff Makefile Makefile.new > /dev/null 2>&1 ; then
                         mv Makefile.new Makefile;
                     else
                         rm Makefile.new;
                         rm Makefile.bak;
                     fi

# DO NOT DELETE (Dependencies follow)
main.o: main.c lpc214x.h

***************************************************************************
***************************************************************************

PS - How do you make relative library declarations in the Makefile?

--- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@...> wrote:
>
>
>
> --- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@> wrote:
> >
> >
> >
> > --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> > > Of bobtransformer
> > > Sent: Saturday, 7 November 2009 1:58 PM
> > > To: lpc2000@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
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> >
>

----- Original Message -----
From: "k5nwa" <k5nwa@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, November 09, 2009 12:03 AM
Subject: [lpc2000]


> Anyone have a board package for CrossWorks for the Olimex STM32
> boards that they are willing to share?
>
> I'm extremely green with ARM and having to create one when one is not
> familiar with the CPU will most likely be an extremely frustrating
> experience.

You don't need a package, just create a generic LPC2000 project. I didn;t
have any problems doing that for the EA LPC2148 Quickstart module and
prototypin g board.

Leon

--- In lpc2000@yahoogroups.com, "bobtransformer" <bgudgel@...> wrote:
>
>
>
> --- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> > Of bobtransformer
> > Sent: Saturday, 7 November 2009 1:58 PM
> > To: lpc2000@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
> >
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
>

--- In lpc2000@yahoogroups.com, "Bruce Paterson" <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: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> Of bobtransformer
> Sent: Saturday, 7 November 2009 1:58 PM
> To: lpc2000@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
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>

Anyone have a board package for CrossWorks for the Olimex STM32
boards that they are willing to share?

I'm extremely green with ARM and having to create one when one is not
familiar with the CPU will most likely be an extremely frustrating experience.

Thanks

Cecil
k5nwa
www.softrockradio.org www.qrpradio.com
<  http://parts.softrockradio.org/  >

Never take life seriously. Nobody gets out alive anyway.