I am having a difficult time with the ECAN peripheral on a dsPIC33EP512MU810.
I have been using MikroElektronika for a long time & I am a big fan of their products and tools. Unfortunately, i am quite stuck on this issue and i am hoping that someone has encountered it before, or someone with more experience than myself may offer some useful debugging advice.
To summarise my problem: The dsPIC crashes with a software reset when trying to send AND receive standard CAN messages. My program is sending 3x 8-byte packets every 10ms, 3x 8 byte packets every 100ms and 2x 8-byte packets every 1s to individual addresses. These messages are sent from timer-based ISRs.The dsPIC is running at 48MIPS and the CAN baud rate is 500k. As soon as I add a receive function call to the CAN ISR, the processor resets immediately after power-on. Upon the reset, the CAN module appears to be disabled and no CAN messages are sent until a power cycle.
I have read through the ERRATA for this dsPIC and I took note of the DMA / CAN bus arbitration issue, to which i moved the TxRx DMA buffer to Dual Port Ram, and i set the receive dma priority to 7. This fixed my issue for about 1-480s - by this i mean, the processor will run as I expect it too, but will still soft-reset at completely random times between 1-480 seconds after power-on. I have a Vector CANalyzer for which i use to debug & verify CAN bus comms.
I have managed to get the system to somewhat behave by moving my CAN transmit functions to send after a RX message is received & processed - (this system receives 3 8-byte packets every 10ms). Unfortunately, if i perform any additional data processing or calculations after the RX message the dsPIC resets.
I have tried a combination of different timers, interrupt priorities and even removing interrupts completely and running my Tx & Rx comms entirely from the main function, which actually works ONLY with a 10ms delay between Rx and Tx processes. I have spent days attempting to rectify this issue, and i have thoroughly scoured both this & Microchip's forums. My current hypothesis is that there is a read / write collision, buffer or pointer overflow that occurs from the Tx & Rx comms. Using my Mikro debugger, I observed the following values in the C1 registers:
C1RXOVF1 : 0x01 80
C1CFG1 : 192
C1VEC : 264
I tried to catch the reset flags from the RCON register, but it never appeared to update and consistently displayed '0b1000 0011'.
I welcome any & all feedback, happy to provide more details incase i have missed anything - My first time posting, but I have been around these forums for a while, always very helpful. Thanks in advance.
Cheers
