I have a really bizarre problem that I’ve been trying to track down for well over a day. It looks to me like some other thread may be hijacking my UART’s DMA and cuasing havoc.
Maybe. I’m not convinced of that just yet.
Anyway, I thought that I’d solved it temporarily with a cludge by doing this rather than using the DMA:
vTaskSuspendAll();
for (i=0;i<RDMMessageSize;i++)
{
while ((USART1->SR & 0x80) == 0);// Make sure we're free to send
USART1->DR = *RDMOutPtr++; // DummyPacket[i];
}
while ((USART1->SR & 0x40) == 0); // Wait until all bytes have finished transmitting before turning RS485 line around
xTaskResumeAll();
That did seem to send all the bytes out at one point, but it’s since gone back to either not sending anything out or sending two bytes (when there should be twenty-odd.
Is this vTaskSuspendAll(); and xTaskResumeAll(); what I need so that the part of the program sending out the data cannot be interrupted by anything else at all? Errrr, interrupts aside of course. Although, maybe being able to disable all interrupts would also be a good idea. I’m not sure whether there’s a FreeRTOS method for that or whether I should just set the global disable bit on this STM32F107.
The suspend/resume all functions, as you imply, will prevent a switch to another task, but will not prevent interrupts. Whether that is ok in your case or not depends on how long it takes for your for() loop to execute (which in turn will depend on the length of the message being sent and the baud rate). It could be quite a long time to have nothing running but what is effectively a polling loop.
If this simple code is still erring then I suspect your problem is not FreeRTOS related. Are you sure the uart does not have interrupts enabled?
Does your application access USART1->DR or the WE-bit of the RS485 bus from more than one task?
Why would it help to use a critical section or disable the scheduler while sending data?
Does RDMOutPtr point to fast internal RAM, or maybe to (slower) external (S)DRAM? That may cause problems. Some peripherals will allow it but perform badly.
Otherwise I would find it strange if DMA doesn’t work properly.
Have you checked the RS485 signal with a scope? Isn’t there a hardware problem? When no device is lowering the WE bit, do you see good, well-defined levels? Your USART must see a high in this ‘resting position’, if not the first start-bit may not be understood.
Do you wait long enough between setting WE and writing the first byte? As a test, you can try to wait more than 10 bits between lowering WE and sending the first byte.
Thanks Richard and Hein and apologies for not replying earlier. I never get notifications over email of when someone posts a reply for some reaosn.
Anyway, it turns out it was, indeed, an interrupt going off and disabling the UART itself.
It seemed so obvious when I eventually it down!
I had spent ages looking at the signals with scope, Hein, yes. This was partly why it was driving me nuts. I have a fabulous Agilent scope that has all sorts of amazing serial decoding built in that helps so much with issues like this and it was showing a perfect reply (when I was single stepping anyway).
This was partly why it was driving me nuts. I have a fabulous Agilent scope that has all sorts of amazing serial decoding built in that helps so much with issues like this and it was showing a perfect reply (when I was single stepping anyway).