STM32F4 SPI with DMA, LL API: no interruption at the end of the transfer
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-13 11:58 PM
Hello,
I am using a STM32F427 to read and write data to EEPROM Serial 256-Kb SPI
CAT25256. I use LL API, and DMA full-duplex over SPI. I manage myself the Chip Slect signal.
I can see with logic analyser that datas are sent and received to/from EEPROM correctly.
But I do not have interruption from DMA, neither input or outputstream.
I do not understand why.
The only way to detect the end of the transfer is to look at the BSY flag LL_SPI_IsActiveFlag_BSY(pSPI_Instance). Could-you help me to find where is the problem?
Thank you for help.
Best regards,
FWX.
I
- Labels:
-
STM32Cube MCU Packages
-
STM32CubeMX
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-15 12:53 AM
Hello @FWX
It seems that the Systick interrupt is causing your issue. Try decreasing the Systick interrupt priority and check again
Thanks
Omar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-19 12:45 AM
Hi Omar,
I don't understand why there would be a conflict over interrupt priorities. ST documentation never talks about conflict in interrupts. Priority levels and subpriorities are there to manage the order of execution of interrupt handler code.
I have found this explanation:
The Preemption Priority allows an ISR to be preempted (interrupted) by another interrupt of higher priority. When the higher-priority interrupt is completed, the lower-priority interrupt continues from where it left off.
Subpriority, on the other hand, has nothing to do with preemption. Say that you have two interrupts of the same priority which are both pending. The interrupt handler will choose which one to service first, based on their subpriority. Once the first one is completed, the second one will begin.
It may seem unlikely that two interrupts can happen at the same time. One common situation where this could happen is if you have an interrupt service routine that takes a long time. During this routine, multiple other interrupt triggers may have taken place. If so, the subpriority will determine which one is handled next.
Finally, keep in mind that as the actual priority increases, the priority value decreases. That is, Priority=1 will be serviced before Priority=2.
Do you have more information on the malfunction I am seeing: no call of interrupt handlers in certain undetermined conditions?
Thanks in advance.
Best regards,
FWX.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-19 01:16 AM
You have to clear the flags causing the interrupts (i.e. DMA_LISR/HISR flags) in the ISR. Otherwise, the ISR gets invoked over and over.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-19 01:35 AM
Hi Jan,
The problem is not that the interrupt handler is called over and over, but that the interrupt handler is never called.
Before activating DMA streams, interrupts are cleared:
/* Clear all interrupt flags at correct offset within the register */
WRITE_REG(pDMA_SPI_Instance->LIFCR, DMA_LIFCR_CHTIF3|DMA_LIFCR_CTCIF3|DMA_LIFCR_CTEIF3|DMA_LIFCR_CDMEIF3|DMA_LIFCR_CFEIF3);
WRITE_REG(pDMA_SPI_Instance->HIFCR, DMA_HIFCR_CHTIF4|DMA_HIFCR_CTCIF4|DMA_HIFCR_CTEIF4|DMA_HIFCR_CDMEIF4|DMA_HIFCR_CFEIF4);
Same in interrupt handler, but never called with priority greater or equal to 5 (because of FreeRTOS needed).
If priority of interruption are 0 or 1, interrupt handler are called. This is my problem.
Have you an idea?
Thank you for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-19 01:52 AM - edited ‎2024-08-19 01:55 AM
> Same in interrupt handler,
>> WRITE_REG(pDMA_SPI_Instance->LIFCR, Status);
OK I overlooked that, sorry.
> The problem is not that the interrupt handler is called over and over, but that the interrupt handler is never called.
How do you know?
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-19 02:00 AM
Because I set an indicateur in the interrupt handler, and my main loop is waiting for this indicator to change.
I also put a breakpoint in the interrupt handlers, for both input and output stream, but never stopped.
But I can see the transfer complete flag set in interupt status register when I stopped the code.
See capture screen image attached.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-19 02:39 AM
Interesting.
I don't use FreeRTOS so can't help with this further, sorry.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-08-19 02:54 AM
Ok. Thank you Jan.
- « Previous
-
- 1
- 2
- Next »