Xpresso Examples

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Sun Apr 01 11:24:28 MST 2012
Welcome.
I would like to post some questions regarding examples provided (LPCXpresso 4.1.5) in here.

[B]Q1:[/B] Solved[INDENT] File "system_LPC17xx.c", line 503:

while (!(LPC_SC->PLL0STAT & ((1<<25) | (1<<24))));/* Wait for PLLC0_STAT & PLLE0_STAT */

This loop is supposed to poll both bits to make sure PLL0 is locked and ready:

Quote: LPC17xx User manual, rev. 2
When PLLC0 and PLLE0 are both one, PLL0 is connected as the clock source for the CPU. When either PLLC0 or PLLE0 is zero, PLL0 is bypassed.

The code does not match the comment/manual or I got it wrong?
[/INDENT][B]Q2: [/B]Pending[INDENT]I do not understand "reserved" bitfields' descriptions (I do not get the subtle differences among those), LPC17XX UM, rev. 2, here I give some examples of those descriptions:[INDENT]a) "Reserved. The value read from a reserved bit is not defined."
b) "Reserved, user software should not write ones to reserved bits. The value read from a reserved bit is not defined."
c) "Reserved. User software should not write ones to reserved bits. These bits read always back as zeroes"
d) "Reserved, and must be written as 0"
e) "Reserved for Debug use. This bit reads as 0. When writing to the register you must write 0 to this bit, otherwise behavior is Unpredictable."
f) "Reserved."
[/INDENT]A Glossary definition of "Reserved" term from the same UM:
"Reserved — A field in a control register or instruction format is reserved if the field is to be defined by the implementation, or produces Unpredictable results if the contents of the field are not zero. These fields are reserved for use in future extensions of the architecture or are implementation-specific. All reserved bits not used by the implementation must be written as 0 and read as 0."

Could someone give a reference on the differences of (a-f)?
LPCXpresso examples are inconsistent w.r.t. the subject..
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by agatsu on Mon Aug 13 12:54:50 MST 2012
Hi All,

I would like to use software timer APIs provided by FreeRTOS for my LPC1227 project:
http://www.freertos.org/FreeRTOS-Software-Timer-API-Functions.html

but the FreeRTOS examples for LPC12xx from:
http://ics.nxp.com/support/lpcxpresso/

does not have FreeRTOS timer APIs. It must be outdated. If anyone is aware of any working examples of FreeRTOS timer please send me the info.

Thanks in advance.

- agatsu

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Wed Jul 18 21:58:31 MST 2012

Quote: Brutte

Fortunately CR supplies a nice IDE with examples, but still, that is a challenge for an 8-bitter like Brutte. How I hate those 0x4fb6d7c9 hexes:mad:

It could be worse 0b01001111101101101101011111001001:p

I have to remember where I was in the learning curve and pick up the pieces again.:eek: Enough chit chat, don't want to piss off Zero, back to work.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Wed Jul 18 16:58:52 MST 2012

Quote: larryvc
@Brutte, I see you finally got one of those "Monsters"(..) :)

Hi, unlike there - I am an absolute beginner in here (not to be confused with "noob") :).
It takes a lot of time to understand how these bees buzz and why they sting so often.

Fortunately CR supplies a nice IDE with examples, but still, that is a challenge for an 8-bitter like Brutte. How I hate those 0x4fb6d7c9 hexes:mad:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Tue Jul 17 18:33:22 MST 2012
@Brutte, I see you finally got one of those "Monsters", your word, that I told you about on the "other" forum.:)

@Rob65, you definitely have not changed.:rolleyes:

@Zero, I need a refresher course on the 1769, I will be asking a lot of questions.;)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by creafyumi on Sun Jul 08 20:09:55 MST 2012

Quote: Brutte
But, in case of write, how do you know that (reference, please)? This applies to a, b, .. or f "reserved" type? Or all of them:confused:
Or did you mean "(...)always make sure we will not toggle the bit [I]from 0[/I] to 1"?

What about read?

If it were so simple, why did NXP guys introduce 6 different descriptions + additional Glossary definition for the "reserved"?

By the way, LPCXpresso example of (a) type I gave above contradicts your thesis :).
It could be another bug, but works OK on my LPC1769.

Quote:
This applies to a, b, .. or f "reserved" type?

Quote:
If it were so simple, why did NXP guys introduce 6 different descriptions + additional Glossary definition for the "reserved"?

Of course this applies to all... Didn't you find that all a to f require the reserved bit be written as 0(if write action applied)? When read, there are different situations, sometimes the reserved bits are zeroes, sometimes the reserved bits are subject to changes if the reserved function enabled. Why so confused..

Quote:
a) "Reserved. The value read from a reserved bit is not defined."
b) "Reserved, user software should not write ones to reserved bits. The value read from a reserved bit is not defined."
c) "Reserved. User software should not write ones to reserved bits. These bits read always back as zeroes"
d) "Reserved, and must be written as 0"
e) "Reserved for Debug use. This bit reads as 0. When writing to the register you must write 0 to this bit, otherwise behavior is Unpredictable."
f) "Reserved."

Quote:
By the way, LPCXpresso example of (a) type I gave above contradicts your thesis :).
It could be another bug, but works OK on my LPC1769.

Just believe in yourself, do not trust examples. :)
Now it works OK, behavior maybe unpredictable in the future.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Fri Jul 06 03:39:45 MST 2012

Quote: creafyumi
Well, when encounter reserved bit, always make sure we will not set the bit to 1 will do.

But, in case of write, how do you know that (reference, please)? This applies to a, b, .. or f "reserved" type? Or all of them:confused:
Or did you mean "(...)always make sure we will not toggle the bit [I]from 0[/I] to 1"?

What about read?

If it were so simple, why did NXP guys introduce 6 different descriptions + additional Glossary definition for the "reserved"?

By the way, LPCXpresso example of (a) type I gave above contradicts your thesis :).
It could be another bug, but works OK on my LPC1769.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by creafyumi on Fri Jul 06 01:37:57 MST 2012
Well, when encounter reserved bit, always make sure we will not set the bit to 1 will do.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Tue Jul 03 12:18:07 MST 2012
I have updated an entry post with my second question:

Quote: Brutte
[B]Q2:[/B] I do not understand "reserved" bitfields' descriptions.

Was "reserved" discussed somewhere before?

Some LPCXpresso example:

LPC_SC->FLASHCFG  = (LPC_SC->FLASHCFG & ~0x0000F000) | FLASHCFG_Val;

and the FLASHCFG contains a reserved bitfields of (a) type..

lpcware · ‎06-15-2016

Content originally posted in LPCWare by creafyumi on Thu Jun 14 20:19:13 MST 2012

Quote: Rob65
Apparently is this time of the year again ...
Some of us 'old men' read and post a lot on this forum. I've done my share last year spending way too much time reading and answering questions asked by users.

Unfortunately there are too many n00bs popping up from time to time - luckily there are also a lot of Newbs and it's sometimes hard to tell the difference from one or two posts.
After looking at a lot of n00b questions I get kind of stomped and start making silly, stupid or even sarcastic remarks.

How many times have I hinted people to read the getting started manual when the stupid (here I go again) question was how to debug a project. Or questions like "can somebody provide me an example about ..." - with a perfectly fitting example available in the examples projects.
I think Zero is just like me - only he's the one who mostly keeps his good attitude a bit longer ...

And then I end up at this thread ...
Two whole pages about something simple like this silly while loop.
TWO HOLE PAGES for one line of code that is just redundant :eek:

To clarify (once and for all): This line of code loops until either one of the PLL0STAT bits (24|25) is a 1. If you look at the lines of code just before this one (and read the description of the PLL0 registers in the user manual) then you'll see that at this point PLL0STAT always has both bits 1 (PLL0CON programmed + FEED sequence given).

So this while will never loop - and always all through.

And now guess what I did ... I copied this line of code into my own version of PLL code without checking just a few month ago :D

Rob

P.s: never call yourself a n00b: a n00b is someone who knows little and has no will to learn whereas a Newb (or newbie) is eager to learn :rolleyes:

:)
Understand that, n00b sometimes will drive people crazy while Newbie is different.

The question TS asked is definitely not "n00b question", actually the sample code logic is indeed wrong. TS is so careful that he/she found it(I even did not notice that!) does not match with UM. Response without careful thinking is a kind of irresponsible.

We change the world, do not let the world change us! The world is full of n00b,kids,newbie.. if we changed our attitude, it is not the world's problem, it is the problem of ourselves! We failed to guard our believing! Blame the world is just an excuse.

P.s: I always call myself a newbie, willing to learn and willing to share my effort. Appreciate the effort of others and show my respect.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Thu Jun 14 09:44:46 MST 2012

Quote: creafyumi

I do not like the way you communicate with people, like a sarcastic "adult" old man. Well you did provide some clue(No matter it helps or not), we appreciate your effort.

Apparently is this time of the year again ...
Some of us 'old men' read and post a lot on this forum. I've done my share last year spending way too much time reading and answering questions asked by users.

Unfortunately there are too many n00bs popping up from time to time - luckily there are also a lot of Newbs and it's sometimes hard to tell the difference from one or two posts.
After looking at a lot of n00b questions I get kind of stomped and start making silly, stupid or even sarcastic remarks.

How many times have I hinted people to read the getting started manual when the stupid (here I go again) question was how to debug a project. Or questions like "can somebody provide me an example about ..." - with a perfectly fitting example available in the examples projects.
I think Zero is just like me - only he's the one who mostly keeps his good attitude a bit longer ...

And then I end up at this thread ...
Two whole pages about something simple like this silly while loop.
TWO HOLE PAGES for one line of code that is just redundant :eek:

To clarify (once and for all): This line of code loops until either one of the PLL0STAT bits (24|25) is a 1. If you look at the lines of code just before this one (and read the description of the PLL0 registers in the user manual) then you'll see that at this point PLL0STAT always has both bits 1 (PLL0CON programmed + FEED sequence given).

So this while will never loop - and always all through.

And now guess what I did ... I copied this line of code into my own version of PLL code without checking just a few month ago :D

Rob

P.s: never call yourself a n00b: a n00b is someone who knows little and has no will to learn whereas a Newb (or newbie) is eager to learn :rolleyes:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by creafyumi on Wed Jun 13 17:41:28 MST 2012

Quote: kayoda
Let's say it's working code, if you want to punish your compiler :eek:

Otherwise use an adult version:

  while((LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))!= (3<<24));

One More Step forward.:)

Quote:
Quote:
Originally Posted by kayoda
Let's say it's working code, if you want to punish your compiler

Otherwise use an adult version:
Code:
while((LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))!= (3<<24));
Code:
while((LPC_SC->PLL0STAT & (3<<24))!= (3<<24));
just shows that reading adult publications isn't always good for ones health.

Again one more steps

[IMG]http://knowledgebase.nxp.com/images/icons/icon14.gif[/IMG]

Quote:
Quote:
Originally Posted by kayoda
Let's say it's working code, if you want to punish your compiler

Otherwise use an adult version:
Code:
while((LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))!= (3<<24));

@Kay: Please explain this kids that there's a 'Disassembly View' which shows the difference. Otherwise they think you are talking about compile time details

I do not like the way you communicate with people, like a sarcastic "adult" old man. Well you did provide some clue(No matter it helps or not), we appreciate your effort. We may not that professional(like kids and newbie), but we have the freedom to share our ideas and try our best to help each other, we are equal essentially, although we may have different strong points. Sometimes attitude is more important. Thanks.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Wed Jun 13 09:33:36 MST 2012

Quote: Zero

What do you think is happening here?(...)
Since there's no delay needed, you are free to decide if you want to check both bits, no bits or just count yellow submarines ;)

I do understand the problem now - no hidden and mysterious background, just bugs and useless code counting yellow submarines. Initially I thought that perhaps my C or UM were incomplete but now I am more self-confident.

Anyway, thank you all for explanations/hints.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Jun 13 07:17:12 MST 2012

Quote: kayoda
Let's say it's working code, if you want to punish your compiler :eek:

Otherwise use an adult version:

  while((LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))!= (3<<24));

@Kay: Please explain this kids that there's a 'Disassembly View' which shows the difference. Otherwise they think you are talking about compile time details

lpcware · ‎06-15-2016

Content originally posted in LPCWare by stalisman on Wed Jun 13 05:57:03 MST 2012

Quote: kayoda
Let's say it's working code, if you want to punish your compiler :eek:

Otherwise use an adult version:

  while((LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))!= (3<<24));

  while((LPC_SC->PLL0STAT & (3<<24))!= (3<<24));

just shows that reading adult publications isn't always good for ones health.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ex-kayoda on Wed Jun 13 02:58:35 MST 2012

Quote: creafyumi
This is the correct code

Let's say it's working code, if you want to punish your compiler :eek:

Otherwise use an adult version:

  while((LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))!= (3<<24));

lpcware · ‎06-15-2016

Content originally posted in LPCWare by creafyumi on Wed Jun 13 01:52:47 MST 2012

Quote: stalisman
The value of ((1<<25) | (1<<24)) in the expression is always 0x30000000.

The value of (LPC_SC->PLL0STAT & ((1<<25) | (1<<24)) ) is 0 only if both bits 24 and 25 are clear

The value of (!(LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))) is thus 1 only if both bits 24 and 25 are clear.

Thus: while(!(LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))) will loop until either or both of bits 24 and 25 become set.

This is not what the documentation is saying.

The expression !( (LPC_SC->PLL0STAT & (1<<25)) && (LPC_SC->PLL0STAT & (1<<24)) ) reflects what the poor comment in the code is trying to say..

[IMG]http://knowledgebase.nxp.com/images/icons/icon14.gif[/IMG] Very clear explanation.

Quote:
!( (LPC_SC->PLL0STAT & (1<<25)) && (LPC_SC->PLL0STAT & (1<<24)) )

This is the correct code(If want to code this line). :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by stalisman on Wed Jun 13 01:38:08 MST 2012
The value of ((1<<25) | (1<<24)) in the expression is always 0x30000000.

The value of (LPC_SC->PLL0STAT & ((1<<25) | (1<<24)) ) is 0 only if both bits 24 and 25 are clear

The value of (!(LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))) is thus 1 only if both bits 24 and 25 are clear.

Thus: while(!(LPC_SC->PLL0STAT & ((1<<25) | (1<<24)))) will loop until either or both of bits 24 and 25 become set.

This is not what the documentation is saying.

The expression !( (LPC_SC->PLL0STAT & (1<<25)) && (LPC_SC->PLL0STAT & (1<<24)) ) reflects what the poor comment in the code is trying to say..

lpcware · ‎06-15-2016

Content originally posted in LPCWare by creafyumi on Wed Jun 13 01:37:49 MST 2012

Quote:
is (software) nonsense. It's looping if both bits are 0 (and bit 24 has been set long time before) and not waiting until both are 1.

Actually it's looping if both bits are 0 and not waiting if [B]one of them[/B] becomes 1(not both are 1), so this code line is not necessary and it is also logic wrong.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Wed Jun 13 01:27:09 MST 2012

Quote:

Till some guru gives a convincing reference.

Good luck :rolleyes:

Meanwhile back to basics (=hardware):

What do you think is happening here?

#1 This part of SystemInit is enabling and locking PLL0 to desired speed (100MHz).

#2 If this is confirmed (= locked) it's switching main clock from IRC (4MHz) to PLL0.

The dangerous and slow part here is enabling and locking PLL0 (see UM). Therefore a loop is useful to wait for successful locking of PLL0. If you insert a loop counter here you can see a real delay which confirms that we are seeing a slow process.

Connecting PLL0 is a fast process, there's no delay necessary. Therefore some samples even doesn't check status register for bit 24 and bit 25.

Of course

while (!(LPC_SC->PLL0STAT & ((1<<25) | (1<<24))));/* Wait for PLLC0_STAT & PLLE0_STAT */

is (software) nonsense. It's looping if both bits are 0 (and bit 24 has been set long time before) and not waiting until both are 1.

Since there's no delay needed, you are free to decide if you want to check both bits, no bits or just count yellow submarines

lpcware · ‎06-15-2016

Content originally posted in LPCWare by creafyumi on Tue Jun 12 18:02:03 MST 2012

Quote:
Do you think that perhaps these bitfields are connected with some mysterious background hardware? That is not what my UM says:

It is not I think that these bitfields are connected with some mysterious background hardware, You set the PLL0CON to be PLL0 Enable & Connect, if nothing wrong, the PLL0 Enable bit and PLL0 Connect bit should be both 1, what you expect? You set it to be [I]Enable & Connect[/I], it should follow unless something wrong. If you only set it to be Enable or you only set it to be Connect, it is another topic.
PLLE0_STAT:Read-back for the PLL0 Enable bit.
PLLC0_STAT:Read-back for the PLL0 Connect bit.

Quote:
Verifying a compile time constant never fails. If it is that simple as UM says (without a mysterious background), it could/should be removed. I will stick an assert there for now.

The UM is not wrong! What I mean is you set it to be [I]Enable & Connect[/I], the result should be PLLE0_STAT & PLLC0_STAT both 1. Nothing to do with "mysterious background" or something. If you only set Enable or Connect, well, you may have the condition as listed in the UM, there are four possibilities: [0 0] [0 1] [1 0] [1 1].

Well, this line could be removed.. See below: If you still feel uncomfortable, you can correct this line and mark it.

Quote:
Till some guru gives a convincing reference.

Well If you still doubt that, I can provide one reference to you. Actually not all sample code have this code line. I believe that the sample code your are looking at is provided in[I]CMSISv1p30_LPC17xx[/I](Right?), you may open another library [I]CMSISv2_LPC17xx[/I] and you will see a bit different implementation.

#if (PLL0_SETUP)
  LPC_SC->PLL0CFG   = PLL0CFG_Val;
  LPC_SC->PLL0CON   = 0x01;             /* PLL0 Enable                        */
  LPC_SC->PLL0FEED  = 0xAA;
  LPC_SC->PLL0FEED  = 0x55;
  
  /* Check which PLL clock source is selected */
  if (LPC_SC->CLKSRCSEL != 2){
    while (!(LPC_SC->PLL0STAT & (1<<26)));/* Wait for PLOCK0                    */
  }else {/* If RTC is selected, a delay of min 500us is needed */
for (cntr=0; cntr <= 100; cntr++);/* Wait min. 500us before connecting PLL */
  }

  LPC_SC->PLL0CON   = 0x03;             /* PLL0 Enable & Connect              */
  LPC_SC->PLL0FEED  = 0xAA;
  LPC_SC->PLL0FEED  = 0x55;
#endif

Well, you can see there is nothing(Status Checking) after PLL0 Enable & Connect.

Thanks and hope the information is helpful.