Hello,
I work with the AT91RM9200.
I have some problems with the retarget-function for the implementation of printf. It works but sometimes I get a data abort - maybe if the buffer for printf function is too small???
that's my function to transmit printf messages to the usart
int COM1_1_sendchar(int ch) { if (ch == '\n') { /* Check for CR */ while (!(COM1_1->US_CSR & AT91C_US_TXRDY)); /* Wait for Empty Tx Buffer */ // COM1_1->US_THR = '\r'; /* Output CR */ AT91F_US_PutChar (COM1_1,'\r'); } while (!(COM1_1->US_CSR & AT91C_US_TXRDY)); /* Wait for Empty Tx Buffer */ return (COM1_1->US_THR = ch); /* Transmit Character */ }
retarget.c
#include <stdio.h> #include <rt_misc.h> #include <AT91RM9200.H> #pragma import(__use_no_semihosting_swi) extern int COM1_1_sendchar (int ch); /* in usart.c */ struct __FILE { int handle; /* Add whatever you need here */ }; FILE __stdout; FILE __stdin; int fputc(int ch, FILE *f) { return (COM1_1_sendchar(ch)); } int ferror(FILE *f) { /* Your implementation of ferror */ return EOF; } void _ttywrch(int ch) { COM1_1_sendchar(ch); } void _sys_exit(int return_code) { label: goto label; /* endless loop */ }
I hope somebody have a idea - because the problem with the data abort is not always but very often
best regards Johannes
the baudrate for the usart is 115200 - so it is not slow.
I have one printf() in a function, which is called three times. And I often have the problem, that the hyperterminal only shows "HellHello World" or something which is similar...
so I get a data abort - and when I look which line occured this dara abort - it's very often the line COM1_1->US_THR = '\r'; after the first if question...
could there be another problem with my programm? like a storage problem?
Johannes
Why didn't you specify that error before?
Are all your printouts using printf, or do you have any other places where you print? Do you have any code that changes baudrate, timing or similar?
This line is responsible for printf() waiting until the serial port can handle more data:
while (!(COM1_1->US_CSR & AT91C_US_TXRDY));
However, if that line is wrong, you would not just loose the last part of a printout. You would loose characters in the middle too.
The most common reason for your error is if you put trace output in an interrupt handler.
I only use printf() to show some messages via the usart1 - I never change the settings of the usart...
I don't know why this line should be false?
"The most common reason for your error is if you put trace output in an interrupt handler."
ok, that's interesting. I have one printf() function in a ISR. That means, the ISR is closed before the printf() function has transmitted all values via the usart port - and that could be the problem? But is a data abort the logic effect of this?
That means, the ISR is closed before the printf() function has transmitted all values via the usart port
No, that means that the interrupt routine does not wait for any already ongoing printouts.
Stay away from printing in your ISR. You want an ISR to be fast - not having to wait until the UART has room for your characters. At your baudrate, your ISR will waste about 0.1ms for each character in the printout.
I have one printf() function in a ISR.
That's very bad indeed. Calling printf() or one of its close relatives is just about the last thing you should ever consider doing in an ISR.
As a rule of thumb, don't call any functions from an ISR. If the job at hand is complex enough that you feel an urge to split it into more than one function, it's probably not a job fit to be done by an ISR.