RTCS Hard Fault

[adyr]

Hi,

I am using KSDK 1.3 with MQX on a MK64F120 built with the IAR embedded workbench 7.40.7.9865. I have the HTTP and FTP servers running and I am using CGI and server side includes.

Occasionally I found the debugger stopped at the Hard Fault interrupt. Following the call stack back I found the source of the problem to be in ENET_free (although it may stem further back) where packet->PRIVATE is NULL but the code tries to read the deviceNumber from it. As this likely gets a bad number it then calls enet_critical_begin with the bad number which it uses as an array index and will sometimes cause the hard fault.

My fix is:

param = (enet_dev_if_t *)packet->PRIVATE;

//Adrian Rockall - packet->PRIVATE has somtimes come in as a NULL so try using a safe deviceNumber. Maybe we should just return

if (NULL == param)

{

  count = 0;

}

else

{

     count = param->deviceNumber;

}

But I'm not convinced this is the correct way to handle it. I presume deviceNumber refers to the ENET controller which should be OK on my board as I only have the one device. Should the function just return in this instance?

Does it point to a bug prior to reaching this point where packet->PRIVATE is not being filled in correctly?

Thanks,

Adrian.

[Carlos_Musich]

Hi Adrian,

I your work around works it means that only param->deviceNumber is corrupted and packet->FRAG[0].FRAGMENT is not. I would think that the whole 'packet' is corrupted.

In this specific case your fix work because there is only device 0. However I would not trust that packet->FRAG[0].FRAGMENT has the correct value.

Monitoring this may be tricky, but the only way to know what is happening is to set some watchpoints and check the moment in which a value is assigned to 'packet'.

On our side it is complicated to determine the cause of the problem, we could provide more help if we have a way to reproduce the behavior.

Best regards,

Carlos

[adyr]

Hi Carlos,

I have not seen this problem reoccur for a while and I think it might be fixed by the suggestion in SOCK_STREAM_recv() bug drops data on receive timeout that I applied. However, I have made other changes that could also be the fix or it might just be that I haven't noticed the problem. I have been trying to keep a break point one the count = 0; line but it does get lost at times. I guess I should really put an ASSERT in there.

Best regards,

Adrian.