Hello everyone,
I just got my new LPC2368 design back today. I connected the JTAG and
was happy to find that I could download and run code. However after a
few seconds the program would crash and end up at the Pabort or Dabort
handler. The odd things is that the link register has a value that
does not lie on a 32-bit boundary, rather a 16-bit one. Suspecting
something was up with ARM mode I switched to thumb mode and the LED
has been happily blinking ever since.
What might cause the processor to crash in ARM mode, but not thumb? I
have tried the program on an eval board and there was no problem in
either mode. The processor on my board came as a sample from nxp. Is
it possible I got a flaky one?
LPC2368 runs in Thumb mode, not ARM
Started by ●March 28, 2007
Reply by ●March 29, 20072007-03-29
Well, I got it working. It was something to do with the PLL. It
seems that it did not like the default crossworks PLL configuration.
Still strange that it works on one chip and not the other, and also
that it works in thumb mode and not ARM. Seems to work fine with the
PLL off or running at 72MHz, haven't tested intermediate values.
Did anyone else get like 5 copies of my first message?
--- In l..., "drproton2003" wrote:
>
> Hello everyone,
>
> I just got my new LPC2368 design back today. I connected the JTAG and
> was happy to find that I could download and run code. However after a
> few seconds the program would crash and end up at the Pabort or Dabort
> handler. The odd things is that the link register has a value that
> does not lie on a 32-bit boundary, rather a 16-bit one. Suspecting
> something was up with ARM mode I switched to thumb mode and the LED
> has been happily blinking ever since.
>
> What might cause the processor to crash in ARM mode, but not thumb? I
> have tried the program on an eval board and there was no problem in
> either mode. The processor on my board came as a sample from nxp. Is
> it possible I got a flaky one?
>
seems that it did not like the default crossworks PLL configuration.
Still strange that it works on one chip and not the other, and also
that it works in thumb mode and not ARM. Seems to work fine with the
PLL off or running at 72MHz, haven't tested intermediate values.
Did anyone else get like 5 copies of my first message?
--- In l..., "drproton2003" wrote:
>
> Hello everyone,
>
> I just got my new LPC2368 design back today. I connected the JTAG and
> was happy to find that I could download and run code. However after a
> few seconds the program would crash and end up at the Pabort or Dabort
> handler. The odd things is that the link register has a value that
> does not lie on a 32-bit boundary, rather a 16-bit one. Suspecting
> something was up with ARM mode I switched to thumb mode and the LED
> has been happily blinking ever since.
>
> What might cause the processor to crash in ARM mode, but not thumb? I
> have tried the program on an eval board and there was no problem in
> either mode. The processor on my board came as a sample from nxp. Is
> it possible I got a flaky one?
>
Reply by ●March 29, 20072007-03-29
Hello,
I've seen some similar weird flakiness with LPC2368's too. We have a
board that we prototyped with LPC2366's and got the firmware all
working fine (with 12MHz crystal, PLL set for 72MHz). We finally got
in some LPC2368's from Digikey, so we soldered up a batch of boards
with those instead. Weird random flaky behavior, random crashes,
etc.. In further investigation, the CPU was periodically skipping
*over* instructions (in ARM mode). Haven't tried thumb mode, but we
did find that if we ran from the 4MHz RC oscillator in the chip it
worked fine, and then found through experimentation that any PLL
frequency less than 72MHz works fine. We ended up at 48MHz in the end
for LPC2368-equipped board.
I'd say there's definitely some sort of clock rate related flakiness
in the LPC2368's that doesn't occur in the LPC2366's. I suspect they
aren't really capable of reliable operation at 72MHz as advertised.
Nothing in the errata about it though. I would've assumed the
LPC2368's and LPC2366's were the same silicon but with different flash
size enabled, but I guess not..
CPU supply voltage was 3.29V, crystal waveform looks fine going in..
There were no other changes to the board when switching between
LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
we assembled exhibited this problem, while *every* board with
LPC2366's did not.
Just for kicks, could you try your code in ARM mode with the 4MHz
internal RC oscillator still enabled? If using the UART, obviously
you'll need to tweak the divisor to get data out. I'm really curious
if someone else is seeing similar clock rate related flakiness in
LPC2368's.. If so, I'd be surprised if NXP doesn't already know about
it, though I would've expected something in the errata by now..
-Ryan
--- In l..., "drproton2003" wrote:
>
> Well, I got it working. It was something to do with the PLL. It
> seems that it did not like the default crossworks PLL configuration.
> Still strange that it works on one chip and not the other, and also
> that it works in thumb mode and not ARM. Seems to work fine with the
> PLL off or running at 72MHz, haven't tested intermediate values.
>
> Did anyone else get like 5 copies of my first message?
> --- In l..., "drproton2003" wrote:
> >
> > Hello everyone,
> >
> > I just got my new LPC2368 design back today. I connected the JTAG
and
> > was happy to find that I could download and run code. However
after a
> > few seconds the program would crash and end up at the Pabort or
Dabort
> > handler. The odd things is that the link register has a value that
> > does not lie on a 32-bit boundary, rather a 16-bit one. Suspecting
> > something was up with ARM mode I switched to thumb mode and the LED
> > has been happily blinking ever since.
> >
> > What might cause the processor to crash in ARM mode, but not
thumb? I
> > have tried the program on an eval board and there was no problem in
> > either mode. The processor on my board came as a sample from nxp.
Is
> > it possible I got a flaky one?
>
I've seen some similar weird flakiness with LPC2368's too. We have a
board that we prototyped with LPC2366's and got the firmware all
working fine (with 12MHz crystal, PLL set for 72MHz). We finally got
in some LPC2368's from Digikey, so we soldered up a batch of boards
with those instead. Weird random flaky behavior, random crashes,
etc.. In further investigation, the CPU was periodically skipping
*over* instructions (in ARM mode). Haven't tried thumb mode, but we
did find that if we ran from the 4MHz RC oscillator in the chip it
worked fine, and then found through experimentation that any PLL
frequency less than 72MHz works fine. We ended up at 48MHz in the end
for LPC2368-equipped board.
I'd say there's definitely some sort of clock rate related flakiness
in the LPC2368's that doesn't occur in the LPC2366's. I suspect they
aren't really capable of reliable operation at 72MHz as advertised.
Nothing in the errata about it though. I would've assumed the
LPC2368's and LPC2366's were the same silicon but with different flash
size enabled, but I guess not..
CPU supply voltage was 3.29V, crystal waveform looks fine going in..
There were no other changes to the board when switching between
LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
we assembled exhibited this problem, while *every* board with
LPC2366's did not.
Just for kicks, could you try your code in ARM mode with the 4MHz
internal RC oscillator still enabled? If using the UART, obviously
you'll need to tweak the divisor to get data out. I'm really curious
if someone else is seeing similar clock rate related flakiness in
LPC2368's.. If so, I'd be surprised if NXP doesn't already know about
it, though I would've expected something in the errata by now..
-Ryan
--- In l..., "drproton2003" wrote:
>
> Well, I got it working. It was something to do with the PLL. It
> seems that it did not like the default crossworks PLL configuration.
> Still strange that it works on one chip and not the other, and also
> that it works in thumb mode and not ARM. Seems to work fine with the
> PLL off or running at 72MHz, haven't tested intermediate values.
>
> Did anyone else get like 5 copies of my first message?
> --- In l..., "drproton2003" wrote:
> >
> > Hello everyone,
> >
> > I just got my new LPC2368 design back today. I connected the JTAG
and
> > was happy to find that I could download and run code. However
after a
> > few seconds the program would crash and end up at the Pabort or
Dabort
> > handler. The odd things is that the link register has a value that
> > does not lie on a 32-bit boundary, rather a 16-bit one. Suspecting
> > something was up with ARM mode I switched to thumb mode and the LED
> > has been happily blinking ever since.
> >
> > What might cause the processor to crash in ARM mode, but not
thumb? I
> > have tried the program on an eval board and there was no problem in
> > either mode. The processor on my board came as a sample from nxp.
Is
> > it possible I got a flaky one?
>
Reply by ●March 29, 20072007-03-29
Hi,
I have a an MCB2300 board from keil with LPC2368 on it.
I am running the board at 72 MHz (12MHz external crystal.)
ALso the GPIO block is connected to 72MHz.
Everything is working fine and I have not come across any problem.
The code is to run in ARM mode.
May be its the problem with the batch that digikey had.
and I think digikey is out of the stock now [or a callback from NXP!!]
Regards
Suvidh
--- In l..., "Ryan Niemi" wrote:
>
> Hello,
>
> I've seen some similar weird flakiness with LPC2368's too. We have a
> board that we prototyped with LPC2366's and got the firmware all
> working fine (with 12MHz crystal, PLL set for 72MHz). We finally got
> in some LPC2368's from Digikey, so we soldered up a batch of boards
> with those instead. Weird random flaky behavior, random crashes,
> etc.. In further investigation, the CPU was periodically skipping
> *over* instructions (in ARM mode). Haven't tried thumb mode, but we
> did find that if we ran from the 4MHz RC oscillator in the chip it
> worked fine, and then found through experimentation that any PLL
> frequency less than 72MHz works fine. We ended up at 48MHz in the end
> for LPC2368-equipped board.
>
> I'd say there's definitely some sort of clock rate related flakiness
> in the LPC2368's that doesn't occur in the LPC2366's. I suspect they
> aren't really capable of reliable operation at 72MHz as advertised.
> Nothing in the errata about it though. I would've assumed the
> LPC2368's and LPC2366's were the same silicon but with different flash
> size enabled, but I guess not..
>
> CPU supply voltage was 3.29V, crystal waveform looks fine going in..
> There were no other changes to the board when switching between
> LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
> we assembled exhibited this problem, while *every* board with
> LPC2366's did not.
>
> Just for kicks, could you try your code in ARM mode with the 4MHz
> internal RC oscillator still enabled? If using the UART, obviously
> you'll need to tweak the divisor to get data out. I'm really curious
> if someone else is seeing similar clock rate related flakiness in
> LPC2368's.. If so, I'd be surprised if NXP doesn't already know about
> it, though I would've expected something in the errata by now..
>
> -Ryan
> --- In l..., "drproton2003" wrote:
> >
> > Well, I got it working. It was something to do with the PLL. It
> > seems that it did not like the default crossworks PLL configuration.
> > Still strange that it works on one chip and not the other, and also
> > that it works in thumb mode and not ARM. Seems to work fine with the
> > PLL off or running at 72MHz, haven't tested intermediate values.
> >
> >
> >
> > Did anyone else get like 5 copies of my first message?
> >
> >
> > --- In l..., "drproton2003" wrote:
> > >
> > > Hello everyone,
> > >
> > > I just got my new LPC2368 design back today. I connected the JTAG
> and
> > > was happy to find that I could download and run code. However
> after a
> > > few seconds the program would crash and end up at the Pabort or
> Dabort
> > > handler. The odd things is that the link register has a value that
> > > does not lie on a 32-bit boundary, rather a 16-bit one. Suspecting
> > > something was up with ARM mode I switched to thumb mode and the LED
> > > has been happily blinking ever since.
> > >
> > > What might cause the processor to crash in ARM mode, but not
> thumb? I
> > > have tried the program on an eval board and there was no problem in
> > > either mode. The processor on my board came as a sample from nxp.
> Is
> > > it possible I got a flaky one?
> > >
>
I have a an MCB2300 board from keil with LPC2368 on it.
I am running the board at 72 MHz (12MHz external crystal.)
ALso the GPIO block is connected to 72MHz.
Everything is working fine and I have not come across any problem.
The code is to run in ARM mode.
May be its the problem with the batch that digikey had.
and I think digikey is out of the stock now [or a callback from NXP!!]
Regards
Suvidh
--- In l..., "Ryan Niemi" wrote:
>
> Hello,
>
> I've seen some similar weird flakiness with LPC2368's too. We have a
> board that we prototyped with LPC2366's and got the firmware all
> working fine (with 12MHz crystal, PLL set for 72MHz). We finally got
> in some LPC2368's from Digikey, so we soldered up a batch of boards
> with those instead. Weird random flaky behavior, random crashes,
> etc.. In further investigation, the CPU was periodically skipping
> *over* instructions (in ARM mode). Haven't tried thumb mode, but we
> did find that if we ran from the 4MHz RC oscillator in the chip it
> worked fine, and then found through experimentation that any PLL
> frequency less than 72MHz works fine. We ended up at 48MHz in the end
> for LPC2368-equipped board.
>
> I'd say there's definitely some sort of clock rate related flakiness
> in the LPC2368's that doesn't occur in the LPC2366's. I suspect they
> aren't really capable of reliable operation at 72MHz as advertised.
> Nothing in the errata about it though. I would've assumed the
> LPC2368's and LPC2366's were the same silicon but with different flash
> size enabled, but I guess not..
>
> CPU supply voltage was 3.29V, crystal waveform looks fine going in..
> There were no other changes to the board when switching between
> LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
> we assembled exhibited this problem, while *every* board with
> LPC2366's did not.
>
> Just for kicks, could you try your code in ARM mode with the 4MHz
> internal RC oscillator still enabled? If using the UART, obviously
> you'll need to tweak the divisor to get data out. I'm really curious
> if someone else is seeing similar clock rate related flakiness in
> LPC2368's.. If so, I'd be surprised if NXP doesn't already know about
> it, though I would've expected something in the errata by now..
>
> -Ryan
> --- In l..., "drproton2003" wrote:
> >
> > Well, I got it working. It was something to do with the PLL. It
> > seems that it did not like the default crossworks PLL configuration.
> > Still strange that it works on one chip and not the other, and also
> > that it works in thumb mode and not ARM. Seems to work fine with the
> > PLL off or running at 72MHz, haven't tested intermediate values.
> >
> >
> >
> > Did anyone else get like 5 copies of my first message?
> >
> >
> > --- In l..., "drproton2003" wrote:
> > >
> > > Hello everyone,
> > >
> > > I just got my new LPC2368 design back today. I connected the JTAG
> and
> > > was happy to find that I could download and run code. However
> after a
> > > few seconds the program would crash and end up at the Pabort or
> Dabort
> > > handler. The odd things is that the link register has a value that
> > > does not lie on a 32-bit boundary, rather a 16-bit one. Suspecting
> > > something was up with ARM mode I switched to thumb mode and the LED
> > > has been happily blinking ever since.
> > >
> > > What might cause the processor to crash in ARM mode, but not
> thumb? I
> > > have tried the program on an eval board and there was no problem in
> > > either mode. The processor on my board came as a sample from nxp.
> Is
> > > it possible I got a flaky one?
> > >
>
Reply by ●March 29, 20072007-03-29
I too am having issues. I thought it was only me. I'm glad I'm not
crazy here.
I have two keil mcb2370 evaluation boards.
One works great. I have running Freertos+lwIP+lpcusb and in a
seperate app, I have efsl 2.8+freertos running. also with two serial
ports and the i2c and a few other stuff going.
the other mcb2370 has random issues, running, with random lockups.
mostly with larger apps, such as code using the ethernet an usb at the
same time.
Sometimes it seems like the PLL never starts up. I have to reset the
board several times to get the code to run.
I also have a project using the lpc2368 with even worse issues, and
this board also has issues running. random lockups, problems starting.
just general random flackeyness.
I've even noticed that the bootloader, sometime works at 115200 and
other times fails and I have to run it at 57600. (lpc2368)
I have a gut feeling that it could be bad internal memory, or
something like this.
I tried running the boards at 58Mhz as well as thumb mode and still
see issues.
I will try to run an even lower 48Mhz in only thumb mode, and no ISR's
and see if gets it running on the bad parts.
--- In l..., "suvidhk" wrote:
> Hi,
>
> I have a an MCB2300 board from keil with LPC2368 on it.
> I am running the board at 72 MHz (12MHz external crystal.)
> ALso the GPIO block is connected to 72MHz.
> Everything is working fine and I have not come across any problem.
> The code is to run in ARM mode.
>
> May be its the problem with the batch that digikey had.
> and I think digikey is out of the stock now [or a callback from NXP!!]
>
> Regards
>
> Suvidh
> --- In l..., "Ryan Niemi" wrote:
> >
> > Hello,
> >
> > I've seen some similar weird flakiness with LPC2368's too. We have a
> > board that we prototyped with LPC2366's and got the firmware all
> > working fine (with 12MHz crystal, PLL set for 72MHz). We finally got
> > in some LPC2368's from Digikey, so we soldered up a batch of boards
> > with those instead. Weird random flaky behavior, random crashes,
> > etc.. In further investigation, the CPU was periodically skipping
> > *over* instructions (in ARM mode). Haven't tried thumb mode, but we
> > did find that if we ran from the 4MHz RC oscillator in the chip it
> > worked fine, and then found through experimentation that any PLL
> > frequency less than 72MHz works fine. We ended up at 48MHz in the end
> > for LPC2368-equipped board.
> >
> > I'd say there's definitely some sort of clock rate related flakiness
> > in the LPC2368's that doesn't occur in the LPC2366's. I suspect they
> > aren't really capable of reliable operation at 72MHz as advertised.
> > Nothing in the errata about it though. I would've assumed the
> > LPC2368's and LPC2366's were the same silicon but with different flash
> > size enabled, but I guess not..
> >
> > CPU supply voltage was 3.29V, crystal waveform looks fine going in..
> > There were no other changes to the board when switching between
> > LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
> > we assembled exhibited this problem, while *every* board with
> > LPC2366's did not.
> >
> > Just for kicks, could you try your code in ARM mode with the 4MHz
> > internal RC oscillator still enabled? If using the UART, obviously
> > you'll need to tweak the divisor to get data out. I'm really curious
> > if someone else is seeing similar clock rate related flakiness in
> > LPC2368's.. If so, I'd be surprised if NXP doesn't already know about
> > it, though I would've expected something in the errata by now..
> >
> > -Ryan
> >
> >
> > --- In l..., "drproton2003" wrote:
> > >
> > > Well, I got it working. It was something to do with the PLL. It
> > > seems that it did not like the default crossworks PLL
configuration.
> > > Still strange that it works on one chip and not the other, and also
> > > that it works in thumb mode and not ARM. Seems to work fine
with the
> > > PLL off or running at 72MHz, haven't tested intermediate values.
> > >
> > >
> > >
> > > Did anyone else get like 5 copies of my first message?
> > >
> > >
> > > --- In l..., "drproton2003"
wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > I just got my new LPC2368 design back today. I connected the JTAG
> > and
> > > > was happy to find that I could download and run code. However
> > after a
> > > > few seconds the program would crash and end up at the Pabort or
> > Dabort
> > > > handler. The odd things is that the link register has a value
that
> > > > does not lie on a 32-bit boundary, rather a 16-bit one.
Suspecting
> > > > something was up with ARM mode I switched to thumb mode and
the LED
> > > > has been happily blinking ever since.
> > > >
> > > > What might cause the processor to crash in ARM mode, but not
> > thumb? I
> > > > have tried the program on an eval board and there was no
problem in
> > > > either mode. The processor on my board came as a sample from nxp.
> > Is
> > > > it possible I got a flaky one?
> > > >
> > >
>
crazy here.
I have two keil mcb2370 evaluation boards.
One works great. I have running Freertos+lwIP+lpcusb and in a
seperate app, I have efsl 2.8+freertos running. also with two serial
ports and the i2c and a few other stuff going.
the other mcb2370 has random issues, running, with random lockups.
mostly with larger apps, such as code using the ethernet an usb at the
same time.
Sometimes it seems like the PLL never starts up. I have to reset the
board several times to get the code to run.
I also have a project using the lpc2368 with even worse issues, and
this board also has issues running. random lockups, problems starting.
just general random flackeyness.
I've even noticed that the bootloader, sometime works at 115200 and
other times fails and I have to run it at 57600. (lpc2368)
I have a gut feeling that it could be bad internal memory, or
something like this.
I tried running the boards at 58Mhz as well as thumb mode and still
see issues.
I will try to run an even lower 48Mhz in only thumb mode, and no ISR's
and see if gets it running on the bad parts.
--- In l..., "suvidhk" wrote:
> Hi,
>
> I have a an MCB2300 board from keil with LPC2368 on it.
> I am running the board at 72 MHz (12MHz external crystal.)
> ALso the GPIO block is connected to 72MHz.
> Everything is working fine and I have not come across any problem.
> The code is to run in ARM mode.
>
> May be its the problem with the batch that digikey had.
> and I think digikey is out of the stock now [or a callback from NXP!!]
>
> Regards
>
> Suvidh
> --- In l..., "Ryan Niemi" wrote:
> >
> > Hello,
> >
> > I've seen some similar weird flakiness with LPC2368's too. We have a
> > board that we prototyped with LPC2366's and got the firmware all
> > working fine (with 12MHz crystal, PLL set for 72MHz). We finally got
> > in some LPC2368's from Digikey, so we soldered up a batch of boards
> > with those instead. Weird random flaky behavior, random crashes,
> > etc.. In further investigation, the CPU was periodically skipping
> > *over* instructions (in ARM mode). Haven't tried thumb mode, but we
> > did find that if we ran from the 4MHz RC oscillator in the chip it
> > worked fine, and then found through experimentation that any PLL
> > frequency less than 72MHz works fine. We ended up at 48MHz in the end
> > for LPC2368-equipped board.
> >
> > I'd say there's definitely some sort of clock rate related flakiness
> > in the LPC2368's that doesn't occur in the LPC2366's. I suspect they
> > aren't really capable of reliable operation at 72MHz as advertised.
> > Nothing in the errata about it though. I would've assumed the
> > LPC2368's and LPC2366's were the same silicon but with different flash
> > size enabled, but I guess not..
> >
> > CPU supply voltage was 3.29V, crystal waveform looks fine going in..
> > There were no other changes to the board when switching between
> > LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
> > we assembled exhibited this problem, while *every* board with
> > LPC2366's did not.
> >
> > Just for kicks, could you try your code in ARM mode with the 4MHz
> > internal RC oscillator still enabled? If using the UART, obviously
> > you'll need to tweak the divisor to get data out. I'm really curious
> > if someone else is seeing similar clock rate related flakiness in
> > LPC2368's.. If so, I'd be surprised if NXP doesn't already know about
> > it, though I would've expected something in the errata by now..
> >
> > -Ryan
> >
> >
> > --- In l..., "drproton2003" wrote:
> > >
> > > Well, I got it working. It was something to do with the PLL. It
> > > seems that it did not like the default crossworks PLL
configuration.
> > > Still strange that it works on one chip and not the other, and also
> > > that it works in thumb mode and not ARM. Seems to work fine
with the
> > > PLL off or running at 72MHz, haven't tested intermediate values.
> > >
> > >
> > >
> > > Did anyone else get like 5 copies of my first message?
> > >
> > >
> > > --- In l..., "drproton2003"
wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > I just got my new LPC2368 design back today. I connected the JTAG
> > and
> > > > was happy to find that I could download and run code. However
> > after a
> > > > few seconds the program would crash and end up at the Pabort or
> > Dabort
> > > > handler. The odd things is that the link register has a value
that
> > > > does not lie on a 32-bit boundary, rather a 16-bit one.
Suspecting
> > > > something was up with ARM mode I switched to thumb mode and
the LED
> > > > has been happily blinking ever since.
> > > >
> > > > What might cause the processor to crash in ARM mode, but not
> > thumb? I
> > > > have tried the program on an eval board and there was no
problem in
> > > > either mode. The processor on my board came as a sample from nxp.
> > Is
> > > > it possible I got a flaky one?
> > > >
> > >
>
Reply by ●March 29, 20072007-03-29
Ok, I tried lowering the clock rate down to 48 Mhz, and now everything
is starting to work.
now i have a working lpc2368+freertos+lwip @ 48Mhz
This is really messed up that nxp never said anything about this. I
have wasted weeks trying to figure out what is going on.
It seems that some lpc2368's are fine though as people are reporting,
and some are messed up like Ryan's and mine.
--- In l..., "sashi ono" wrote:
>
> I too am having issues. I thought it was only me. I'm glad I'm not
> crazy here.
>
> I have two keil mcb2370 evaluation boards.
> One works great. I have running Freertos+lwIP+lpcusb and in a
> seperate app, I have efsl 2.8+freertos running. also with two serial
> ports and the i2c and a few other stuff going.
>
> the other mcb2370 has random issues, running, with random lockups.
> mostly with larger apps, such as code using the ethernet an usb at the
> same time.
> Sometimes it seems like the PLL never starts up. I have to reset the
> board several times to get the code to run.
>
> I also have a project using the lpc2368 with even worse issues, and
> this board also has issues running. random lockups, problems starting.
> just general random flackeyness.
>
> I've even noticed that the bootloader, sometime works at 115200 and
> other times fails and I have to run it at 57600. (lpc2368)
>
> I have a gut feeling that it could be bad internal memory, or
> something like this.
>
> I tried running the boards at 58Mhz as well as thumb mode and still
> see issues.
> I will try to run an even lower 48Mhz in only thumb mode, and no ISR's
> and see if gets it running on the bad parts.
>
> --- In l..., "suvidhk" wrote:
> >
> >
> > Hi,
> >
> > I have a an MCB2300 board from keil with LPC2368 on it.
> > I am running the board at 72 MHz (12MHz external crystal.)
> > ALso the GPIO block is connected to 72MHz.
> > Everything is working fine and I have not come across any problem.
> > The code is to run in ARM mode.
> >
> > May be its the problem with the batch that digikey had.
> > and I think digikey is out of the stock now [or a callback from NXP!!]
> >
> > Regards
> >
> > Suvidh
> >
> >
> >
> >
> >
> >
> > --- In l..., "Ryan Niemi" wrote:
> > >
> > > Hello,
> > >
> > > I've seen some similar weird flakiness with LPC2368's too. We
have a
> > > board that we prototyped with LPC2366's and got the firmware all
> > > working fine (with 12MHz crystal, PLL set for 72MHz). We
finally got
> > > in some LPC2368's from Digikey, so we soldered up a batch of boards
> > > with those instead. Weird random flaky behavior, random crashes,
> > > etc.. In further investigation, the CPU was periodically skipping
> > > *over* instructions (in ARM mode). Haven't tried thumb mode, but we
> > > did find that if we ran from the 4MHz RC oscillator in the chip it
> > > worked fine, and then found through experimentation that any PLL
> > > frequency less than 72MHz works fine. We ended up at 48MHz in
the end
> > > for LPC2368-equipped board.
> > >
> > > I'd say there's definitely some sort of clock rate related flakiness
> > > in the LPC2368's that doesn't occur in the LPC2366's. I suspect
they
> > > aren't really capable of reliable operation at 72MHz as advertised.
> > > Nothing in the errata about it though. I would've assumed the
> > > LPC2368's and LPC2366's were the same silicon but with different
flash
> > > size enabled, but I guess not..
> > >
> > > CPU supply voltage was 3.29V, crystal waveform looks fine going
in..
> > > There were no other changes to the board when switching between
> > > LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
> > > we assembled exhibited this problem, while *every* board with
> > > LPC2366's did not.
> > >
> > > Just for kicks, could you try your code in ARM mode with the 4MHz
> > > internal RC oscillator still enabled? If using the UART, obviously
> > > you'll need to tweak the divisor to get data out. I'm really
curious
> > > if someone else is seeing similar clock rate related flakiness in
> > > LPC2368's.. If so, I'd be surprised if NXP doesn't already know
about
> > > it, though I would've expected something in the errata by now..
> > >
> > > -Ryan
> > >
> > >
> > > --- In l..., "drproton2003"
wrote:
> > > >
> > > > Well, I got it working. It was something to do with the PLL. It
> > > > seems that it did not like the default crossworks PLL
> configuration.
> > > > Still strange that it works on one chip and not the other, and
also
> > > > that it works in thumb mode and not ARM. Seems to work fine
> with the
> > > > PLL off or running at 72MHz, haven't tested intermediate values.
> > > >
> > > >
> > > >
> > > > Did anyone else get like 5 copies of my first message?
> > > >
> > > >
> > > > --- In l..., "drproton2003"
> wrote:
> > > > >
> > > > > Hello everyone,
> > > > >
> > > > > I just got my new LPC2368 design back today. I connected
the JTAG
> > > and
> > > > > was happy to find that I could download and run code. However
> > > after a
> > > > > few seconds the program would crash and end up at the Pabort or
> > > Dabort
> > > > > handler. The odd things is that the link register has a value
> that
> > > > > does not lie on a 32-bit boundary, rather a 16-bit one.
> Suspecting
> > > > > something was up with ARM mode I switched to thumb mode and
> the LED
> > > > > has been happily blinking ever since.
> > > > >
> > > > > What might cause the processor to crash in ARM mode, but not
> > > thumb? I
> > > > > have tried the program on an eval board and there was no
> problem in
> > > > > either mode. The processor on my board came as a sample
from nxp.
> > > Is
> > > > > it possible I got a flaky one?
> > > > >
> > > >
> > >
>
is starting to work.
now i have a working lpc2368+freertos+lwip @ 48Mhz
This is really messed up that nxp never said anything about this. I
have wasted weeks trying to figure out what is going on.
It seems that some lpc2368's are fine though as people are reporting,
and some are messed up like Ryan's and mine.
--- In l..., "sashi ono" wrote:
>
> I too am having issues. I thought it was only me. I'm glad I'm not
> crazy here.
>
> I have two keil mcb2370 evaluation boards.
> One works great. I have running Freertos+lwIP+lpcusb and in a
> seperate app, I have efsl 2.8+freertos running. also with two serial
> ports and the i2c and a few other stuff going.
>
> the other mcb2370 has random issues, running, with random lockups.
> mostly with larger apps, such as code using the ethernet an usb at the
> same time.
> Sometimes it seems like the PLL never starts up. I have to reset the
> board several times to get the code to run.
>
> I also have a project using the lpc2368 with even worse issues, and
> this board also has issues running. random lockups, problems starting.
> just general random flackeyness.
>
> I've even noticed that the bootloader, sometime works at 115200 and
> other times fails and I have to run it at 57600. (lpc2368)
>
> I have a gut feeling that it could be bad internal memory, or
> something like this.
>
> I tried running the boards at 58Mhz as well as thumb mode and still
> see issues.
> I will try to run an even lower 48Mhz in only thumb mode, and no ISR's
> and see if gets it running on the bad parts.
>
> --- In l..., "suvidhk" wrote:
> >
> >
> > Hi,
> >
> > I have a an MCB2300 board from keil with LPC2368 on it.
> > I am running the board at 72 MHz (12MHz external crystal.)
> > ALso the GPIO block is connected to 72MHz.
> > Everything is working fine and I have not come across any problem.
> > The code is to run in ARM mode.
> >
> > May be its the problem with the batch that digikey had.
> > and I think digikey is out of the stock now [or a callback from NXP!!]
> >
> > Regards
> >
> > Suvidh
> >
> >
> >
> >
> >
> >
> > --- In l..., "Ryan Niemi" wrote:
> > >
> > > Hello,
> > >
> > > I've seen some similar weird flakiness with LPC2368's too. We
have a
> > > board that we prototyped with LPC2366's and got the firmware all
> > > working fine (with 12MHz crystal, PLL set for 72MHz). We
finally got
> > > in some LPC2368's from Digikey, so we soldered up a batch of boards
> > > with those instead. Weird random flaky behavior, random crashes,
> > > etc.. In further investigation, the CPU was periodically skipping
> > > *over* instructions (in ARM mode). Haven't tried thumb mode, but we
> > > did find that if we ran from the 4MHz RC oscillator in the chip it
> > > worked fine, and then found through experimentation that any PLL
> > > frequency less than 72MHz works fine. We ended up at 48MHz in
the end
> > > for LPC2368-equipped board.
> > >
> > > I'd say there's definitely some sort of clock rate related flakiness
> > > in the LPC2368's that doesn't occur in the LPC2366's. I suspect
they
> > > aren't really capable of reliable operation at 72MHz as advertised.
> > > Nothing in the errata about it though. I would've assumed the
> > > LPC2368's and LPC2366's were the same silicon but with different
flash
> > > size enabled, but I guess not..
> > >
> > > CPU supply voltage was 3.29V, crystal waveform looks fine going
in..
> > > There were no other changes to the board when switching between
> > > LPC2366's and LPC2368's. In our tests, *every* board with LPC2368's
> > > we assembled exhibited this problem, while *every* board with
> > > LPC2366's did not.
> > >
> > > Just for kicks, could you try your code in ARM mode with the 4MHz
> > > internal RC oscillator still enabled? If using the UART, obviously
> > > you'll need to tweak the divisor to get data out. I'm really
curious
> > > if someone else is seeing similar clock rate related flakiness in
> > > LPC2368's.. If so, I'd be surprised if NXP doesn't already know
about
> > > it, though I would've expected something in the errata by now..
> > >
> > > -Ryan
> > >
> > >
> > > --- In l..., "drproton2003"
wrote:
> > > >
> > > > Well, I got it working. It was something to do with the PLL. It
> > > > seems that it did not like the default crossworks PLL
> configuration.
> > > > Still strange that it works on one chip and not the other, and
also
> > > > that it works in thumb mode and not ARM. Seems to work fine
> with the
> > > > PLL off or running at 72MHz, haven't tested intermediate values.
> > > >
> > > >
> > > >
> > > > Did anyone else get like 5 copies of my first message?
> > > >
> > > >
> > > > --- In l..., "drproton2003"
> wrote:
> > > > >
> > > > > Hello everyone,
> > > > >
> > > > > I just got my new LPC2368 design back today. I connected
the JTAG
> > > and
> > > > > was happy to find that I could download and run code. However
> > > after a
> > > > > few seconds the program would crash and end up at the Pabort or
> > > Dabort
> > > > > handler. The odd things is that the link register has a value
> that
> > > > > does not lie on a 32-bit boundary, rather a 16-bit one.
> Suspecting
> > > > > something was up with ARM mode I switched to thumb mode and
> the LED
> > > > > has been happily blinking ever since.
> > > > >
> > > > > What might cause the processor to crash in ARM mode, but not
> > > thumb? I
> > > > > have tried the program on an eval board and there was no
> problem in
> > > > > either mode. The processor on my board came as a sample
from nxp.
> > > Is
> > > > > it possible I got a flaky one?
> > > > >
> > > >
> > >
>
Reply by ●March 29, 20072007-03-29
--- In l..., "sashi ono" wrote:
>
> I have a gut feeling that it could be bad internal memory, or
> something like this.
>
I suspect the problem is in the PLL hold capability -- it seems to
lose lock at least when using IRC.
Jaya
>
> I have a gut feeling that it could be bad internal memory, or
> something like this.
>
I suspect the problem is in the PLL hold capability -- it seems to
lose lock at least when using IRC.
Jaya
Reply by ●March 30, 20072007-03-30
--- In l..., "sashi ono" wrote:
>
> Ok, I tried lowering the clock rate down to 48 Mhz, and now everything
> is starting to work.
> now i have a working lpc2368+freertos+lwip @ 48Mhz
>
I'm running LPC2378+freertos+lwip @ 72MHz without any problems.
Are you shure that your PLL settings are OK?
>
> Ok, I tried lowering the clock rate down to 48 Mhz, and now everything
> is starting to work.
> now i have a working lpc2368+freertos+lwip @ 48Mhz
>
I'm running LPC2378+freertos+lwip @ 72MHz without any problems.
Are you shure that your PLL settings are OK?
Reply by ●March 30, 20072007-03-30
--- In l..., "slawcus" wrote:
>
> --- In l..., "sashi ono" wrote:
> >
> > Ok, I tried lowering the clock rate down to 48 Mhz, and now everything
> > is starting to work.
> > now i have a working lpc2368+freertos+lwip @ 48Mhz
> > I'm running LPC2378+freertos+lwip @ 72MHz without any problems.
>
> Are you shure that your PLL settings are OK?
>
I put up that lpc+freertos+lwip demo. It works great with the lpc2378
at 72Mhz. but with the lpc2368 I have, it crashes right away.
when I lower the clock to 48 Mhz it works.
It appears that only some lpc2368's are affected with this problem
though. As other users are reporting that their lpc2368's run fine at
72Mhz.
I can still run basic code such as RTOS+dual uarts+ i2c code on the
lcp2368 at 72Mhz. but when I try the ethernet, it crashes. It also
crashes using the efsl stack at 72 Mhz, but works at 48Mhz. It appears
that anything memory intensive @ 72 Mhz causes it to crash.
When I load the exact same hex file on the lpc2378 @72 Mhz it works
great. loading it on the lpc2368 causes it to crash.
leading to my conclusion that some lpc2368 parts are bad. And thus I
will run my lpc2368 at 48 Mhz until a new rev comes out.
>
> --- In l..., "sashi ono" wrote:
> >
> > Ok, I tried lowering the clock rate down to 48 Mhz, and now everything
> > is starting to work.
> > now i have a working lpc2368+freertos+lwip @ 48Mhz
> > I'm running LPC2378+freertos+lwip @ 72MHz without any problems.
>
> Are you shure that your PLL settings are OK?
>
I put up that lpc+freertos+lwip demo. It works great with the lpc2378
at 72Mhz. but with the lpc2368 I have, it crashes right away.
when I lower the clock to 48 Mhz it works.
It appears that only some lpc2368's are affected with this problem
though. As other users are reporting that their lpc2368's run fine at
72Mhz.
I can still run basic code such as RTOS+dual uarts+ i2c code on the
lcp2368 at 72Mhz. but when I try the ethernet, it crashes. It also
crashes using the efsl stack at 72 Mhz, but works at 48Mhz. It appears
that anything memory intensive @ 72 Mhz causes it to crash.
When I load the exact same hex file on the lpc2378 @72 Mhz it works
great. loading it on the lpc2368 causes it to crash.
leading to my conclusion that some lpc2368 parts are bad. And thus I
will run my lpc2368 at 48 Mhz until a new rev comes out.
Reply by ●March 31, 20072007-03-31
----- Original Message -----
From: "sashi ono"
To:
Sent: Friday, March 30, 2007 9:59 PM
Subject: [lpc2000] Re: Some LPC2368's chips are messed up
> --- In l..., "slawcus" wrote:
>>
>> --- In l..., "sashi ono" wrote:
>> >
>> > Ok, I tried lowering the clock rate down to 48 Mhz, and now everything
>> > is starting to work.
>> > now i have a working lpc2368+freertos+lwip @ 48Mhz
>> >
>>
>> I'm running LPC2378+freertos+lwip @ 72MHz without any problems.
>>
>> Are you shure that your PLL settings are OK?
>> I put up that lpc+freertos+lwip demo. It works great with the lpc2378
> at 72Mhz. but with the lpc2368 I have, it crashes right away.
> when I lower the clock to 48 Mhz it works.
> It appears that only some lpc2368's are affected with this problem
> though. As other users are reporting that their lpc2368's run fine at
> 72Mhz.
>
> I can still run basic code such as RTOS+dual uarts+ i2c code on the
> lcp2368 at 72Mhz. but when I try the ethernet, it crashes. It also
> crashes using the efsl stack at 72 Mhz, but works at 48Mhz. It appears
> that anything memory intensive @ 72 Mhz causes it to crash.
>
> When I load the exact same hex file on the lpc2378 @72 Mhz it works
> great. loading it on the lpc2368 causes it to crash.
>
> leading to my conclusion that some lpc2368 parts are bad. And thus I
> will run my lpc2368 at 48 Mhz until a new rev comes out.
Have you contacted NXP about this?
Leon
From: "sashi ono"
To:
Sent: Friday, March 30, 2007 9:59 PM
Subject: [lpc2000] Re: Some LPC2368's chips are messed up
> --- In l..., "slawcus" wrote:
>>
>> --- In l..., "sashi ono" wrote:
>> >
>> > Ok, I tried lowering the clock rate down to 48 Mhz, and now everything
>> > is starting to work.
>> > now i have a working lpc2368+freertos+lwip @ 48Mhz
>> >
>>
>> I'm running LPC2378+freertos+lwip @ 72MHz without any problems.
>>
>> Are you shure that your PLL settings are OK?
>> I put up that lpc+freertos+lwip demo. It works great with the lpc2378
> at 72Mhz. but with the lpc2368 I have, it crashes right away.
> when I lower the clock to 48 Mhz it works.
> It appears that only some lpc2368's are affected with this problem
> though. As other users are reporting that their lpc2368's run fine at
> 72Mhz.
>
> I can still run basic code such as RTOS+dual uarts+ i2c code on the
> lcp2368 at 72Mhz. but when I try the ethernet, it crashes. It also
> crashes using the efsl stack at 72 Mhz, but works at 48Mhz. It appears
> that anything memory intensive @ 72 Mhz causes it to crash.
>
> When I load the exact same hex file on the lpc2378 @72 Mhz it works
> great. loading it on the lpc2368 causes it to crash.
>
> leading to my conclusion that some lpc2368 parts are bad. And thus I
> will run my lpc2368 at 48 Mhz until a new rev comes out.
Have you contacted NXP about this?
Leon
