EmbeddedRelated.com
Forums
Memfault Beyond the Launch

LPC2136 big code crash problem

Started by Aleksandar Zivkovic February 7, 2008
Hello,
I have a problem that gives me a headache for some time. I am working
on an LPC2136 based platform on a project that was developed on
Rowley Crossworks before me. The platform includes different kind of
devices such as: serial flash, bluetooth module, LCD graphic display ,
etc... Last months I moved that code to KEIL development environment.I
was translating C code step by step and at one stage it began to act
very strange:
- after some time after power-up it crashes and goes into reset state
- then I add or remove some C code line and it starts working correctly
- if I add some new code it acts like before, crashes

I got a feeling that compiler writes over some mem locations,
therefore I added code protection explained in KEIL web site. I
thought that Flash Magic I am using puts its 87654321 over some
program instruction. But it didn't help.
The strangest thing to me is that changing some unimportant code lines
(like switching some GPIO pins on and off) affects this dramatic change.

I know that info that I gave to you guys and girls is not enough to
give me explicit help but if you would give me some advices where to
start looking for my error source it would be a great!

I am not able to connect JTAG to my platform, but can use UART to
catch various info...

Thank you in advance!

An Engineer's Guide to the LPC2100 Series

Aleksandar Zivkovic Wrote
> I have a problem that gives me a headache for some time. I am working
> on an LPC2136 based platform on a project that was developed on
> Rowley Crossworks before me. The platform includes different kind of
> devices such as: serial flash, bluetooth module, LCD graphic display ,
> etc... Last months I moved that code to KEIL development environment.

Ahhh, the perils of changing development systems mid-stream. Why did you
attempt that?

> I was translating C code step by step and at one stage it began to act
> very strange:

If there was very much translating necessary that's an issue.

> - after some time after power-up it crashes and goes into reset state
> - then I add or remove some C code line and it starts working correctly
> - if I add some new code it acts like before, crashes

Heisenbug, always among the worst to find.

> I got a feeling that compiler writes over some mem locations,

The compiler can't. The program might.

> therefore I added code protection explained in KEIL web site. I

Why on earth would that make a difference? You can't overwrite the flash
casually and it certainly won't protect the RAM.

> thought that Flash Magic I am using puts its 87654321 over some
> program instruction. But it didn't help.
> The strangest thing to me is that changing some unimportant code lines
> (like switching some GPIO pins on and off) affects this dramatic change.
>
> I know that info that I gave to you guys and girls is not enough to
> give me explicit help but if you would give me some advices where to
> start looking for my error source it would be a great!

Wild pointer, array overrun, stack overrun, misaligned pointer, race
condition, watchdog timer....

The possibilities are nearly endless.

You can start putting markers in the code to see if the crash occurs at a
consistent point. Hopefully you have a few spare I/O pins. Finding the area
via serial port may be possible but the timing changes introduced may cause
the bugs apparent location to shift. If the program was as poorly
structured as your translating efforts imply you may be better off
re-writing than searching for the problem.

Robert
--------------------------------
mail2web.com What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint



Hi,

> Aleksandar Zivkovic Wrote
> > I have a problem that gives me a headache for some time. I am working
> > on an LPC2136 based platform on a project that was developed on
> > Rowley Crossworks before me. The platform includes different kind of
> > devices such as: serial flash, bluetooth module, LCD graphic display
> ,
> > etc... Last months I moved that code to KEIL development environment.
>
> Ahhh, the perils of changing development systems mid-stream. Why did
> you attempt that?

That's a very good question... Aleksader, are you still at UAH?

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
> I have a problem that gives me a headache for some time. I am working
> on an LPC2136 based platform on a project that was developed on
> Rowley Crossworks before me. The platform includes different kind of
> devices such as: serial flash, bluetooth module, LCD graphic display ,
> etc... Last months I moved that code to KEIL development environment.

Some time I also faced strange problem, but then disabling the optimization
solved it.
Warm Regards,

Mukund Deshmukh,
Beta Computronics Pvt Ltd.
10/1 IT Park, Parsodi,
Nagpur -440022 India.
Web site - http://betacomp.com

MEET US AT,

Chinaplas 2008, Shanghai, China.
Hi,
Look out for problems related to time, interrupts and the length of
generated
code by each compiler (use the .map file for that). Anyway, perhaps is
better
to re-write the whole program, instead of debugging an old one.
Ioan.

Aleksandar Zivkovic wrote:
>
> Hello,
> I have a problem that gives me a headache for some time. I am working
> on an LPC2136 based platform on a project that was developed on
> Rowley Crossworks before me. The platform includes different kind of
> devices such as: serial flash, bluetooth module, LCD graphic display ,
> etc... Last months I moved that code to KEIL development environment.I
> was translating C code step by step and at one stage it began to act
> very strange:
> - after some time after power-up it crashes and goes into reset state
> - then I add or remove some C code line and it starts working correctly
> - if I add some new code it acts like before, crashes
>
> I got a feeling that compiler writes over some mem locations,
> therefore I added code protection explained in KEIL web site. I
> thought that Flash Magic I am using puts its 87654321 over some
> program instruction. But it didn't help.
> The strangest thing to me is that changing some unimportant code lines
> (like switching some GPIO pins on and off) affects this dramatic change.
>
> I know that info that I gave to you guys and girls is not enough to
> give me explicit help but if you would give me some advices where to
> start looking for my error source it would be a great!
>
> I am not able to connect JTAG to my platform, but can use UART to
> catch various info...
>
> Thank you in advance!
>
>
At 08:00 PM 2/7/2008 -0800, Mukund Deshmukh wrote:
> > I have a problem that gives me a headache for some time. I am working
> > on an LPC2136 based platform on a project that was developed on
> > Rowley Crossworks before me. The platform includes different kind of
> > devices such as: serial flash, bluetooth module, LCD graphic display ,
> > etc... Last months I moved that code to KEIL development environment.
>
>Some time I also faced strange problem, but then disabling the optimization
>solved it.

Probably not. It probably just masked it. There is a VERY good chance
it'll show up again, probably when you are already struggling with other
issues.

Robert

Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
What happens if you don't use the code protection ?
----- Original Message -----
From: Aleksandar Zivkovic
To: l...
Sent: Thursday, February 07, 2008 6:18 PM
Subject: [lpc2000] LPC2136 big code crash problem
Hello,
I have a problem that gives me a headache for some time. I am working
on an LPC2136 based platform on a project that was developed on
Rowley Crossworks before me. The platform includes different kind of
devices such as: serial flash, bluetooth module, LCD graphic display ,
etc... Last months I moved that code to KEIL development environment.I
was translating C code step by step and at one stage it began to act
very strange:
- after some time after power-up it crashes and goes into reset state
- then I add or remove some C code line and it starts working correctly
- if I add some new code it acts like before, crashes

I got a feeling that compiler writes over some mem locations,
therefore I added code protection explained in KEIL web site. I
thought that Flash Magic I am using puts its 87654321 over some
program instruction. But it didn't help.
The strangest thing to me is that changing some unimportant code lines
(like switching some GPIO pins on and off) affects this dramatic change.

I know that info that I gave to you guys and girls is not enough to
give me explicit help but if you would give me some advices where to
start looking for my error source it would be a great!

I am not able to connect JTAG to my platform, but can use UART to
catch various info...

Thank you in advance!
Hello again,
thank you all for a quick replies. I think your advices could help me
to get out of my problem.
First of all, I agree that debugging an already written code is really
a bad thing but I have a timing issue for my project and I'm seem so
close to find a cause of trouble.It always seems so close...

Robert, thanks for advices! You used a word 'Heisenbug' which I didn't
know what it stands for.And I found some explanation connecting
initialized C variables with this problem.I will double check my
variables for initialization...
I agree that UART usage can add undesirable timings in debugging and I
am already using LED, moving its turn_on statement through the code.
Thanks for a suggestion.

Paul, I'm not sure for what UAH stands for? Maybe you misplaced me
with some other person...

Mukund, I am already at (-O0) optimization level but thanks...

Ioan, I will look at .map files. I think it's a good start. Thanks...
Aleksandar,

> Paul, I'm not sure for what UAH stands for? Maybe you misplaced me
> with some other person...

Ok. Well, perhaps I did. Still, I'm interested to know why the port... :-)

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
> Robert, thanks for advices! You used a word 'Heisenbug' which I didn't
> know what it stands for.

http://en.wikipedia.org/wiki/Uncertainty_principle

.. you cannot observe/trace the bug without changing its position/form
or severity, usually to somewhere outside the scope of your debugging
attempt

Rgds,
Martin

Memfault Beyond the Launch