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:
- EtherCAT Subdevice Stack (09.02)
- buffer callback API in our application.
EC_API_SLV_cbRegisterPreSeqInputPDBuffer(...)
EC_API_SLV_cbRegisterPostSeqInputPDBuffer(...)
EC_API_SLV_cbRegisterPreSeqOutputPDBuffer(...)
EC_API_SLV_cbRegisterPostSeqOutputPDBuffer(...)
