EmbDev.net

Forum: ARM programming with GCC/GNU tools Bug using STR711F


von Bruno A. (bvadorno)


Rate this post
useful
not useful
Hi everybody,

   I'm using a development board from Olimex (STR-H 711) and i am having
a strange behavior: when I use the code below, everything goes fine, but
when I comment UART_ByteSend(UART0, &bRByte) in else statement, the
compiler generates code without error, but it simply doesn't run.

With the line uncommented, the program works only with optimization s.
With optimization 0, the program doesn't work. Does anybody knows why
this occurs?

Thanks,
Bruno


The simple code:


void UART1_IRQHandler(void)
{
  u8 bRByte;

  /*  Get the received byte, set the guard time to 0xFF */
  UART_ByteReceive(UART1, &bRByte, 0xFF);

  /*  Send the received byte */
   if(bRByte == 'H')
   {
     bRByte = 'Y';
    UART_ByteSend(UART0, &bRByte);
  }
  else
   {
     bRByte = 'N';
     UART_ByteSend(UART0, &bRByte); //line to be commented
   }
}

von Bruno A. (bvadorno)


Rate this post
useful
not useful
I think that is some problem with interrupts. When I work without
interruptions in a simple program that only blink leds, all goes fine
with optimization level 0. But when i add three uarts, the program works
only with optimization 's'. Maybe is some problem with the stack?

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
Bruno Adorno wrote:
> I think that is some problem with interrupts. When I work without
> interruptions in a simple program that only blink leds, all goes fine
> with optimization level 0. But when i add three uarts, the program works
> only with optimization 's'. Maybe is some problem with the stack?

Maybe the stack size for IRQ-Mode is too small but since you do not use
an "attribute" for your ISR I expect some Assembler-Wrapper gets used
and it's difficult to help without looking into the startup-code,
interrupt-handling-code and linker-script. More information needed.
Please create a minimal example-application with all needed files to
reproduce the problem, pack it into a zip-archive and attach it to a
forum-post.

Martin Thomas

von Bruno A. (bvadorno)


Attached files:

Rate this post
useful
not useful
> Maybe the stack size for IRQ-Mode is too small but since you do not use
> an "attribute" for your ISR I expect some Assembler-Wrapper gets used
> and it's difficult to help without looking into the startup-code,
> interrupt-handling-code and linker-script. More information needed.
> Please create a minimal example-application with all needed files to
> reproduce the problem, pack it into a zip-archive and attach it to a
> forum-post.
>
> Martin Thomas

Thanks for the response, Martin. I sent a minimal example that uses
UART0. Compiling with 's' optimization, when the UART0 receives '@' or
'#', the ARM answer to terminal with a message in both cases. But when
the optimization flag is '0', when the ARM receives only '@', everything
is ok and he is able to send back a message, but when it receives '#' it
simply stops sending messages back to the terminal.

Thanks in advance,
Bruno Vilhena Adorno

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
Bruno Adorno wrote:
>> Maybe the stack size for IRQ-Mode is too small but since you do not use
>> an "attribute" for your ISR I expect some Assembler-Wrapper gets used
>> and it's difficult to help without looking into the startup-code,
>> interrupt-handling-code and linker-script. More information needed.
>> Please create a minimal example-application with all needed files to
>> reproduce the problem, pack it into a zip-archive and attach it to a
>> forum-post.
>>
>> Martin Thomas
>
> Thanks for the response, Martin. I sent a minimal example that uses
> UART0. Compiling with 's' optimization, when the UART0 receives '@' or
> '#', the ARM answer to terminal with a message in both cases. But when
> the optimization flag is '0', when the ARM receives only '@', everything
> is ok and he is able to send back a message, but when it receives '#' it
> simply stops sending messages back to the terminal.

Sorry, so far I did not have time to take a closer look into the code
and test it with my STR710-hardware or a simulator.
It may no be related to the optimization on/off-problem but it's not a
good idea to call the "UARTSend" Function from inside the UART-ISR.
AFAIK the function from the STR71x-library uses a simple polling
approach which waits until sending is possible (space in FIFO or
transmit register free). Maybe this is a source of other side-effects
which result in the failure when optimization is disabled. Better try to
use a global variable (remember volatile) to flag that the char has been
received inside the ISR, send the answer from outside the
interrupt-handler ("main loop") if the flag is set and reset the flag
afterwards.

Martin Thomas

von Bruno A. (bvadorno)


Rate this post
useful
not useful
> Sorry, so far I did not have time to take a closer look into the code
> and test it with my STR710-hardware or a simulator.
> It may no be related to the optimization on/off-problem but it's not a
> good idea to call the "UARTSend" Function from inside the UART-ISR.
> AFAIK the function from the STR71x-library uses a simple polling
> approach which waits until sending is possible (space in FIFO or
> transmit register free). Maybe this is a source of other side-effects
> which result in the failure when optimization is disabled. Better try to
> use a global variable (remember volatile) to flag that the char has been
> received inside the ISR, send the answer from outside the
> interrupt-handler ("main loop") if the flag is set and reset the flag
> afterwards.
>
> Martin Thomas

I think you are right. I removed all the code that uses the polling
scheme inside interrupt and it worked. But now the code is growing and I
am worried about its reliability =).

Thanks,
Bruno Vilhena Adorno

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
Bruno Adorno wrote:
>> Sorry, so far I did not have time to take a closer look into the code
>> and test it with my STR710-hardware or a simulator.
>> It may no be related to the optimization on/off-problem but it's not a
>> good idea to call the "UARTSend" Function from inside the UART-ISR.
>> AFAIK the function from the STR71x-library uses a simple polling
>> approach which waits until sending is possible (space in FIFO or
>> transmit register free). Maybe this is a source of other side-effects
>> which result in the failure when optimization is disabled. Better try to
>> use a global variable (remember volatile) to flag that the char has been
>> received inside the ISR, send the answer from outside the
>> interrupt-handler ("main loop") if the flag is set and reset the flag
>> afterwards.
>>
>> Martin Thomas
>
> I think you are right. I removed all the code that uses the polling
> scheme inside interrupt and it worked. But now the code is growing and I
> am worried about its reliability =).

Maybe this is all well known to you, but anyway:
In general it's a good idea to buffer "unrequested" data like i.e.
characters received by UART. The usual approach is to use a FIFO-buffer
where the UART RX-ISR adds incoming data to the Buffer and the main-code
reads from it later on. With such an approach you have some time in the
main-loop for time-consuming processing without worring about loosing
incoming data. The FIFO must be large enough to hold all data that has
been received before they can be picked up by the main-process to avoid
buffer-overruns. IRC the STR71x have build-in 16 word fifos for the
UARTs which may be large enough but this depends on the rest of the
applicaiton. If not: implementing an "UART-FIFO" in software is not too
difficult since a lot of example-code is already available which can be
ported. Maybe there are even ready-made codes for STR71x.


Martin Thomas

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.