Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Problem with GNUARM 3.4.3

Problem with GNUARM 3.4.3

2005-02-15 by Anton Erasmus

Hi,

I have installed the latest GNUARM which is based on gcc 3.4.3.
I downloaded the UT040803A.zip uart example from the files
area. 
I compiled and downloaded the code to a LPC2292 board. The code
runs as expected except for one thing. In stead of printing "Hello World!",
it displays garbage.
The main routine is as follows:

int main(void)
{
  uint32_t startTime;

  sysInit();
#if defined(UART0_TX_INT_MODE) || defined(UART0_RX_INT_MODE)
  enableIRQ();
#endif
  startTime = getSysTICs();
  uart0Puts("\r\nHello World!\r\n");

  for (;;)
    {
    do
      {
      int ch;

      if ((ch = uart0Getch()) >= 0)
        uart0Putch(ch);
      }
    while (getElapsedSysTICs(startTime) < HALF_SEC);

    IOPIN ^= LED2_BIT;

    startTime += HALF_SEC;
    }

  return 0;
}

The section after the uart0Puts works. When I press a key on the serial terminal, it is 
echoed correctly back. So it seems that the baud rate etc. is correct. If I compile the 
code with no optimisation  (Default is set to O2), then it prints the "Hello World!" as 
expected. If I add a uart0Putch('U') before the uart0Puts, the U is printed. If I add more, 
then sometimes the "Hello World!" is printed correctly. I have looked in the hex file 
generated, and the ASCII data is put in the .rodata section as expected. It looks as if
the ASCII strings are aligned at 4 byte boundaries, so I do not think it is an alignment 
problem.
Has anyone else had problems with literal strings using gcc 3.4.3 ? Any suggestions on
where I can look to find the problem would be appreciated.

Regards
   Anton Erasmus


-- 
A J Erasmus

Re: [lpc2000] Problem with GNUARM 3.4.3

2005-02-15 by Bill Knight

Anton
  I haven't used 3.4.3 yet so haven't seen this problem.
If anyone else wants to jump in here, please feel free.
I will try to get the new version installed and the code tested
soon.  (Un)fortunately I have several active contracts right
now so don't have much spare time.

Regards
-Bill Knight
R O SOftWare &
http://www.theARMPatch.com


On Tue, 15 Feb 2005 18:53:17 +0200, Anton Erasmus wrote:


Hi,

I have installed the latest GNUARM which is based on gcc 3.4.3.
I downloaded the UT040803A.zip uart example from the files
area. 
I compiled and downloaded the code to a LPC2292 board. The code
runs as expected except for one thing. In stead of printing "Hello World!",
it displays garbage.
The main routine is as follows:

int main(void)

  uint32_t startTime;

  sysInit();
#if defined(UART0_TX_INT_MODE) || defined(UART0_RX_INT_MODE)
  enableIRQ();
#endif
  startTime = getSysTICs();
  uart0Puts("\r\nHello World!\r\n");

  for (;;)
    {
    do
      {
      int ch;

      if ((ch = uart0Getch()) >= 0)
        uart0Putch(ch);
      }
    while (getElapsedSysTICs(startTime) < HALF_SEC);

    IOPIN ^= LED2_BIT;

    startTime += HALF_SEC;
    }

  return 0;


The section after the uart0Puts works. When I press a key on the serial terminal, it is 
echoed correctly back. So it seems that the baud rate etc. is correct. If I compile the 
code with no optimisation  (Default is set to O2), then it prints the "Hello World!" as 
expected. If I add a uart0Putch('U') before the uart0Puts, the U is printed. If I add more, 
then sometimes the "Hello World!" is printed correctly. I have looked in the hex file 
generated, and the ASCII data is put in the .rodata section as expected. It looks as if
the ASCII strings are aligned at 4 byte boundaries, so I do not think it is an alignment 
problem.
Has anyone else had problems with literal strings using gcc 3.4.3 ? Any suggestions on
where I can look to find the problem would be appreciated.

Regards
   Anton Erasmus


-- 
A J Erasmus




Yahoo! Groups Links

Re: [lpc2000] Problem with GNUARM 3.4.3

2005-02-15 by Robert Adsett

At 06:53 PM 2/15/05 +0200, Anton Erasmus wrote:
>IThe section after the uart0Puts works. When I press a key on the serial 
>terminal, it is
>echoed correctly back. So it seems that the baud rate etc. is correct. If 
>I compile the
>code with no optimisation  (Default is set to O2), then it prints the 
>"Hello World!" as
>expected. If I add a uart0Putch('U') before the uart0Puts, the U is 
>printed. If I add more,
>then sometimes the "Hello World!" is printed correctly. I have looked in 
>the hex file
>generated, and the ASCII data is put in the .rodata section as expected. 
>It looks as if
>the ASCII strings are aligned at 4 byte boundaries, so I do not think it 
>is an alignment
>problem.
>Has anyone else had problems with literal strings using gcc 3.4.3 ? Any 
>suggestions on
>where I can look to find the problem would be appreciated.


Just a thought (I haven't tested 3.4.3) but this looks what you would 
expect if constant data wasn't being referenced correctly.  IE ld was 
placing the data in flash and expecting it to be copied to RAM (and the 
startup wasn't expecting the constant area to have to move).  Have you 
checked your link script?

Of course that leads to the question of why the link script changed, but I 
can see misplacing it.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Re: [lpc2000] Problem with GNUARM 3.4.3

2005-02-15 by Anton Erasmus

On 15 Feb 2005 at 13:50, Robert Adsett wrote:

> 
> At 06:53 PM 2/15/05 +0200, Anton Erasmus wrote:
> >IThe section after the uart0Puts works. When I press a key on the
> >serial terminal, it is echoed correctly back. So it seems that the
> >baud rate etc. is correct. If I compile the code with no optimisation
> > (Default is set to O2), then it prints the "Hello World!" as
> >expected. If I add a uart0Putch('U') before the uart0Puts, the U is
> >printed. If I add more, then sometimes the "Hello World!" is printed
> >correctly. I have looked in the hex file generated, and the ASCII
> >data is put in the .rodata section as expected. It looks as if the
> >ASCII strings are aligned at 4 byte boundaries, so I do not think it
> >is an alignment problem. Has anyone else had problems with literal
> >strings using gcc 3.4.3 ? Any suggestions on where I can look to find
> >the problem would be appreciated.
> 
> 
> Just a thought (I haven't tested 3.4.3) but this looks what you would
> expect if constant data wasn't being referenced correctly.  IE ld was
> placing the data in flash and expecting it to be copied to RAM (and
> the startup wasn't expecting the constant area to have to move).  Have
> you checked your link script?
> 
> Of course that leads to the question of why the link script changed,
> but I can see misplacing it.
> 

I am using the linker script supplied with the example code. The assembly code looks
fine for all optimisation levels. The ASCII data is defined and put in the .rodata section
which is placed in the text section just after the code. The assembly is typically:

  ldr r0, =LC0

with LC0 being the label of a word.

LC0 .word  LC1

where LC1 being the label of the ASCII data.

The ldr pseudo instruction is then transformed into a number of instructions.
Unfortunately I do not have JTAG debug capability at the moment, so it is a bit 
difficult to see what the actual run-time calculation is. The dissasembler is also not
smart enough to spot references to defined word such as at the LC0 label, but tries to
dissasemble the value. It does not look as if the .rodata section should be copied to 
RAM for it to work. Also the fact that it works correctly with no optimisation. If it was a 
problem with data not being copied to RAM when it should be, then I would expect it to
fail with no optimisation as well. I am beginning to suspect that the conversion of the ldr
pseudo instruction to actual code might be incorrect. AFAIK the compiler will try and
calculate the address, and only if it cannot do so actually read the address from a
defined word with a PC relative load. It might be that it is failing when it can calculate
the address. Anybody here know what the assembler actually does  with a ldr pseudo
instruction ?

Regards
  Anton Erasmus


-- 
A J Erasmus

Re: Problem with GNUARM 3.4.3

2005-02-15 by Rick Collins

Why don't you ask this in the gnuarm group?  

http://groups.yahoo.com/group/gnuarm

There are tons of good people who can likely answer your question. 

Also, I am curious, which web site did you use to download the code? 
Did you do your own compile of the tools?  


--- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote:
> Hi,
> 
> I have installed the latest GNUARM which is based on gcc 3.4.3.
> I downloaded the UT040803A.zip uart example from the files
> area. 
> I compiled and downloaded the code to a LPC2292 board. The code
> runs as expected except for one thing. In stead of printing "Hello
World!",
> it displays garbage.
> The main routine is as follows:
> 
> int main(void)
> {
>   uint32_t startTime;
> 
>   sysInit();
> #if defined(UART0_TX_INT_MODE) || defined(UART0_RX_INT_MODE)
>   enableIRQ();
> #endif
>   startTime = getSysTICs();
>   uart0Puts("\r\nHello World!\r\n");
> 
>   for (;;)
>     {
>     do
>       {
>       int ch;
> 
>       if ((ch = uart0Getch()) >= 0)
>         uart0Putch(ch);
>       }
>     while (getElapsedSysTICs(startTime) < HALF_SEC);
> 
>     IOPIN ^= LED2_BIT;
> 
>     startTime += HALF_SEC;
>     }
> 
>   return 0;
> }
> 
> The section after the uart0Puts works. When I press a key on the
serial terminal, it is 
> echoed correctly back. So it seems that the baud rate etc. is
correct. If I compile the 
> code with no optimisation  (Default is set to O2), then it prints
the "Hello World!" as 
> expected. If I add a uart0Putch('U') before the uart0Puts, the U is
printed. If I add more, 
> then sometimes the "Hello World!" is printed correctly. I have
looked in the hex file 
> generated, and the ASCII data is put in the .rodata section as
expected. It looks as if
> the ASCII strings are aligned at 4 byte boundaries, so I do not
think it is an alignment 
> problem.
> Has anyone else had problems with literal strings using gcc 3.4.3 ?
Any suggestions on
Show quoted textHide quoted text
> where I can look to find the problem would be appreciated.
> 
> Regards
>    Anton Erasmus
> 
> 
> -- 
> A J Erasmus

Re: [lpc2000] Problem with GNUARM 3.4.3

2005-02-15 by Robert Adsett

At 09:53 PM 2/15/05 +0200, Anton Erasmus wrote:
>On 15 Feb 2005 at 13:50, Robert Adsett wrote:
> > Just a thought (I haven't tested 3.4.3) but this looks what you would
> > expect if constant data wasn't being referenced correctly.  IE ld was
> > placing the data in flash and expecting it to be copied to RAM (and
> > the startup wasn't expecting the constant area to have to move).  Have
> > you checked your link script?
>Also the fact that it works correctly with no optimisation. If it was a
>problem with data not being copied to RAM when it should be, then I would 
>expect it to
>fail with no optimisation as well.

Very good point.

I think Rick's suggestion of asking the GNUARM group is probably a good one.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Re: [lpc2000] Re: Problem with GNUARM 3.4.3

2005-02-15 by Anton Erasmus

On 15 Feb 2005 at 20:02, Rick Collins wrote:

> 
> 
> Why don't you ask this in the gnuarm group?  
> 
> http://groups.yahoo.com/group/gnuarm
> 
> There are tons of good people who can likely answer your question. 

I am not sure if it is an actual compiler problem, and not some linker script 
problem or some other finger problem. Since the example code is LPC
specific, I thought others might have compiled it succesfully with gcc 3.4.3.
If it is not some LPC specific problem, I will ask in the gnuarm group.


> Also, I am curious, which web site did you use to download the code?
> Did you do your own compile of the tools?  

I used the binary tools from http://www.gnuarm.com. Both the Windows/cygwin
binary and the linux binary. I also built the compiler using the script and sources
from Rod Moffitt's site. The problem is the same, both when compiled as ARM
only code and ARM/THUMB code. 

Regards
   Anton Erasmus

> 
> --- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote: >
> Hi, > > I have installed the latest GNUARM which is based on gcc
> 3.4.3. > I downloaded the UT040803A.zip uart example from the files >
> area. > I compiled and downloaded the code to a LPC2292 board. The
> code > runs as expected except for one thing. In stead of printing
> "Hello World!", > it displays garbage. > The main routine is as
> follows: > > int main(void) > { >   uint32_t startTime; > >  
> sysInit(); > #if defined(UART0_TX_INT_MODE) ||
> defined(UART0_RX_INT_MODE) >   enableIRQ(); > #endif >   startTime =
> getSysTICs(); >   uart0Puts("\r\nHello World!\r\n"); > >   for (;;) > 
>    { >     do >       { >       int ch; > >       if ((ch =
> uart0Getch()) >= 0) >         uart0Putch(ch); >       } >     while
> (getElapsedSysTICs(startTime) < HALF_SEC); > >     IOPIN ^= LED2_BIT;
> > >     startTime += HALF_SEC; >     } > >   return 0; > } > > The
> section after the uart0Puts works. When I press a key on the serial
> terminal, it is > echoed correctly back. So it seems that the baud
> rate etc. is correct. If I compile the > code with no optimisation 
> (Default is set to O2), then it prints the "Hello World!" as >
> expected. If I add a uart0Putch('U') before the uart0Puts, the U is
> printed. If I add more, > then sometimes the "Hello World!" is printed
> correctly. I have looked in the hex file > generated, and the ASCII
> data is put in the .rodata section as expected. It looks as if > the
> ASCII strings are aligned at 4 byte boundaries, so I do not think it
> is an alignment > problem. > Has anyone else had problems with literal
> strings using gcc 3.4.3 ? Any suggestions on > where I can look to
> find the problem would be appreciated. > > Regards >    Anton Erasmus
> > > > -- > A J Erasmus
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
> 

-- 
A J Erasmus

Re: [lpc2000] Re: Problem with GNUARM 3.4.3

2005-02-16 by Anton Erasmus

I have now investigated further and it looks like a start-up problem.
I noticed that the number of rubbish characters sent was the number
of characters in the actual string. The uart0Puts routine outputs until a
0 is reached, hence if the pointer to the data was corrupted, then the
chances that it outputs the same number of characters are extremely
unlikely. When I changed the main routine to the following:

void foo(void)
{
  uart0Puts("\r\nHello World!\r\n");
}

int main(void)
{
  uint32_t startTime;

  sysInit();
#if defined(UART0_TX_INT_MODE) || defined(UART0_RX_INT_MODE)
  enableIRQ();
#endif
  startTime = getSysTICs();
  foo();

  for (;;)
    {
    do
      {
      int ch;

      if ((ch = uart0Getch()) >= 0)
      {
        if(ch=='~')
          foo();
        uart0Putch(ch);
      }
      }
    while (getElapsedSysTICs(startTime) < HALF_SEC);

    IOPIN ^= LED2_BIT;

    startTime += HALF_SEC;
    }

  return 0;
}

The first time foo() is called I get garbage out - although the right number of chars.
When I press ~, the right string is displayed every time. It looks like the PLL might not 
have locked properly or something else is causing the baudrate to be incorrect at 
startup. My circuit uses an external 14.7456MHz crystal oscillator as the clock source.
Using the PLL, I set the CPU clock to 58.9824MHz.

Regards
   Anton Erasmus



On 15 Feb 2005 at 23:29, Anton Erasmus wrote:

> 
> On 15 Feb 2005 at 20:02, Rick Collins wrote:
> 
> > 
> > 
> > Why don't you ask this in the gnuarm group?  
> > 
> > http://groups.yahoo.com/group/gnuarm
> > 
> > There are tons of good people who can likely answer your question. 
> 
> I am not sure if it is an actual compiler problem, and not some linker
> script problem or some other finger problem. Since the example code is
> LPC specific, I thought others might have compiled it succesfully with
> gcc 3.4.3. If it is not some LPC specific problem, I will ask in the
> gnuarm group.
> 
> 
> > Also, I am curious, which web site did you use to download the code?
> > Did you do your own compile of the tools?  
> 
> I used the binary tools from http://www.gnuarm.com. Both the
> Windows/cygwin binary and the linux binary. I also built the compiler
> using the script and sources from Rod Moffitt's site. The problem is
> the same, both when compiled as ARM only code and ARM/THUMB code. 
> 
> Regards
>    Anton Erasmus
> 
> > 
> > --- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote:
> > > Hi, > > I have installed the latest GNUARM which is based on gcc
> > 3.4.3. > I downloaded the UT040803A.zip uart example from the files
> > > area. > I compiled and downloaded the code to a LPC2292 board. The
> > code > runs as expected except for one thing. In stead of printing
> > "Hello World!", > it displays garbage. > The main routine is as
> > follows: > > int main(void) > { >   uint32_t startTime; > > 
> > sysInit(); > #if defined(UART0_TX_INT_MODE) ||
> > defined(UART0_RX_INT_MODE) >   enableIRQ(); > #endif >   startTime =
> > getSysTICs(); >   uart0Puts("\r\nHello World!\r\n"); > >   for (;;)
> > > 
> >    { >     do >       { >       int ch; > >       if ((ch =
> > uart0Getch()) >= 0) >         uart0Putch(ch); >       } >     while
> > (getElapsedSysTICs(startTime) < HALF_SEC); > >     IOPIN ^=
> > LED2_BIT;
> > > >     startTime += HALF_SEC; >     } > >   return 0; > } > > The
> > section after the uart0Puts works. When I press a key on the serial
> > terminal, it is > echoed correctly back. So it seems that the baud
> > rate etc. is correct. If I compile the > code with no optimisation
> > (Default is set to O2), then it prints the "Hello World!" as >
> > expected. If I add a uart0Putch('U') before the uart0Puts, the U is
> > printed. If I add more, > then sometimes the "Hello World!" is
> > printed correctly. I have looked in the hex file > generated, and
> > the ASCII data is put in the .rodata section as expected. It looks
> > as if > the ASCII strings are aligned at 4 byte boundaries, so I do
> > not think it is an alignment > problem. > Has anyone else had
> > problems with literal strings using gcc 3.4.3 ? Any suggestions on >
> > where I can look to find the problem would be appreciated. > >
> > Regards >    Anton Erasmus
> > > > > -- > A J Erasmus
> > 
> > 
> > 
> > 
> > 
> > 
> > Yahoo! Groups Links
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> A J Erasmus
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
> 

-- 
A J Erasmus

Re: Problem with GNUARM 3.4.3

2005-02-16 by Rick Collins

--- In lpc2000@yahoogroups.com, "Anton Erasmus" <antone@s...> wrote:
> I have now investigated further and it looks like a start-up
problem.
> I noticed that the number of rubbish characters sent was the number
> of characters in the actual string. The uart0Puts routine outputs
until a
> 0 is reached, hence if the pointer to the data was corrupted, then
the
> chances that it outputs the same number of characters are extremely
> unlikely. When I changed the main routine to the following:
> 
> void foo(void)
> {
>   uart0Puts("\r\nHello World!\r\n");
> }
> 
> int main(void)
> {
>   uint32_t startTime;
> 
>   sysInit();
> #if defined(UART0_TX_INT_MODE) || defined(UART0_RX_INT_MODE)
>   enableIRQ();
> #endif
>   startTime = getSysTICs();
>   foo();
> 
>   for (;;)
>     {
>     do
>       {
>       int ch;
> 
>       if ((ch = uart0Getch()) >= 0)
>       {
>         if(ch=='~')
>           foo();
>         uart0Putch(ch);
>       }
>       }
>     while (getElapsedSysTICs(startTime) < HALF_SEC);
> 
>     IOPIN ^= LED2_BIT;
> 
>     startTime += HALF_SEC;
>     }
> 
>   return 0;
> }
> 
> The first time foo() is called I get garbage out - although the
right number of chars.
> When I press ~, the right string is displayed every time. It looks
like the PLL might not 
> have locked properly or something else is causing the baudrate to be
incorrect at 
> startup. My circuit uses an external 14.7456MHz crystal oscillator
as the clock source.
> Using the PLL, I set the CPU clock to 58.9824MHz.

You can distinguish between a problem that requires time to fix it,
like a xtal startup time and an initialization problem by adding a
startup delay.  If this fixed the problem, you have something wrong
that fixes itself with time.  

I will say that a wrong baud rate is unlikely to result in the correct
number of characters.  Normally a baud rate that is off enough to
garble the characters will give you more or fewer characters as well.
 

So my guess is that something in the code is not initialized correctly
and gets fixed after some data is run through the port. 
 Very possibly a problem with passing a data pointer.  This may happen
after the character is checked for null, so it gets the count
correct.  

Another way to easily distinguish the two is to call foo() twice.  If
the second call is output corectly, then there is clearly an init
problem.

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.