Reading outpc via CAN, CANPWM corruption?

[gurov]

So what did you change in your code gurov??

in the screenshot above, DLC is read from 1st receive buffer every time.

Code: Select all

DLC = MEGASQUIRT.CANRead(MCP_RXB0DLC);

apparently, this somehow confuses the CAN-BUS interface, and makes it read random things from the 1st data cell.

[makro]

Ohhhhh yes... good pick up and innocent mistake!!

So every so often it would be reading the DLC from a different message in the other buffer. As the buffers don't get cleared after reading a message, you would occasionally see a larger DLC code which would be reading the 2nd or 3rd byte from the previous CAN message in the same buffer you're reading your new message from.

Makes sense I think.

[gurov]

Ohhhhh yes... good pick up and innocent mistake!!

So every so often it would be reading the DLC from a different message in the other buffer. As the buffers don't get cleared after reading a message, you would occasionally see a larger DLC code which would be reading the 2nd or 3rd byte from the previous CAN message in the same buffer you're reading your new message from.

Makes sense I think.

well, but that's the thing though...
DLC isn't used anywhere (super important) on receive. and the data bytes were read from the right place.

[makro]

If you had turned all other CAN features off in Megasquirt then I can see what you're saying... you should only be receiving one type of CANPWM message and IIRC that always has a 0 - 100 value in the first byte for me. However if you're using CANPWM8 then yeah you'll be seeing it in the eighth byte.

Is your CANPWM1 setup at all?? Because my MS3 is unconnected on my desk, I see guages from time to time flicker as I'm assuming there are some floating inputs affecting it (as they're all unconnected). If that flickering guage is actually linked to the load axis on another PWM, then maybe you're getting the dummy values from that flickering? Just a suggestion really... I'm probably barking up the wrong tree.

[gurov]

If you had turned all other CAN features off in Megasquirt then I can see what you're saying... you should only be receiving one type of CANPWM message and IIRC that always has a 0 - 100 value in the first byte for me. However if you're using CANPWM8 then yeah you'll be seeing it in the eighth byte.

Is your CANPWM1 setup at all?? Because my MS3 is unconnected on my desk, I see guages from time to time flicker as I'm assuming there are some floating inputs affecting it (as they're all unconnected). If that flickering guage is actually linked to the load axis on another PWM, then maybe you're getting the dummy values from that flickering? Just a suggestion really... I'm probably barking up the wrong tree.

i started looked at the rest of the code when the corruption migrated to output ports.

CANPWM1 did not have to be set up at all.

i don't have an issue with floating inputs, i usually disable what i don't need, and all the CAN stuff is still just pulling from basically a set of variables, nothing feeding into that yet.

all the corruption stopped once i read DLC from the right buffer's DLC register. i really do think the CAN controller was getting really confused why i would read header from first 4 bytes, then other buffer's DLC byte.

[makro]

Yeah I don't think that's how it works IMHO.

You are simply sending the MCP2515 the SPI read instruction and it's returning the data to you. The order of which of the different bytes of the buffer are being read is something the programmer gets to decide.

What SPI command are you sending to read the buffers? Is it one of the quick read commands??

[gurov]

Yeah I don't think that's how it works IMHO.

You are simply sending the MCP2515 the SPI read instruction and it's returning the data to you. The order of which of the different bytes of the buffer are being read is something the programmer gets to decide.

What SPI command are you sending to read the buffers? Is it one of the quick read commands??

hey man, this s*** don't make sense to me either. it worked when reading from buf0, jacked when reading from buf1, cause dlc is read from buf0.

Code: Select all

    EID8=MEGASQUIRT.CANRead(MCP_RXB1EID8);
    EID0=MEGASQUIRT.CANRead(MCP_RXB1EID0);
    DLC =MEGASQUIRT.CANRead(MCP_RXB1DLC);
    databuffer[0]=MEGASQUIRT.CANRead(MCP_RXB1D0);
    databuffer[1]=MEGASQUIRT.CANRead(MCP_RXB1D1);
    databuffer[2]=MEGASQUIRT.CANRead(MCP_RXB1D2);

the read is just a normal SPI read procedure.

Code: Select all

INT8U MCP_CAN::mcp2515_readRegister(const INT8U address)
{
    INT8U ret;

    MCP2515_SELECT();
    spi_readwrite(MCP_READ);
    spi_readwrite(address);
    ret = spi_read();
    MCP2515_UNSELECT();

    return ret;
}

it's a completely unexpected for the MCP flow to read DLC from the buffer that's not being read from.

i can reproduce the corruption 100% by changing that 1 to a 0 in the DLC read.

i don't make the rules, i just follow them.

[gurov]

well, reproduce 100% in the chance that read comes from buf1, i guess i could test it by switching buf0's DLC read to buf1 and get corruption 100% of the time.