Lpc2000

I want to connect the LPC2114 (or other LPC2xxx) to 5V solenoid 
drivers (eg. UDN2981's).  Can I pull up the outputs of the LPC to 5V 
with say 10K, to satisfy the input reqmts of the driver?
And secondly, I cant find a list anywhere in the datasheets of the 
LPC pins which are 5V tolerant, I notice some are specified as 3.3V + 
0.6V but I cant figure out which ones, can anyone help please.
Michael.

onceinfour wrote:
> I want to connect the LPC2114 (or other LPC2xxx) to 5V solenoid 
> drivers (eg. UDN2981's).  Can I pull up the outputs of the LPC to 5V 
> with say 10K, to satisfy the input reqmts of the driver?

Hmmm. You might be able to do that with a diode, to prevent it from 
back-feeding current into the internal 3.3v line from the 5v line when 
it's trying to pull the line high.

On the other hand, there is a neat circuit to bidirectionally convert 
between logic levels, I seem to recall... put a MOSFET between the 3.3v 
part and the 5v line (as in, drain to source) and connect the gate of 
the FET to 3.3v, or somesuch. I found the circuit while googling for 
ways of communicating between 3.3v and 5v I2C.

I'm planning on putting 5v pullups on the I2C lines from the LPC - but 
they're pull-down-only, so that's meant to be OK.

> Michael.

ABS

Michael,
  All the IO pins on that device are 5V tolerant EXCEPT any that can 
be configured as an ADC input.  This is lacking in the documentation 
and will be remedied.  In future devices the analog pins will also be 
5V tolerant.

Philips Apps.


--- In lpc2000@yahoogroups.com, "onceinfour" <mmack287@h...> wrote:
> I want to connect the LPC2114 (or other LPC2xxx) to 5V solenoid 
> drivers (eg. UDN2981's).  Can I pull up the outputs of the LPC to 
5V 
> with say 10K, to satisfy the input reqmts of the driver?
> And secondly, I cant find a list anywhere in the datasheets of the 
> LPC pins which are 5V tolerant, I notice some are specified as 3.3V 
+ 
> 0.6V but I cant figure out which ones, can anyone help please.
> Michael.

Please, need an element of practicality here.  We are talking about a 
lot of i/o lines, in our design we are looking at 3 x 8 way solenoid 
drivers, that's 24 signals.  Would make more sense to use a 3.3V to 
5V logic translator(s), but I am trying to save the board space and 
cost.
Michael.


--- In lpc2000@yahoogroups.com, Alaric B Snell <alaric@a...> wrote:
> onceinfour wrote:
> > I want to connect the LPC2114 (or other LPC2xxx) to 5V solenoid 
> > drivers (eg. UDN2981's).  Can I pull up the outputs of the LPC to 
5V 
> > with say 10K, to satisfy the input reqmts of the driver?
> 
> Hmmm. You might be able to do that with a diode, to prevent it from 
> back-feeding current into the internal 3.3v line from the 5v line 
when 
> it's trying to pull the line high.
> 
> On the other hand, there is a neat circuit to bidirectionally 
convert 
> between logic levels, I seem to recall... put a MOSFET between the 
3.3v 
> part and the 5v line (as in, drain to source) and connect the gate 
of 
> the FET to 3.3v, or somesuch. I found the circuit while googling 
for 
> ways of communicating between 3.3v and 5v I2C.
> 
> I'm planning on putting 5v pullups on the I2C lines from the LPC - 
but 

> they're pull-down-only, so that's meant to be OK.
> 
> > Michael.
> 
> ABS

On Fri, 05 Mar 2004 13:22:37 +0000, Alaric B Snell wrote:

onceinfour wrote:
> I want to connect the LPC2114 (or other LPC2xxx) to 5V solenoid 
> drivers (eg. UDN2981's).  Can I pull up the outputs of the LPC to 5V 
> with say 10K, to satisfy the input reqmts of the driver?

Hmmm. You might be able to do that with a diode, to prevent it from 
back-feeding current into the internal 3.3v line from the 5v line when 
it's trying to pull the line high.

On the other hand, there is a neat circuit to bidirectionally convert 
between logic levels, I seem to recall... put a MOSFET between the 3.3v 
part and the 5v line (as in, drain to source) and connect the gate of 
the FET to 3.3v, or somesuch. I found the circuit while googling for 
ways of communicating between 3.3v and 5v I2C.

I'm planning on putting 5v pullups on the I2C lines from the LPC - but 
they're pull-down-only, so that's meant to be OK.

> Michael.

ABS
=====================================================================
IDT <www.idt.com> make a product line called QuickSwitch which uses
this technique.  They are bi-directional and fast.

Regards
-Bill Knight
R O SoftWare

I suppose this is for the Philips Apps. 
OK all pins except a/d are 5V tolerant.  What level (in the high 
state) will I get on a pin configured as an output if I have a pullup 
to 5V, and what current will it draw.  Sorry to harp on, but I need 
to know what voltage level I can generate for my peripheral device, 
and what size of pull-up I can use.
Michael.

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
wrote:
> Michael,
>   All the IO pins on that device are 5V tolerant EXCEPT any that 
can 
> be configured as an ADC input.  This is lacking in the 
documentation 
> and will be remedied.  In future devices the analog pins will also 
be 
> 5V tolerant.
> 
> Philips Apps.
> 
> 
> --- In lpc2000@yahoogroups.com, "onceinfour" <mmack287@h...> wrote:
> > I want to connect the LPC2114 (or other LPC2xxx) to 5V solenoid 
> > drivers (eg. UDN2981's).  Can I pull up the outputs of the LPC to 
> 5V 
> > with say 10K, to satisfy the input reqmts of the driver?
> > And secondly, I cant find a list anywhere in the datasheets of 
the 
> > LPC pins which are 5V tolerant, I notice some are specified as 
3.3V 

> + 
> > 0.6V but I cant figure out which ones, can anyone help please.
> > Michael.

--- In lpc2000@yahoogroups.com, "onceinfour" <mmack287@h...> wrote:
> I suppose this is for the Philips Apps. 
> OK all pins except a/d are 5V tolerant.  What level (in the high 
> state) will I get on a pin configured as an output if I have a pullup 
> to 5V, and what current will it draw.  Sorry to harp on, but I need 
> to know what voltage level I can generate for my peripheral device, 
> and what size of pull-up I can use.

I have two observations for you.  

1) If you use a pullup, your output should be configured as open
collector or open drain (depending on your nomenclature preference). 
This is done by writing a '0' to the output data and controlling the
output drive (on/off or input/output).  

2) The data sheet for the UDN2981 says it is TTL compatible.  That
means the input switching level is between 0.8 and 2.0 volts, so you
don't need a pullup to 5 volts.  

Does that help?

redsp@... wrote:

>I have two observations for you.  
>
>1) If you use a pullup, your output should be configured as open
>collector or open drain (depending on your nomenclature preference). 
>This is done by writing a '0' to the output data and controlling the
>output drive (on/off or input/output).  
>
>2) The data sheet for the UDN2981 says it is TTL compatible.  That
>means the input switching level is between 0.8 and 2.0 volts, so you
>don't need a pullup to 5 volts.  
>  
>
Correct answer redsp ....
Hmmm, funny that onceinfour didn't work out that a low-impedance cmos 
output wouldn't pull-up to +5V with a resistor, unless of course the 
resistor was ridiculously low :)

some further thoughts for onceinfour;
Of course when the pin is not outputing a low it becomes an input which 
are designed to be +5V tolerant. The normal method of making an output 
appear to be open collector is to set the output port low initially and 
then simply set/reset the direction register (as redsp pointed out) to 
make the pin flip from low to high-impedance, thus mimicking an 
open-collector output. Unlike a true open-collector output, the pin 
cannot handle breakdown voltages greater than the chip is designed for 
though.
But why use pull-ups and open-collector drives for this application when 
they are redundant anyway?


Peter Jakacki

I've run into a situation that I've had several times before but never
done anything about.  All of the sudden, code that was working (and
should be working) fine causes a processor data abort exception.
Before, I've always been able to rearrange the code and have the problem
go away but today I decided I should try to get to the bottom of it.  

The C code is a simple save-max-value statement of the form: if (x>y)
y=x;  (x and y are global unsigned longs) Here's the output from
arm-elf-objdump:

        if (USBOutCount>HighUSBOutCount) HighUSBOutCount=USBOutCount;
     378:	e59f3160 	ldr	r3, [pc, #352]	; 4e0
<USBPoll+0x1f8>
     37c:	e59f2168 	ldr	r2, [pc, #360]	; 4ec
<USBPoll+0x204>
     380:	e5931000 	ldr	r1, [r3]
     384:	e5923000 	ldr	r3, [r2]
     388:	e1510003 	cmp	r1, r3

The exception occurs at 384.  The contents around 4ec (end of the
routine, apparently a literal pool) are:

}
     4d4:	e91ba800 	ldmdb	fp, {fp, sp, pc}
     4d8:	000004f0 	streqd	r0, [r0], -r0
     4dc:	000004f4 	streqd	r0, [r0], -r4
     4e0:	00000000 	andeq	r0, r0, r0
     4e4:	000004ec 	andeq	r0, r0, ip, ror #9
     4e8:	000004e8 	andeq	r0, r0, r8, ror #9
     4ec:	0000000c 	andeq	r0, r0, ip

000004f0 <USBInit>:

void USBInit()
{
     4f0:	e1a0c00d 	mov	ip, sp

I'm an arm assembler novice, but it looks like 0000000c is getting
loaded into r2 and being used to access a memory location, but 000000c
isn't a valid memory location.  Alternatively, if I add 360 decimal to
pc (37c) I get 4e4 which holds 4ec which seems to point to a valid
address; OTOH the first variable (0x378+0x160) points to 0x4d8 which in
turn points to 0x4f0 which is code in the following routine USBInit()
(but this operation appears to execute successfully).  Like I said, I'm
not exactly sure how to interpret the assembler but I do know that it is
causing an exception.  Perhaps an assembler guru on the list can tell me
if there is a problem with this code, and more importantly, if it is a
compiler problem, how to escalate the issue to get it fixed.

Development environment is Ashling AsIDE running arm-elf-gcc 3.3.1.
Debug environment is Ashling Pathfinder 1.0.9A.

TIA,

Curt

Hi Curt

If you've been having these problems before but have been able to
make them "go away" by shuffling code around then you have really just
been hiding from the problem instead of fixing it.

Yes, what you see is indeed a literal pool, but perhaps one that has 
not been fixed up properly by linking, or perhaps one that has been 
located badly.

There are many things that contribute to getting things right 
including:
* correct compilation
* correct linking
* correct location 

The actual code itself looks sound. You could also generate the 
assmebler to see if that looks sane too.

You really need to check out a few other things to hunt this down.
The best place to go look is the map file. Check what addresses the 
symbols got located at. If they agree with what you see in the code 
then it means your compiler etc is fine and your ldscript is broken.

Personally, I always use my own hand crafted ld scripts and not the 
general purpose ones. ldscripting is pretty hairy-chested stuff 
though.

--- In lpc2000@yahoogroups.com, "Curt Powell" <curt.powell@s...> 
wrote:
> I've run into a situation that I've had several times before but 
never
> done anything about.  All of the sudden, code that was working (and
> should be working) fine causes a processor data abort exception.
> Before, I've always been able to rearrange the code and have the 
problem
> go away but today I decided I should try to get to the bottom of 
it.
:
<snip>
:
> I'm an arm assembler novice, but it looks like 0000000c is getting
> loaded into r2 and being used to access a memory location, but 
000000c
> isn't a valid memory location.  Alternatively, if I add 360 
decimal to
> pc (37c) I get 4e4 which holds 4ec which seems to point to a valid
> address; OTOH the first variable (0x378+0x160) points to 0x4d8 
which in
> turn points to 0x4f0 which is code in the following routine USBInit
()
> (but this operation appears to execute successfully).  Like I 
said, I'm
> not exactly sure how to interpret the assembler but I do know that 
it is
> causing an exception.

Hi Curt,

I can't tell what's going wrong here. it is screaming 'compiler bug' 
at me - or perhaps linker script error (hmmm... that may be more 
likely?).

One thing I wanted to mention that may help when you're tracking the 
problem down, is that you should remember that because the ARM is a 
pipelined architecture, the program counter is actually pointing 
*two instructions* beyond the currently executing instruction. In 
ARM state, this will be 8 bytes and in Thumb state 4 bytes beyond 
the currently executing instruction.

Because all flavours of ARM have the first three pipeline stages in 
common (Fetch, Decode, Execute), this rule works with any ARM core.

Wandering off-topic, a nice way to use this is in a call to a 
function with an address loaded from a table or computed at run-time:

 mov lr,pc             ; set up return address
 ldr pc,[r4,r5,lsl #2] ; branch to function

In this example, r4 holds the base address of an array of pointers 
to functions, r5 holds the index into the array and is multiplied by 
4 to give the offset from the base of the array to the entry 
containing the required function pointer. Pipelining works to our 
advantage, placing the address of the instruction *after* the ldr pc 
into the link register, which is the correct return address when 
returning from the function.

Good luck with tracking the problem down.

Peter.

Peter,

Thanks for the insights.  If I remove the 'offending' statement, the
problem goes away.  Does that still sound like a possible linker script
error to you?

Curt

-----Original Message-----
From: Peter [mailto:pmaloy@...] 
Sent: Sunday, March 07, 2004 11:09 AM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: Possible gcc bug?


--- In lpc2000@yahoogroups.com, "Curt Powell" <curt.powell@s...> 
wrote:
> I've run into a situation that I've had several times before but
never
> done anything about.  All of the sudden, code that was working (and 
> should be working) fine causes a processor data abort exception. 
> Before, I've always been able to rearrange the code and have the
problem
> go away but today I decided I should try to get to the bottom of
it.
:
<snip>
:
> I'm an arm assembler novice, but it looks like 0000000c is getting 
> loaded into r2 and being used to access a memory location, but
000000c
> isn't a valid memory location.  Alternatively, if I add 360
decimal to
> pc (37c) I get 4e4 which holds 4ec which seems to point to a valid 
> address; OTOH the first variable (0x378+0x160) points to 0x4d8
which in
> turn points to 0x4f0 which is code in the following routine USBInit
()
> (but this operation appears to execute successfully).  Like I
said, I'm
> not exactly sure how to interpret the assembler but I do know that
it is
> causing an exception.

Hi Curt,

I can't tell what's going wrong here. it is screaming 'compiler bug' 
at me - or perhaps linker script error (hmmm... that may be more 
likely?).

One thing I wanted to mention that may help when you're tracking the 
problem down, is that you should remember that because the ARM is a 
pipelined architecture, the program counter is actually pointing 
*two instructions* beyond the currently executing instruction. In 
ARM state, this will be 8 bytes and in Thumb state 4 bytes beyond 
the currently executing instruction.

Because all flavours of ARM have the first three pipeline stages in 
common (Fetch, Decode, Execute), this rule works with any ARM core.

Wandering off-topic, a nice way to use this is in a call to a 
function with an address loaded from a table or computed at run-time:

 mov lr,pc             ; set up return address
 ldr pc,[r4,r5,lsl #2] ; branch to function

In this example, r4 holds the base address of an array of pointers 
to functions, r5 holds the index into the array and is multiplied by 
4 to give the offset from the base of the array to the entry 
containing the required function pointer. Pipelining works to our 
advantage, placing the address of the instruction *after* the ldr pc 
into the link register, which is the correct return address when 
returning from the function.

Good luck with tracking the problem down.

Peter.





 
Yahoo! Groups Links

--- In lpc2000@yahoogroups.com, "Curt Powell" <curt.powell@s...> 
wrote:
> Peter,
> 
> Thanks for the insights.  If I remove the 'offending' statement, the
> problem goes away.  Does that still sound like a possible linker 
script
> error to you?

This still seems more like a linker/locater problem with ld.

Look at the ld map file. See if the symbols are in the correct place.

-- Charles

Followup:  Turned out to be a linker script problem.  If anyone wants
the gory details please contact me off-list.  

Once again this list turns out to be a godsend.

-----Original Message-----
From: embeddedjanitor [mailto:charles.manning@...] 
Sent: Sunday, March 07, 2004 3:40 PM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: Possible gcc bug?


--- In lpc2000@yahoogroups.com, "Curt Powell" <curt.powell@s...> 
wrote:
> Peter,
> 
> Thanks for the insights.  If I remove the 'offending' statement, the 
> problem goes away.  Does that still sound like a possible linker
script
> error to you?

This still seems more like a linker/locater problem with ld.

Look at the ld map file. See if the symbols are in the correct place.

-- Charles




 
Yahoo! Groups Links