Hello all,
I am totally messed up. I am trying to use Port1 (P1.16
to P1.31) of an LPC2148 as GPIO. I am trying for about two weeks now
without success.
I am using the arm-elf-gcc ver. 4.0.2 for windows. I took the
startup assembly code from the "Hello World!" example downloadable
in the files section of this group.
My hardware layout is similar to the olimex LPC-P2148 eval board. In
the meantime I bought one of these boards to cross check that my
hardware is ok. I have got the same problem on both hardware
platforms, so for better understanding I will describe everything I
did based on the olimex board.
I do not need JTAG for debugging but I need the JTAG pins to be GPIO
because I want to use them together with the trace port as an 16 bit
input port.

The point where I got stuck is:
I wrote a simple programm which only sets up the CPU including the
PLL and initialises UART0 for debugging output.
Then I read out PINSEL2 which delivers 0x00000004 when the JTAG
enable jumper is set, which means that P1.26 is pulled low during
reset.
Then I read out FIO1PIN which then delivers 0x03ff0000.
I think this behaviour is correct although I am wondering a little
bit why I can not read out the pull ups connected to the JTAG
connector.

But when I remove the enable JTAG jumper the LPC2148 behaves strange.
After removing the jumper a readout of PINSEL2 delivers 0x00000000.
Then I read the FIO1PIN register. It delivers 0x00000000 although
it has to deliver some ones on the JTAG part of port 1 because of the
pull ups connected to these pins and additionally the ones which I can
read out on the lower bits when JTAG is enabled.

I already checked if this is an FIO problem but it also occurs with
GPIO Pins switched back to legacy mode.

This also happens when I leave the enable JTAG jumper set and write
0 to bit 2 and 3 in the PINSEL2 register with "PINSEL2 &0xfffffff3;" prior to reading FIO1PIN.

I also tried to pull low P0.31 during Reset. This is not documented
in the LPC manual. There is only a note that it has to be high for
enabling JTAG. So I thought that pulling it low disables JTAG and
perhaps is required to get GPIO working on the JTAG Pins. But
this was without success, too.

Another thing that I registered is that in the Kile simulator the
Pinsel2 register holds a 0x00000030 when read just after bootup.
Does anybody know what these two bits represent? In the Philips
manual there is only a hint that users should never write zeros to
bit 5 and 6 because this may causes wrong code execution.
For this setup I used the Kile internal startup assembly code and
header files and compiled it with the kile internal compiler. When I
simulate my peripherals in the Kile simulator everything works like
expected. But when I load the hex file into my controller it does
not.

Have I overlooked something? Is there an additional register which has
to be modified to get complete Port P1 as GPIO? Has anyone already
managed to get this port completely running as GPIO? Is there a
possibility to contact Philips? Perhaps they have got an answer.

I start beeing a little bit frustrated because of lack of ideas what
to do next. :-( I would really apreciate any kind of hint. Thanks in
advance.

Joerg

Start a New Thread

Hello all,
by fluke I found a workaround for my problem.
I played around with the GPIO peripherals in the Kile simulator
simultaneously watching the IOPIN1 content on the serial console.
Suddenly I found a state in which Port1 could be read although PINSEL2
bit 2 and 3 were zero. It depends on the state of P1.31. Either when
it is switched to input and pulled low or when this pin is set to
output and output is set to 0 the port wakes up.
This behaviour seems very strange to me. It is nowhere mentioned in
the LPC2148 users manual and does not make sense at all, because it is
not possible to read a one from this pin ?!?!
It was big luck that I only need the first 14 IO pins of this port but
when someone wants to use the whole Port as IO this could get very
uncomfortable.
I reproduced this with two Boards, one designed by myself and an
Olimex LPC-P2148.
There are three facts I really wonder about:
Has really nobody used this port as IO before?
Is this a feature or a bad hardware design error?
And when its an error why is it implemented in the Kile simulator but
not mentioned in the LPC2148 errata sheet?

Any comments?

Cheers Joerg Start a New Thread

Hi all,
by fluke I found a workaround for my problem.
I played around with the GPIO peripherals in the Kile simulator
while simultaneously watching the IOPIN1 content on the serial console.
Suddenly I found a state in which Port1 could be read although
PINSEL2 bit 2 and 3 were zero. It depends on the state of P1.31.
Either when it is switched to input and pulled low or when this pin is
set to output and output is set to 0 the port wakes up.
This behaviour seems very strange to me. It is nowhere mentioned in
the LPC2148 users manual and does not make sense at all, because it
is not possible to read a one from this pin ?!?!
It was big luck that I only need the first 14 IO pins of this port
but when someone wants to use the whole Port as IO this could get very
uncomfortable.
I reproduced this with two Boards, one designed by myself and an
Olimex LPC-P2148.
There are three facts I really wonder about:
Has really nobody used this port as IO before?
Is this a feature or a bad hardware design error?
And when its an error why is it implemented in the Kile simulator
but not mentioned in the LPC2148 errata sheet?

Any comments?

Cheers Joerg

P.s.: Sorry for perhaps posting this message twice. The first time
it did not appear in the message list.

Start a New Thread

Hello all,
by fluke I found a workaround for my problem.
I played around with the GPIO peripherals in the Kile simulator while
simultaneously watching the IOPIN1 content on the serial console.
Suddenly I found a state in which Port1 could be read although PINSEL2
bit 2 and 3 were zero. It depends on the state of P1.31. Either when
it is switched to input and pulled low or when this pin is set to
output and output is set to 0 the port wakes up.
This behaviour seems very strange to me. It is nowhere mentioned in
the LPC2148 users manual and does not make sense at all, because it is
not possible to read a one from this pin ?!?!
It was big luck that I only need the first 14 IO pins of this port but
when someone wants to use the whole Port as IO this could get very
uncomfortable.
I reproduced this with two Boards, one designed by myself and an
Olimex LPC-P2148.
There are three facts I really wonder about:
Has really nobody used this port as IO before?
Is this a feature or a bad hardware design error?
And when its an error why is it implemented in the Kile simulator but
not mentioned in the LPC2148 errata sheet?

Any comments?

Cheers Joerg

P.s.: Sorry for perhaps posting this message twice. The first time it
did not appear in the message list. Start a New Thread

--- In l..., "joerg.nagel" wrote:
> [relating to P1.31 on LPC-P2148]
>
> There are three facts I really wonder about:
> Has really nobody used this port as IO before?
> Is this a feature or a bad hardware design error?
> And when its an error why is it implemented in the Kile simulator but
> not mentioned in the LPC2148 errata sheet?
>
> Any comments?

I have no comment specifically on P1.31 but I know there are certain
GPIO pins and registers in LPC whose functionality Philips would not
like to disclose.

I gather such information is available on a need to know basis and
subject to NDAs. This may apply to KEIL because they promote LPC.

The most compelling reason I think for taking on such an approach to
information hiding would be that disclosure adversely affects Philips
marketing efforts.

As an example, if they made the MAM statistics registers public, then
anyone would be able to *measure* the efficacy of MAM without relying
on (ambit) claims in sales brochures.

Jaya

Start a New Thread

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "joerg.nagel" wrote:
> > [relating to P1.31 on LPC-P2148]
> >
> > There are three facts I really wonder about:
> > Has really nobody used this port as IO before?
> > Is this a feature or a bad hardware design error?
> > And when its an error why is it implemented in the Kile simulator but
> > not mentioned in the LPC2148 errata sheet?
> >
> > Any comments?
>
> I have no comment specifically on P1.31 but I know there are certain
> GPIO pins and registers in LPC whose functionality Philips would not
> like to disclose.

..and they keep the documents in Area 51 with Greys?
:-)
Your usage of connector "but" is an examplary: it negates whatever was
preceeding it. :-Q

>
> I gather such information is available on a need to know basis and
> subject to NDAs. This may apply to KEIL because they promote LPC.

Uh-oh. A new conspiracy? KEIL is "An ARM company", surely you can
backup your statement with more specific facts. Oder..?

> The most compelling reason I think for taking on such an approach to
> information hiding would be that disclosure adversely affects Philips
> marketing efforts.

I am astonished by your verve with which you keep on fighting the wind
mills. Buy a million LPCs per annum and Philips will tell you a few
things, too.

>
> As an example, if they made the MAM statistics registers public, then
> anyone would be able to *measure* the efficacy of MAM without relying
> on (ambit) claims in sales brochures.

Lies, bigger lies and statistics. Someone who wants
'under_$10_ARM7_chip' statistics are a moot point. Am I mistaken?

Onward and upward, Jaya.

Take care

Roger

>
> Jaya
>

Start a New Thread

--- In l..., "roger_lynx" wrote:
> > I have no comment specifically on P1.31 but I know there are certain
> > GPIO pins and registers in LPC whose functionality Philips would not
> > like to disclose.
>
> ..and they keep the documents in Area 51 with Greys?

Do they?

[quote AN10404]

There could also be an additional pin in certain devices which should
not be held low on reset. If low on reset, then the device behavior is
not guaranteed. The following are the pins in various devices:

a. In LPC213x and LPC214x devices, P0.31 should not held low on reset
b. In LPC2114/2124/2212/2214/2119/2129/2194/2290/2292/2294/2210 and 2220
devices, P0.26 should not be held low on reset.

[end quote]

It does not matter if it is P0.31 or P1.31 as the original poster
said. When people keep asking me what these pins do and that they
cannot find this out from the user manuals, I tend to push for disclosure.

It is particularly important when these cause problems that are hard
to debug.

> > I gather such information is available on a need to know basis and
> > subject to NDAs. This may apply to KEIL because they promote LPC.
>
> Uh-oh. A new conspiracy? KEIL is "An ARM company", surely you can
> backup your statement with more specific facts. Oder..?

Not a theory, conspiracy or not. Just echoing what another poster
said in this forum about information in relation to MAM statistics
registers.

> > As an example, if they made the MAM statistics registers public, then
> > anyone would be able to *measure* the efficacy of MAM without relying
> > on (ambit) claims in sales brochures.
>
> Lies, bigger lies and statistics.

If you did a bit of homework, you will realise that MAM statistics
registers do exist and are referred to in documents by vendors.

I dont know if it was KEIL or Hitex document, but I saw reference to
these registers and examples of how to use it to measure the efficacy
of MAM.

If you are not resourceful enough to find this document, I may be able
to help after I get back from my holidays in a week. I can dig this
from my archives.

> Someone who wants
> 'under_$10_ARM7_chip' statistics are a moot point. Am I mistaken?

We have different views with respect to performance data. I try not
to put down clients who ask for such information. I just do my best
to find out, or suggest alternative ways of obtaining such data.

My point is that I cannot see any harm in documenting these registers
given they are useful to anyone who want performance data. Can you?

Jaya

Start a New Thread

--- In l..., "jayasooriah"
wrote:
> > > I gather such information is available on a need to know basis
and
> > > subject to NDAs. This may apply to KEIL because they promote
LPC.
> >
> > Uh-oh. A new conspiracy? KEIL is "An ARM company", surely you can
> > backup your statement with more specific facts. Oder..?
>
> Not a theory, conspiracy or not. Just echoing what another poster
> said in this forum about information in relation to MAM statistics
> registers.
>

[and...]

> My point is that I cannot see any harm in documenting these
registers
> given they are useful to anyone who want performance data. Can
you?
>
> Jaya
>

As with most conspiracy theories, there's a more benign explanation
for an observed set of facts. Here's my alternative theory:

- like any engineering organization, Philips most likely have
internal engineering documents that describe in great detail the
inner workings of their products

- like any other micro there are most likely additional registers
within the memory map that perform functions related to test and/or
production

- because these functions come and go, and are not necessarily the
same across all products in a family, and are not relevant to end
users, company's have no incentive to include them in end user
documentation: the relevant areas of the memory space are usually
just marked as "RESERVED" or something similar

- producing end user documentation is an expensive business, and
resources producing it will invariably be dedicated to explaining
the features that users need to know in order to use the device, in
providing easy to understand clear examples etc.

- supporting that documentation, and ensuring it is kept up-to-date
is also an expensive business.

- in other words, resources are generally stretched enough as it is
producing the documentation we all need to know without seeking
additional work in documenting stuff that's irrelevant

- if you have a valid reason, Philips like other companies, are
quite happy to share their internal engineering documentation. This
sharing of internal documentation is invariably covered by an NDA
(non-disclosure agreement, for those unaware of the acronym), which
establishes the terms on which it is made available. This is
entirely normal: I've signed maybe 20 such agreements over the last
five years myself, for example, and I certainly wouldn't claim to be
a privileged member of some inner sanctum of engineers intent on
preventing the spreading of information. It's just normal business
practice.

There's nothing stopping anyone from playing around with the device
and trying to reverse engineer the product. However, it's clear that
you're on your own here; you're almost certainly working from
incomplete information and making incorrect assumptions. In my view,
you'd be crazy to put anything that relied on this into a commercial
product. We clearly differ on this point.

As for the MAM statistics and their related control registers that
may or may not exist, you shouldn't need them to measure the
effectiveness of the MAM. The MAM timings have already been well
documented and are easy enough to confirm by a set of test software.
OK, so you might have to do a bit of work (to confirm what's already
known), but please don't whine, complain and promote your conspiracy
theories when Philips won't share their information with you.

If you really, really think these supposed registers should be
documented as you believe them to be valuable, might I humbly
suggest you're going the wrong way about influencing Philips to do
so: try asking nicely, they might just respond!

Brendan. Start a New Thread

--- In l..., "brendanmurphy37"
wrote:
> As with most conspiracy theories, there's a more benign explanation
> for an observed set of facts. Here's my alternative theory:

You hit the nail on the head. I am not interested in theories. I am
interested in facts.

> There's nothing stopping anyone from playing around with the device
> and trying to reverse engineer the product. However, it's clear that
> you're on your own here; you're almost certainly working from
> incomplete information and making incorrect assumptions. In my view,
> you'd be crazy to put anything that relied on this into a commercial
> product. We clearly differ on this point.

We certainly do differ in that one of us understands reverse engineering.

> As for the MAM statistics and their related control registers that
> may or may not exist,

Lets me cut to the chase ... they exist. I thought I make use of it
for a open tutorial and wanted to know there is open document.

> you shouldn't need them to measure the
> effectiveness of the MAM.

Thanks for your advice. I know what I doing and I need to make direct
measurements.

> The MAM timings have already been well
> documented and are easy enough to confirm by a set of test software.
> OK, so you might have to do a bit of work (to confirm what's already
> known), but please don't whine, complain and promote your conspiracy
> theories when Philips won't share their information with you.

Thank you again. I read but tend not to rely on information contained
in sales brochures.

> If you really, really think these supposed registers should be
> documented as you believe them to be valuable, might I humbly
> suggest you're going the wrong way about influencing Philips to do
> so: try asking nicely, they might just respond!

I have no desire whatsoever to influence Philips. Philips is an
organisation, not a person and as such does not act on whims and
fancies. Neither does it succumb to brown-nosing as some people think.

Enough of distractions. I shall get off your train here ... as I have
work to do if you dont mind.

Jaya

Start a New Thread

--- In l..., "jayasooriah" wrote:
> We certainly do differ in that one of us understands reverse
engineering.
>

You're right there: we are different. I don't feel the need
gratuitously to insult people who don't agree with me.

Please give everyone in the group a break, and lay off the insults. We
all have better things to do than listen to abusive comments.

Brendan. Start a New Thread