Now I made more tests and it turns out to be the worst case, it could be:
The (whole) system is no more running, if I enable USART transmit interrupt!
What I did on testing:
I placed some LEDs at port Pins showing the run state of the system. A counter variable is incremented and every (% 10, % 100, and % 1000) an accordingly LED is complemented. With a delay(1) in the main loop, I have now 3 LEDs blinking every 2, 0.2 and 0.02 seconds. This works fine and shows, that main loop is running.
Now I change only one thing: I enable the transmit interrupt of USART3, nothing else.
And then starting again, but the LEDs stay quite. So main loop is not called any more, the system is dead.
What could that be?
I thought again about the cortex_handlers with their __halt default. Could it be, that there is a mistake with the default transmit interrupt handler and it runs on __halt ? (Though I do not send any character till now, might be a ghost interrupt.)
So I added such a heartbeat showing function with (other) LEDs also into the _halt-function of the cortex_handlers in
But they also stay quite.
I repeat, it is the same behaviour, if I enable the transmit interrupt in the given USARTClass of Arduino library.
For me, it now looks like a severe bug at the SAM3 microcontroller or at least some wrong explanations in the SAM3 data book (I am using ATMEL, AT91SAM ARM-based Flash MCU, SAM3X SAM3A Series, 11057B-ATARM-28-May-12, 1467 pages).
What makes me insecure: Handling of transmit interrupts is a very important thing for serial communication. It cannot be, that I am the only one dealing with this problem on SAM3. So someone else should have addressed this problem, if it is not only a mistake by myself.
I found a hint on interrupt handled serial communication with SAM3 at the FreeRTOS environment (www.freertos.org
). But I do not have the time now, to care for that. I would need many hours to install and understand the FreeRTOS environment.
Thanks again for Your interest. May be, some day someone else is interested in interrupt handled serial communication for SAM3 and together we may find the solution.
Some time later: .... the problem badgers me ...
I downloaded FreeRTOS and investigated the source code for serial communication.
Aah ... even they do not use transmit interrupt for USART, only receive interrupt (on USART1).
So I have a growing suspicion, that it is a bug with the microcontroller.
I do not know, where to ask at ATMEL. I do not want to discuss with the sellers until they understand the problem.
They do enable transmit interrupt with USART, but it is inside the character sending function.
I have to stop my investigations on that now, it takes too much time and there are more important things to do. I could not find the mistake and the comparison with FreeRTOS did not give me any hint, why the Arduino Due blocks as soon as I enable the transmit interrupt of USART.