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
}
}
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?
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
> 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
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
> 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
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
Watch this topic
Disable multi-page viewPlease 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
Log in with Google account
No account? Register here.