Freertos block

freertos seems to be blocked when write flash in one task as below:
void backup_parameter( VCP_t *ctl_para ){

uint8_t bkp[ 4 + sizeof( VCP_t ) ] = { 0 };		
	
	erase_page(1, 37);
	
	memcpy( bkp + 4, ctl_para, sizeof( VCP_t ));		
	
FLASH_Program( BOOTLOADER_FLAG_ADDRESS, sizeof(bkp) / sizeof(*(bkp)), (uint32_t *)bkp );									

}

void ParaBackupTask( void *pvParameters ){

while(1){    						
		
		  //taskENTER_CRITICAL();			  
		  backup_parameter( &g_vp.vcp ); 
		  //taskEXIT_CRITICAL();	
		
    vTaskDelay( pdMS_TO_TICKS(configPARAMETER_BACKUP_TASK_PERIOD) );			
	}		

}

Can you elaborate on what “blocked” means? Is it that the tick count isn’t executing so tasks don’t time out correctly, or something else?

How is FLASH_Program() implemented? If it disables interrupts then the RTOS tick interrupt will stop.

Which MCU are you using?

  1. In another task there is a led flash periodly. But it will stop flashing some time when add “ParaBackupTask”. So I said freertos was blocked.

  2. FLASH_Program() is
    TestStatus FLASH_Program(uint32_t WRITE_START_ADDR, uint16_t Size, uint32_t * data)
    {
    uint32_t Address;
    TestStatus TransferStatus = FAILED;
    uint32_t i;
    TransferStatus = PASSED;
    /* Unlock the Flash Bank1 Program Erase controller */
    fmc_unlock();

    /* Clear All pending flags */
    fmc_flag_clear(FMC_FLAG_BANK0_END | FMC_FLAG_BANK0_WPERR | FMC_FLAG_BANK0_PGERR);

    /* Program Flash Bank1 */
    Address = WRITE_START_ADDR;
    i = 0;
    while(Address < (WRITE_START_ADDR + Size))
    {
    fmc_word_program(Address, data[i]);
    i++;
    Address = Address + 4;
    fmc_flag_clear(FMC_FLAG_BANK0_END | FMC_FLAG_BANK0_WPERR | FMC_FLAG_BANK0_PGERR);
    }

    fmc_lock();

    return TransferStatus;
    }

  3. MCU is GD32F103VET6

If backup_parameter() takes a long time to execute, and has a priority that is higher than the priority of the task that flashes the LEDs, then it will starve the LED flashing task of any execution time, which is a task priority issue rather than a blocking issue.

Then Is there any good idea on how to fix this issue?
Just now I tried to lower priority of “ParaBackupTask”, but it can not fix this issue.

Is backup_parameter working properly ? Is the LED task continuing blinking the LED after a backup was done and waiting in vTaskDelay ?

Yeap. But some time later , the LED stopped flashing.

Did you define configASSERT and enabled stack checking ? Did you verify that the task stacks are large enough ?
I think something (probably the backup task) is damaging internal data structures making your application not longer working properly. This is almost always caused by stack overflows given the code is not buggy.

I defined configASSERT but did not enable “INCLUDE_uxTaskGetStackHighWaterMark”

See also FreeRTOS - stacks and stack overflow checking
and maybe also FreeRTOS FAQ - links to all RTOS FAQ pages

OK. Thank you very much! I will try it and give a feedback here ASAP.

Most microcontrollers can’t fetch instructions from flash while a write operation is in progress, so they appear frozen until the flash write operation completes. This includes most STM32 parts (the ones without dual flash banks), but I don’t know how GD32 parts behave. At least some GD32 parts copy instructions from flash to RAM during boot and then execute from RAM.

GD32 fetch instructions and execute directly from flash.

Double-check the capabilities of the Flash in the processor. As Tagli said, most processors are unable to read from one block of flash while another one is being written to.

Another possibility (as rtel mentioned) is that the FLASH_Program() disables interrupts to give it the correct timing, which will stop the rest of the system.

One technique to get around not being able to read and write to flash simultaneously is to copy the code you want running during the flash write to RAM, then temporarily execute from RAM. You would have to build the function copied to RAM specifically to enable that though.

OK. I will double-check it. Thank you very much!

Thank you very much.