this thread is related to my previous one about bit-banging some GPIO using DMA2: viewtopic.php?f=16&t=3778
When I am using USB (FS) the DMA2-transactions become disturbed randomly.
This article describes a similar issue: https://vjordan.info/log/fpga/stm32-bar ... speed.html
Please see the last plot on the bottom.
He assumes that this happens because the CPU blocks the DMA when accessing the SRAM.
However, there is a (probably) a solution for that: I moved the buffer into sram2 while everything else remains into sram1. According to "Figure 4. STM32F446xC/E and Multi-AHB matrix" in the STM32F446 datasheet, there should be "no way" for the CPU to disturb DMA2 anymore:
Code: Select all
#define intoSRAM2 __attribute__((section(".ram2"))) __attribute__((aligned(4)))
volatile uint32_t buffer[8] intoSRAM2; This solved the problem for me.
Now, I added USB to my project and the trouble starts again. This is my USB-config in mcuconf.h:
Code: Select all
#define STM32_USB_USE_OTG1 TRUE // USB OTG FS
#define STM32_USB_USE_OTG2 FALSE // USB OTG HS
#define STM32_USB_OTG1_IRQ_PRIORITY 14
#define STM32_USB_OTG2_IRQ_PRIORITY 14
#define STM32_USB_OTG1_RX_FIFO_SIZE 512
#define STM32_USB_OTG2_RX_FIFO_SIZE 1024
#define STM32_USB_OTG_THREAD_PRIO LOWPRIO
#define STM32_USB_OTG_THREAD_STACK_SIZE 128
#define STM32_USB_OTGFIFO_FILL_BASEPRI 0When I connect to USB, I start writing to the port through:
Code: Select all
void USB_VCP_send_string(unsigned char *ptr)
{
while (*ptr != 0) {
streamPut(&SDU1, *ptr);
ptr++;
}
}This is called from a thread. The buffer is never touched after initialization.
The purple signal is generated by DMA2 writing to GPIOA->BSRR.W. When the signal remains high, there is at least the respective byte not been transferred to the BSRR register. This happens almost regardless of the actual DMA2-request-frequency (this was 3.6MHz, but also at a few kHz).
Is it possible, that the USB driver has any effects to DMA2?
I would be happy about any ideas again!
Jörg
