flewz2010 wrote on Thursday, November 21, 2019:
do you mean break in the debugger, so stop the program running in the
debugger?
Yep, when I try to stop the program to step through the code, I can make one step in the best case scenario until the hard fault triggers
Do you have the debugger set to stop timers when you are stepping through the code?
How do I set this? I only have this assert defined per the instructions for the m4
#define configASSERT( x ) if ((x) == 0) {taskDISABLE_INTERRUPTS(); for( ;; );}
…and the second task is the same as the first task? If not, what are
the differences?
The thing about the two tasks was a wrong assumption on my part. I eliminated one task and I still have the problem, I even removed the TaskDelayUntil and Semaphore I used previously to synchronize my tasks, so now it just runs continuously.
const TickType_t xFrequencySend = 10;
// xLastWakeTimeSend = xTaskGetTickCount();
for(;;)
{
// xLastWakeTimeSend = xTaskGetTickCount();
if(xQueueReceive(sendCmdQ, &cmd, 0) == pdTRUE)
{
// if( xSemaphoreTake( xSendSemaphore, (TickType_t) 500) )
// {
switch(cmd)
{
case CONNECT:
connect();
break;
case START:
start();
break;
}
// xSemaphoreGive(xSendSemaphore);
// }
}
// else
// {
// vTaskDelayUntil( &xLastWakeTimeSend, xFrequencySend );
// }
}
This is my task, although a bit simplified. the connect() and start() functions look a bit like this:
uint8_t data[2] ={CONNECT, 0x80};
HAL_UART_Transmit(&huart6, (uint8_t *) pData, size, 5000);
while(!Connected)
{
Connected = connectCheck();
}
the start() function is analogous in sending out data over UART and checking received packages for a response.
The UART interrupt is set to lowest priority (15,0), although I also had it at (10,0)