Hello,
I've problems with the printf() routine. I receive frames over the ethernet in a very short intervall. If I received a frame I set a flag in the ISR.
void ethernet_interrupt(void) __irq { unsigned int status; AT91PS_EMAC pEmac = AT91C_BASE_EMAC; status = pEmac->EMAC_ISR; if (status & AT91C_EMAC_RCOM) /* Receive complete */ Emac_Receive++; // clear receive status register pEmac->EMAC_RSR &= ~(AT91C_EMAC_OVR | AT91C_EMAC_REC | AT91C_EMAC_BNA); AT91C_BASE_AIC->AIC_EOICR = 0; /* End of ISR */ }
In the main routine I ask if the flag is set -> if it is set, I use printf() to see via the usart that I get a new frame...
printf("h");
The problem is that I always get a data abort within the printf() routine..
Could it be that the ethernet frames came to close together (in a short time) so that the printf() routine has not finish to transmit the last character?
And after the ISR the printf() routine don't know what to do / what to send -> data abort??
If the printf-argument is much bigger - it is often so that I only can transmit one or two letter - but not the whole word...
e.g.
printf("hello world\n");
I only transmit "hel" - that's all...
best regards Johannes
now I reach the point that the ptr is invalid
int COM1_1_sendchar(int ch) { unsigned int i=0; if (ch == '\n') { /* Check for CR */ while (!(COM1_1->US_CSR & AT91C_US_TXRDY)) /* Wait for Empty Tx Buffer */ { if (COM1_1 != AT91C_BASE_US1) { i++; } COM1_1->US_THR = '\r'; }
But how can I see which instructions caused this data abort
R14(LR) 0x10000898 -> I type into the output window u 0x10000890 -->
int fputc(int ch. FILE *f) { return (COM1_1_sendchar(ch)); data abort --> //
0x10000890 E1A00004 MOV R0, R4
Johannes
If your ARM supports a data-change breakpoint, then set such a breakpoint on the pointer and then run the program.
If it doesn't, then you have to figure this out manually. Is the pointer a global variable? Are there any array variables with lower address, so that a overrun will kill following variables?
Where is the stack in relation to this pointer? WÃll the stack grow into your variables?
Add test code to verify your pointer at a number of places in your program and run. Can you figure out that it always gets destroyed between two points, then narrow it down.
Or, it may be an interrupt handler that breaks it.
In other worlds, normal elbow grease...
Your goal is to figure out why your pointer is invalid, not where the data abort happens.
You don't care about which instruction that generates a data abort, since you already know that the data abort is caused by an invalid pointer. In short: Valid code is more or less expected to generate a data abort if you fail to fulfill the required preconditions.
View all questions in Keil forum