- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hi TI-Support-Team,
We have a problem in Debug build, as soon as our application using EtherCAT subdevice stack switches to operational mode with DC-Sync (Sync0) enabled the core crashes and lands in a abort handler.
Callbacks for requesting process data are called either from BEPDItask or if DC-Sync enabled from BESync0Task. In our application both tasks show a FreeRTOS HighWaterMark of 0 in non-synchronized mode. Therefore, I think it is very likely that in those tasks an unexpected stack overflow occurs.
I was able to reproduce this behavior in the demo/example. In the registered callback I just simulate with a recursive call that something is going on. I then have the same behavior as in my application I run into a abort handler:
#define MAX_RECURSION 40
static void recursiveCall(uint32_t call_number, uint32_t dummy_data, uint64_t another_dummy_variable)
{
if(call_number == MAX_RECURSION)
return;
recursiveCall(call_number + 1, dummy_data, another_dummy_variable);
}
static void*acquireTxBuffer(void* pContext_p, uint32_t length_p)
{
// dummy data
data_tx[0]++;
data_tx[1]++;
data_tx[2]++;
data_tx[3]++;
// consume stack
recursiveCall(0, 2004, 5000);
return &data_tx[0];
}Is there any possibility to increase the sizes of those tasks?
Printing the tasklist in the state change function shows, that from beginning both tasks only have 169 bytes left, which might be too less if a few function calls/copy actions need to be done.
State change: 0x0 -> 0x1
Task State Prio HighWater ID
Appl_LoopTask X 8 516 5
IDLE R 0 969 2
kbEepromTask B 4 441 11
mainThread B 30 1784 1
HWALWatchDog B 30 179 4
BELedTask B 8 183 9
BESync0Task B 16 169 7
BESync1Task B 16 169 8
BEPDItask B 16 169 6
NVM_APP_WriteAsyncTask B 8 169 10
Tmr Svc B 31 196 3What I also saw in demo is that when I add some further TX-PDOs the HighWater-Mark already decreases significantly:
BESync0Task B 16 28 7
BEPDItask B 16 28 6Additional Info: I am using:
EC_API_SLV_cbRegisterPreSeqInputPDBuffer(...)
EC_API_SLV_cbRegisterPostSeqInputPDBuffer(...)
EC_API_SLV_cbRegisterPreSeqOutputPDBuffer(...)
EC_API_SLV_cbRegisterPostSeqOutputPDBuffer(...)
I just wanted to point out that this still is an issue. I do not know how to handle this properly/what could be a workaround. In firmware I minimized calls and stack consumption in those callbacks, but still I got this error. I took a closer look to memory. For a normal task you see that there is some stack left (some memory regions left filled with 0xA5A5A5A5 FreeRTOS-pattern)
But for the PDI task and SYNC0 tasks it pretty much looks like a stack overflow
However I do not know how to influence the stack or if I can move those variables to somewhere else, where I could insert "safety" buffers inbetween.
