Hi
I am using a STM32F103ZG and Keil uVision + RTX. I have a multi-threaded application using interrupts and DMA. The problem I have is an intermittent ISR FIFO overflow and, upon inspection, some odd interrupts / SVC / PendSV / SysTick behaviour.
Everything is fine for quite some time and the software behaves normally, processing multiple interrupts, using isr_xxx to post various IPC messages / event and context switching quite happily. Then, at random times since POR, a ISR FIFO overflow occurs. Upon inspection of the the FIFO it is indeed full (default limit of 16) but the logged interrupt behaviour shows that PendSV is no longer being called.
The NVIC is setup correctly I believe with SVC higher priority (14) than both SysTick and PendSV (both 15).
We have been using STM32F1 series processors for a long time now (mainly 103ZE, never ZG until now) and always with the same interrupts settings, so I cannot understand why we are no longer seeing PendSV being executed.
As we are using a far amount of DMA, does the F1 series suffer from the 'no more than 2 simultaneous DMA transfers' being report for F2 and F4?
Any thoughts / direction appreciated.
Regards
Andy
Actually, this is a really big hit to the processor design as, at least with the F2xx family, there are no peripheral FIFOs. By using DMA you can bypass the need to service each peripheral interrupt on a data-type basis. IF DMA is defective, then you are forced to use this method or jump through many hoops to ensure that no more than 2 DMAs are in use at a time. Not a pretty solution. Thus this is probably the reason why ST is mum on providing a workaround/chip revision other than problem acknowledgement. As the F1xx, F2xx and F4xx are wihin the same 'family line' of processors, they probably ALL have this issue would be a reasonable assumption to make.
Hi All,
Further debug of the problem suggests that we are in the SVC handler when an interrupt occurs (UART) and preempts the handler. Once the interrupt handling is complete and SVC handler also complete, we see no more PendSV activity.
We have been using RTX 4.12 for some time, but as a result of this issue, we have looked at the change set between 4.12 and latest (4.53). It looks like a significant bug was fixed between these two releases to address an issue with task / scheduler locking and interrupt preemption.
We have migrated this fix across and the application is stable now and the problem cannot be reproduced.
A support case is open with ARM so this thread can be closed (unless anyone has pertinent info to share of course).