--- In l..., "Leon" wrote:
>
> ----- 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
>
Not yet, I would like a someone else to confirm that they are having
the same problems.
LPC2368 runs in Thumb mode, not ARM
Started by ●March 28, 2007
Reply by ●April 1, 20072007-04-01
Reply by ●April 1, 20072007-04-01
--- In l..., "sashi ono" wrote:
>
> --- In l..., "Leon" wrote:
> > Have you contacted NXP about this?
> >
> > Leon
> > Not yet, I would like a someone else to confirm that they are having
> the same problems.
>
In my experience it's best to get it as definitive as possible that it
is a problem with the device before anything like this will be taken
too seriously.
If possible, work towards a minimal program (i.e. a few tens of lines
of code at the most), that either works or fails depending on what you
find to be the trigger (in this case it seems to be clock speed).
Ideally, this should be done on some standard board (i.e. not one that
is itself under development).
There are just too many possibilities for other sources of error (e.g.
programming errors, errors in compilers generating bad code etc.) that
cause seemingly mysterious crashes. For example, when the speed goes
up, so does the current consumption: is there a problem with the power
supply? A previously undiscovered problem with the device is probably
the least likely cause.
In other words, I'd make sure you discount as much as you can before
reporting a problem with the device to NXP.
>
> --- In l..., "Leon" wrote:
> > Have you contacted NXP about this?
> >
> > Leon
> > Not yet, I would like a someone else to confirm that they are having
> the same problems.
>
In my experience it's best to get it as definitive as possible that it
is a problem with the device before anything like this will be taken
too seriously.
If possible, work towards a minimal program (i.e. a few tens of lines
of code at the most), that either works or fails depending on what you
find to be the trigger (in this case it seems to be clock speed).
Ideally, this should be done on some standard board (i.e. not one that
is itself under development).
There are just too many possibilities for other sources of error (e.g.
programming errors, errors in compilers generating bad code etc.) that
cause seemingly mysterious crashes. For example, when the speed goes
up, so does the current consumption: is there a problem with the power
supply? A previously undiscovered problem with the device is probably
the least likely cause.
In other words, I'd make sure you discount as much as you can before
reporting a problem with the device to NXP.
Reply by ●April 2, 20072007-04-02
Are you sure that when you set up the PLL the Fcco frequency is less
than 290MHz? The errata states that it will not run if you set it
greater than this.
--- 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?
> > > > >
> > > >
> > >
>
than 290MHz? The errata states that it will not run if you set it
greater than this.
--- 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?
> > > > >
> > > >
> > >
>
