TDA2E: Processors forum

Do you have anything running on this core? then it is possible that this is delayed due to other priority task and when it happens, its not possible to get exact 100 or 50us delay/sleep. 

Regards,

Brijesh

There is also another task with the same priority, most of the time it is waiting to receive data（Utils_mbxRecvMsg）from the SPI bus.

ok, but in this case, when SPI is unblocked, it can potentially delay the GPIO task and can cause sleep to take more time. 

Regards,

Brijesh 

To eliminate the potential impact of SPI task blocking, we try adding a sleep phase at the initial stage of the SPI task and lowering its priority. Like the following:

// Lower priority than task_gpio

void task_spi(void){

// wait for task_gpio done

BspOsal_sleep(1500U); 

spi_init();

while(1)

{

wait_for_data_from_spi();

}

}

void task_gpio(void){

// config GPIO_1 to output mode

GPIODirModeSet(gpio_1, GPIO_DIR_OUTPUT);

// set GPIO_1 to HIGH

GPIOPinWrite(gpio_1, GPIO_PIN_HIGH)

// The high level duration here is 350ms by The oscilloscope. 

// It is inconsistent with the 100ms defined in the software.

BspOsal_sleep(100U); 

// set GPIO_1 to LOW

GPIOPinWrite(gpio_1, GPIO_PIN_LOW)

// The Low level duration here is 150ms by The oscilloscope. 

// It is inconsistent with the 500ms defined in the software.

BspOsal_sleep(50U); 

// set GPIO_1 to HIGH

GPIOPinWrite(gpio_1, GPIO_PIN_HIGH)

}

However, the issue still persists. Are there any other troubleshooting approaches you can suggest?

Can you try disabling SPI task completely first and then check the output? 

Regards,

Brijesh