EmbeddedRelated.com
Forums
Memfault Beyond the Launch

LPC2368 and LCD display, strange behaviour when main code is relocated

Started by Gabriele May 24, 2013
Hello everyone,

I'm writing code for an LPC2368 where I'm using SD card file system in order to load the new firmware when needed.

I'm following the indication reported in the application note 10835 from NXP and I'm able to load and update the code.

My Board use a 6963LCD plus a 4W touchScreen as input panel.

I'm experiencing a strange behaviour when I run my relocated code.
The LCD shows a random pints on one line and every time the LCD is updated this line change pattern.

Beside this problem, the code is working perfectly without any issue, I can debug etc.

If I build my project avoiding to use the secondary bootloader, so starting it from 0x0000, the display does not show this problem and again all the functionalities are working perfectly.

I suppose (but let me say that I'm not a FW designer) that this issue can be generated by some variable that corrupt some portion of the RAM where also the display is getting/saving data.

If you have any suggestion on how to solve this problem is welcomed.

Thanks in advance for your time.
rgds
Gabriele

An Engineer's Guide to the LPC2100 Series

P
lease, can you check what is the CPU mode that is left by the bootloader
startup?

What happens is that the bootloader calls the main firmware after setting
up the stack pointers for each mode which includes leaving the supervisor
mode, once this mode is left, the stacks will never be able to be reset
again. In such a case, the main firmware will not be able to re-setup the
stack pointer as it is supposed to and so, you will have the stack
overriding you data. The symptoms you will notice is your buffers being
changed randomly and cpu calling the error handlers (or system freezing if
you haven't setup custom handlers).

The workarounds are:

1) Change your bootloader to never leave the supervisor mode.
2) (NOT RECOMENDED) Sync the stack of all your firmwares to be the exact
same.
2013/5/24 Gabriele

> **
> Hello everyone,
>
> I'm writing code for an LPC2368 where I'm using SD card file system in
> order to load the new firmware when needed.
>
> I'm following the indication reported in the application note 10835 from
> NXP and I'm able to load and update the code.
>
> My Board use a 6963LCD plus a 4W touchScreen as input panel.
>
> I'm experiencing a strange behaviour when I run my relocated code.
> The LCD shows a random pints on one line and every time the LCD is updated
> this line change pattern.
>
> Beside this problem, the code is working perfectly without any issue, I
> can debug etc.
>
> If I build my project avoiding to use the secondary bootloader, so
> starting it from 0x0000, the display does not show this problem and again
> all the functionalities are working perfectly.
>
> I suppose (but let me say that I'm not a FW designer) that this issue can
> be generated by some variable that corrupt some portion of the RAM where
> also the display is getting/saving data.
>
> If you have any suggestion on how to solve this problem is welcomed.
>
> Thanks in advance for your time.
> rgds
> Gabriele
>
>
>


Hello,

thanks for your reply, can you explain me, or redirect me somewhere, un order to know how to do this?

"1) Change your bootloader to never leave the supervisor mode."

Thanks in advance
rgds
Gabriele
--- In l..., Felipe de Andrade Neves Lavratti wrote:
>
> P
> lease, can you check what is the CPU mode that is left by the bootloader
> startup?
>
> What happens is that the bootloader calls the main firmware after setting
> up the stack pointers for each mode which includes leaving the supervisor
> mode, once this mode is left, the stacks will never be able to be reset
> again. In such a case, the main firmware will not be able to re-setup the
> stack pointer as it is supposed to and so, you will have the stack
> overriding you data. The symptoms you will notice is your buffers being
> changed randomly and cpu calling the error handlers (or system freezing if
> you haven't setup custom handlers).
>
> The workarounds are:
>
> 1) Change your bootloader to never leave the supervisor mode.
> 2) (NOT RECOMENDED) Sync the stack of all your firmwares to be the exact
> same.
> 2013/5/24 Gabriele > **
> >
> >
> > Hello everyone,
> >
> > I'm writing code for an LPC2368 where I'm using SD card file system in
> > order to load the new firmware when needed.
> >
> > I'm following the indication reported in the application note 10835 from
> > NXP and I'm able to load and update the code.
> >
> > My Board use a 6963LCD plus a 4W touchScreen as input panel.
> >
> > I'm experiencing a strange behaviour when I run my relocated code.
> > The LCD shows a random pints on one line and every time the LCD is updated
> > this line change pattern.
> >
> > Beside this problem, the code is working perfectly without any issue, I
> > can debug etc.
> >
> > If I build my project avoiding to use the secondary bootloader, so
> > starting it from 0x0000, the display does not show this problem and again
> > all the functionalities are working perfectly.
> >
> > I suppose (but let me say that I'm not a FW designer) that this issue can
> > be generated by some variable that corrupt some portion of the RAM where
> > also the display is getting/saving data.
> >
> > If you have any suggestion on how to solve this problem is welcomed.
> >
> > Thanks in advance for your time.
> > rgds
> > Gabriele
> >
> >
> >
>
>

Gabriele,
First we should check if the problem is the one I mentioned. Can you please
post the .map files of your both firmwares ( bootloader & main)?

Att
Em 25/05/2013 03:29, "Gabriele" escreveu:

> **
> Hello,
>
> thanks for your reply, can you explain me, or redirect me somewhere, un
> order to know how to do this?
>
> "1) Change your bootloader to never leave the supervisor mode."
>
> Thanks in advance
> rgds
> Gabriele
>
> --- In l..., Felipe de Andrade Neves Lavratti
> wrote:
> >
> > P
> > lease, can you check what is the CPU mode that is left by the bootloader
> > startup?
> >
> > What happens is that the bootloader calls the main firmware after setting
> > up the stack pointers for each mode which includes leaving the supervisor
> > mode, once this mode is left, the stacks will never be able to be reset
> > again. In such a case, the main firmware will not be able to re-setup the
> > stack pointer as it is supposed to and so, you will have the stack
> > overriding you data. The symptoms you will notice is your buffers being
> > changed randomly and cpu calling the error handlers (or system freezing
> if
> > you haven't setup custom handlers).
> >
> > The workarounds are:
> >
> > 1) Change your bootloader to never leave the supervisor mode.
> > 2) (NOT RECOMENDED) Sync the stack of all your firmwares to be the exact
> > same.
> >
> >
> > 2013/5/24 Gabriele
> >
> > > **
> > >
> > >
> > > Hello everyone,
> > >
> > > I'm writing code for an LPC2368 where I'm using SD card file system in
> > > order to load the new firmware when needed.
> > >
> > > I'm following the indication reported in the application note 10835
> from
> > > NXP and I'm able to load and update the code.
> > >
> > > My Board use a 6963LCD plus a 4W touchScreen as input panel.
> > >
> > > I'm experiencing a strange behaviour when I run my relocated code.
> > > The LCD shows a random pints on one line and every time the LCD is
> updated
> > > this line change pattern.
> > >
> > > Beside this problem, the code is working perfectly without any issue, I
> > > can debug etc.
> > >
> > > If I build my project avoiding to use the secondary bootloader, so
> > > starting it from 0x0000, the display does not show this problem and
> again
> > > all the functionalities are working perfectly.
> > >
> > > I suppose (but let me say that I'm not a FW designer) that this issue
> can
> > > be generated by some variable that corrupt some portion of the RAM
> where
> > > also the display is getting/saving data.
> > >
> > > If you have any suggestion on how to solve this problem is welcomed.
> > >
> > > Thanks in advance for your time.
> > > rgds
> > > Gabriele
> > >
> > >
> > >
> >
> >
> >
> >
>



Memfault Beyond the Launch