After transplanting the latest FreeRTOS on the STM32G0B1 and using the From_ISR() series of functions, the system will crash

The MCU model I am using is STM32G0B1 (with M0+ core). I generated the Hal library code using CubeMX, and then plan to port the latest FreeRTOS. The following problem occurred:
Currently, if no external interrupt is used and only multiple tasks are executed, with the task content being just GPIO toggling, it can already run.
However, if a semaphore is set up and the task is switched in the receiving interrupt callback function of the USB peripheral, it will enter the hardware fault handling function when the prvCheckTasksWaitingTermination() function is executed.
The receiving interrupt callback function is as follows:
if(User_Flag_USB_RX_Once_Complete ! = NULL)
{
BaseType_t xHigher_Priority_Task_Worken = pdFALSE;
xSemaphoreGiveFromISR(User_Flag_USB_RX_Once_Complete,&xHigher_Priority_Task_Worken);
portYIELD_FROM_ISR(xHigher_Priority_Task_Worken);
}

Currently, thepreempting priority of all programmable peripheral interrupts in CubeMX has been set to 3 (the least priority. G0 only has 2 bits, with priority levels ranging from 0 to 3).
#define configKERNEL_INTERRUPT_PRIORITY 3 (the least priority)
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 2
#define configMAX_API_CALL_INTERRUPT_PRIORITY 2
Those AI all said it was a matter of priority. However, the priority of the RTOS is opposite to that of the NVIC of the MCU. It is also unclear which logic these three macros follow.
Task initialization and functions: void Function_USB_Revice_Handler(void * pvParameters)
{
while(1)
{
if(
xSemaphoreTake(User_Flag_USB_RX_Once_Complete,portMAX_DELAY) == pdTRUE
)
{
void * *arr = (void * *)pvParameters; // Since the variables are located in different and discontinuous positions, the data is passed in through an array of pointers.
uint32_t RX_Count = *(uint32_t *)arr[0];
uint8_t *buffer = arr[1];

    //CDC_Transmit_FS(buffer,RX_Count);
    }
}

}
Initialization of FreeRTOS tasks:
void RTOS_Tasks_Init(void)
{
User_Flag_USB_RX_Once_Complete = xSemaphoreCreateBinary();
xTaskCreate(Function_USB_Revice_Handler,“USB_R”,256,USB_RX_Buffer_Info_Addr,10,NULL);

xTaskCreate(Function_Task_P2_LED1,“P2 LED1”,256,NULL,10,&Task_P2_LED1);
xTaskCreate(Function_Task_P2_LED2,“P2 LED2”,256,NULL,10,&Task_P2_LED2);
xTaskCreate(Function_Task_P2_LED3,“P2 LED3”,256,NULL,10,&Task_P2_LED3);

vTaskStartScheduler();
}
The port file uses the M0 core.
This article was written using translation software.

If you comment out this part, does everything else work as expected?

Have you defined cofigASSERT in your FreeRTOSConfig.h?

If this part of the code is commented out, it won’t cause the system to crash when the USB receive interrupt is triggered. I asked the AI, and they all said it was due to an error in my priority configuration. But even after following their method to make the modification, the hardware still malfunctioned.
Then the assert() function does not modify itself and remains in its default state. Moreover, it is not used by itself either.

#define configASSERT( x )
if( ( x ) == 0 )
{
taskDISABLE_INTERRUPTS();
for( ; ; )
;
}

your task stack sizes look fairly small, have you tried raising them? Have you checked on stack overflows?

I also tried changing it to 512 before, including setting configSYSTEM_CALL_STACK_SIZE to 512 as well. But it still ended up triggering the hardware fault handling function.

	if(User_Flag_USB_RX_Once_Complete != NULL)
	{
		xSemaphoreGive(User_Flag_USB_RX_Once_Complete);
	}

Even if we modify the code to avoid using the From_ISR series of functions within the callback, the system will still crash and enter the hardware fault handling function.

I was using version 11.1.0. Then I noticed that the three priority configurations (kernel, syscall, apicall) of FreeRTOS were not referenced anywhere in the entire project. Is this normal?

Previously, when creating the USB task, the &Task_Handler_t variable was not included. After I added it, the hardware failure still occurred.
xTaskCreate(Function_USB_Revice_Handler,“USB_R”,256,USB_RX_Buffer_Info_Addr,10,NULL);

xTaskCreate(Function_USB_Revice_Handler,“USB_R”,512,USB_RX_Buffer_Info_Addr,10,&Task_USB_Revice_Handler);

That is fine.

That is expected too.

Would you please share your complete project?

Since the reply function of this community indicates that new users cannot upload attachments,Then reply to the bounced email using the provided email address. May I ask if you could offer a way for me to receive the message directly?

You should be able to upload now.

Currently, the size of the project’s email after ZIP compression is much larger than 4MB. I have deleted the compiled files, but the size of the Hal library is over 40MB. The current compression method is “best”, and it is also 13MB.

May I ask if you have any other solutions? For example, increasing the allowed file size or changing the sending method?

Could you please inform me of the time period you spent in the community and the corresponding time zone for that period? At least let me know during which period you won’t be responding to messages.

May be put in a GitHub repo somewhere and share the link.

DDXP1/STM32G0-FreeRTOS-error: FreeRTOS出现错误

The callback function for USB receive interrupt is located at lines 168 to 191 of usbd_config.c
FreeRTOS task initialization is in FreeRTOS_User_API.c
USB task is defined in USB_API.c

User_Flag_USB_RX_Once_Complete is never initialized in usb_api.c, so it appears to be 0 when referenced. That eyplains the crash.

这个User_Flag_USB_RX_Once_Complete是一个全局变量,然后在RTOS_Tasks_Init()函数内使用xSemaphoreCreateBinary()将其初始化为信号量。

ok I see. Could it be that your usb isr in invoked before the init function is called? Put an assert on User_Flag_USB_RX_Once_Complete in the callback and see if it is triggered. Note that prematurely enabling interrupts (very likely by ab underlying eco system that is not RTOS aware) is one of the most frequent cases of problems in FreeRTOS. In this case you may get away with returning from the callback as long as the semaphore is 0 but run into other problems.

This User_Flag_USB_RX_Once_Complete is a global variable, and then it is initialized as a semaphore using xSemaphoreCreateBinary() within the RTOS_Tasks_Init() function.