OK, I got this bug fixed -> YAY! <-
It was not the microcontroller that was causing the error! It was an user application error. Some details:
We make use of an external CANbus controller (MCP2515). CANbus frame messages can contain zero to eight messages. According to the received frame data from the MCP2515, the frame messages get copied. However, in very seldom cases, the received messages length value equals 16. This should never be possible since CAN frame data can at max use 8 bytes, not 16 bytes.
However, we did use the received value to copy the received data to an pointer that points to an array managed on the stack. So whenever in seldom cases we received 0xF, it was erasing 8 positions on the stack causing stack corruption.
So FIXED :D. Now we need to focus why sometimes the CAN controller send us 0xF messages length.
It was not the microcontroller that was causing the error! It was an user application error. Some details:
We make use of an external CANbus controller (MCP2515). CANbus frame messages can contain zero to eight messages. According to the received frame data from the MCP2515, the frame messages get copied. However, in very seldom cases, the received messages length value equals 16. This should never be possible since CAN frame data can at max use 8 bytes, not 16 bytes.
However, we did use the received value to copy the received data to an pointer that points to an array managed on the stack. So whenever in seldom cases we received 0xF, it was erasing 8 positions on the stack causing stack corruption.
So FIXED :D. Now we need to focus why sometimes the CAN controller send us 0xF messages length.
