2024-07-12 09:34 AM
I use NUCLEO-F767Z board and was working on a Application Framework that uses RTOS with different tasks, and logging to serial console and USBDisk. This is quite a while ago (STM32CubeIDE 1.6.1). I couldn't make USBDisk work with RTOS then. I switched to other tasks. But now I want to get back to this.
Now I see, that in STM32CubeIDE there is an example FatFs_USBDisk_RTOS. This might be what I need. But this example can only be selected for other evaluation boards.
Is it possible to port the example FatFs_USBDisk_RTOS to NUCLEO-F767Z for a newbee?
When I download the FatFs_USBDisk_RTOS example for a board which is supported, and look at the sources, then I can see that this is not using the API USBH_Init(), USBH_RegisterClass(), etc, .... - for integration with RTOS.
Therfore, I guess, there is no use trying to adapt and incorporate the FatFs_USBDisk reference into an RTOS project.
Will it be more promising to take FatFs_USBDisk_RTOS from another board and adapt that for NUCLEO-F767Z?
2024-07-20 07:06 AM
WWDG_IRQHandler () at /home/frank/STM32CubeIDE/workspace_1.16.0/FatFs_USBDisk/SW4STM32/startup_stm32f767xx.s:110 110 b Infinite_Loop
For some reason the watchdog is enabled and it hits during some lengthy process (the 200 ms delay?)
Do you actually need the watchdog at this step of development? If yes, prevent it from triggering.
> USBH_Delay(...) is just a wrapper for HAL_Delay(...).
With a RTOS, this is not great. Consider more RTOS friendly implementation of USBH_Delay.
2024-07-21 03:07 AM
Hi @Pavel A.
I locally added missing for the serial console via DMA:
/**
* @brief This function handles DMA1 stream3 global interrupt.
*/
void DMA1_Stream3_IRQHandler(void)
{
/* USER CODE BEGIN DMA1_Stream3_IRQn 0 */
/* USER CODE END DMA1_Stream3_IRQn 0 */
HAL_DMA_IRQHandler(&hdma_usart3_tx);
/* USER CODE BEGIN DMA1_Stream3_IRQn 1 */
/* USER CODE END DMA1_Stream3_IRQn 1 */
}
I missed to adopt that from the reference projects (where it is available).
The I debugged again and wondered about HAL_DMA_IRQHandler() in backtrace at a time, when I didn't expect it to be used.
Is my implementation of TaskConsole_Run(...) here:
...wrong for just firing HAL_UART_Transmit_DMA(...) in lines #94, #99, and #101 - without waiting for confirmation from the DMA interrupt, that the job was done?
I mean: Shouldn't I better lock a semaphore before calling HAL_UART_Transmit_DMA(...) and wait for it being released after HAL_UART_Transmit_DMA(...) - before continue to process?
And that semaphore should be unlocked by the DMA1_Stream3_IRQHandler()?
Another question:
Is it correct to enable the IRQ globally in https://github.com/FBergemann/STM32-USBDiskAndConsole/blob/master/Src/main.c#L68 ?
Or does that have to be enabled and disabled again around the invocations of HAL_UART_Transmit_DMA(...) ?
2024-07-21 01:23 PM
> Shouldn't I better lock a semaphore before calling HAL_UART_Transmit_DMA(...) and wait for it being released after HAL_UART_Transmit_DMA(...)
Just try it (should work)
> Is it correct to enable the IRQ globally
It is matter of taste. The DMA interrupts are gated by the DMA config registers, so should not occur without reason.
If you prefer, disable the NVIC interrupt.