Reading outpc via CAN, CANPWM corruption?

[gurov]

From having gotten this request/detect response from ms, the biggest hurdle is the lack of clear mapping of standard compact header bytes to the extended header structure used by ms (which is so full of wtf)

The arching can-bus library follows the (microchip) mcp2515 , and exposes the headers, but mapping of that to what ms is doing takes some time and shifty code to figure out.

Perhaps an infographic could help this.

[jsmcortina]

From having gotten this request/detect response from ms, the biggest hurdle is the lack of clear mapping of standard compact header bytes to the extended header structure used by ms (which is so full of wtf)

I'm not sure I understand your question?

Have you looked at the std-CAN broadcasting feature of the latest development firmwares? (pre-1.4)

James

[gurov]

From having gotten this request/detect response from ms, the biggest hurdle is the lack of clear mapping of standard compact header bytes to the extended header structure used by ms (which is so full of wtf)

I'm not sure I understand your question?

Have you looked at the std-CAN broadcasting feature of the latest development firmwares? (pre-1.4)

James

Of course , and that works with only a few lines in arduino, but it feels like cheating, and pre-1.4 only.

I was talking about mapping of the fields needed for a MSG_REQ and MSG_RSP messages, and the part where one part of variable has 4 lower bits, followed by the 5th high bit.

[makro]

I have a C++ class that I use with my Arduino code that you can have if it helps. I wrote it specifically to talk to my MS3.

[gurov]

I have a C++ class that I use with my Arduino code that you can have if it helps. I wrote it specifically to talk to my MS3.

i'd like to take a look. perhaps it will help me solve the issue i'm seeing with things overwriting CANPWM1 randomly every few hundred packets. can you PM it to me please.

[jsmcortina]

Explain your problem some more.

James

[gurov]

Explain your problem some more.

James

i'm still trying to wrap my head around it, cause it's so WTF, and the code works perfectly for the rest of the things, but let me see if i can make it a bit clearer, maybe it will help me think through this.

i've got this.



CANPWM8 is cofigured as this:


every single one of the CANOUT ports is configured, basically triggers on TPS in 5 % increments, but I don't think this was important enough in testing this.

below is the debug code from my arduino talking via can-bus shield.

here's the marked up explanation for the fields:

Code: Select all

SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 110000;
0 0 0 0 0 0 0 48;
sending input port: 10010001
set output PWM port 0 to 7
28429 3.52 57512
SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 110000;
7 0 0 0 0 0 0 48;
sending input port: 10010010
set output PWM port 0 to 0
18 5555.56 57514
SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 110000;
0 0 0 0 0 0 0 48;
sending input port: 10010011
set output PWM port 0 to 7
18219 5.49 62374
SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 110000;
7 0 0 0 0 0 0 48;
sending input port: 10010100
set output PWM port 0 to 0
18 5555.56 62376
SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 110000;
0 0 0 0 0 0 0 48;
sending input port: 10010101
set output PWM port 0 to 7
3847 25.99 63402
SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 110000;
7 0 0 0 0 0 0 48;
sending input port: 10010110
set output PWM port 0 to 0
18 5555.56 63404
SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 110000;
0 0 0 0 0 0 0 48;
sending input port: 10010111

i've not noticed any pattern other than the 2 output digital ports need to be on, and input port has to be on.

also note, even though the markup image says 25-30 seconds between phantom writes, sometimes it's less than that. sometimes more.

rest of the arduino code works fine for interaction between MS and arduino, i just sometimes get a random packet saying the 1st byte = 7, when it should be 0, then it flips back to 0 within 20-ish miliseconds.

at least one of the can PWM output ports needs to be enabled and data going to it, but only first pwm port gets phantom write.

i should also mention that this:

Code: Select all

sending input port: 10010110
set output PWM port 0 to 0
18 5555.56 63404
SIDH: 1011 SIDL: 11101000 EID8: 10 EID0: 10111000 block: 7 offset: 95 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 110000;
0 0 0 0 0 0 0 48;

is from the same loop. change in the PWM ports from previous state causes the packet/data to get printed, such that there's less chatter with whatever microcontroller i'm going to use to actually execute the PWM state change.
the packet counter line ( 18 5555.56 63404 ) in this case is a comparison to the previous packet output. i only display it on state change to cut down on serial traffic, but there's thousands of can messages flying around and making it through just fine, and delivering the same correct data.

[jsmcortina]

I'm examining the code, but


James

[makro]

I have a C++ class that I use with my Arduino code that you can have if it helps. I wrote it specifically to talk to my MS3.

i'd like to take a look. perhaps it will help me solve the issue i'm seeing with things overwriting CANPWM1 randomly every few hundred packets. can you PM it to me please.

No worries... will tidy it up tomorrow and send it to you. Currently buried in a whole heap of other code I'm sure you don't want to sort through!!

[gurov]

I'm examining the code, but


James

yeah, i can do that.

this is latest 1.4 pre4 as well, i just upgraded it this morning before running off to work. it's still on the bench at home, hooked up to a raspberry pi with ser2net running, so i can ssh tunnel my way to it from work. (this is offtopic, but this is one of the coolest things so far)

it also appears that i cannot duplicate this issue while being 60 miles away (debugging the arduino over serial + ser2net for TS)

i've attached the MSQ

i swear i'm not crazy.

[gurov]

I have a C++ class that I use with my Arduino code that you can have if it helps. I wrote it specifically to talk to my MS3.

i'd like to take a look. perhaps it will help me solve the issue i'm seeing with things overwriting CANPWM1 randomly every few hundred packets. can you PM it to me please.

No worries... will tidy it up tomorrow and send it to you. Currently buried in a whole heap of other code I'm sure you don't want to sort through!!

eh, i mainly want your decoding routine for all the megasquirt CAN craziness, here's mine.

assume things are declared
top part changes depending on which RX buffer thing arrived in.

this is receiving a message.

Code: Select all

*snip*

    SIDH=MEGASQUIRT.CANRead(MCP_RXB0SIDH);
    SIDL=MEGASQUIRT.CANRead(MCP_RXB0SIDL);
    EID8=MEGASQUIRT.CANRead(MCP_RXB0EID8);
    EID0=MEGASQUIRT.CANRead(MCP_RXB0EID0);
    DLC=MEGASQUIRT.CANRead(MCP_RXB0DLC);
    databuffer[0]=MEGASQUIRT.CANRead(MCP_RXB0D0);
    databuffer[1]=MEGASQUIRT.CANRead(MCP_RXB0D1);
    databuffer[2]=MEGASQUIRT.CANRead(MCP_RXB0D2);
    databuffer[3]=MEGASQUIRT.CANRead(MCP_RXB0D3);
    databuffer[4]=MEGASQUIRT.CANRead(MCP_RXB0D4);
    databuffer[5]=MEGASQUIRT.CANRead(MCP_RXB0D5);
    databuffer[6]=MEGASQUIRT.CANRead(MCP_RXB0D6);
    databuffer[7]=MEGASQUIRT.CANRead(MCP_RXB0D7);

*snip*



  block=((B01111000 & EID0) >> 3);
  temp=0x00;
  temp=((B00000100 & EID0) << 3);
  block=block | temp;

  offset=SIDH;
  temp=((SIDL & B11100000) >> 5);
  offset=((offset << 3) | temp);

  from_id = EID8 >> 3 & B1111;
  to_id = ((EID8 & B111) << 1 ) + (EID0 >> 7 & 1);
  msg_type = (SIDL & 0b11 << 1) + (EID8 >> 7 & 1);

  myvarblk = databuffer[0] & 0b1111; // table to write to 
  myvaroffset = (databuffer[1] << 3) + ((databuffer[2] >> 5) & 0b111); // offset to write back to
  varbyt = databuffer[2] & 0b1111; // bytes to write

sending a message:

Code: Select all

void ms_can_request(byte block, unsigned int offset, byte req_bytes, unsigned short msg_type, unsigned short from_id, unsigned short to_id, unsigned short varbyt, byte *bytes) {
  byte SIDH = 0, SIDL = 0, EID8 = 0, EID0= 0 , DLC = 0, D[8] = { 
    0, 0, 0, 0, 0, 0, 0, 0    };
  int l;

  SIDH = (offset >> 3) & 255;
  SIDL = (((offset & 0b111) << 5) | ((msg_type & 0b111) >> 1)) | 0b11000 ;
  EID8 = ((msg_type & 1) << 7) | ((from_id & 0b1111) << 3) | ((to_id & 0b1111) >> 1);
  EID0 = ((to_id & 1) << 7) | ((block & 0b1111) << 3) | ((block & 0b10000) >> 2);
  DLC = varbyt & 0b1111;

i was following this page: http://kckr.net/interfacing-megasquirt-with-arduino/

and this is what the message header looks like mapped on the 4 header bytes:

[gurov]

came back home, and started testing again.

I got packets to be transmitted to the PWM can address without having any of the CANPWM outputs used:

Code: Select all

set output PWM port 0 to 0
21 4761.90 159929
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;
set output PWM port 0 to 7
104977 0.95 243942
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 0;
7 0 0 0 0 0 0 0;
set output PWM port 0 to 0
22 4545.45 243953
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;
set output PWM port 0 to 7
134316 0.74 434223
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 0;
7 0 0 0 0 0 0 0;
set output PWM port 0 to 0
21 4761.90 434234
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;
set output PWM port 0 to 7
56537 1.77 479479
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 0;
7 0 0 0 0 0 0 0;
set output PWM port 0 to 0
21 4761.90 479490
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;

the stuff that's left in my arduino program (that talks back to MS3) is sending back the 8bit input port (CANIN 1-8) when asked for it:

Code: Select all

   if (block == INPUT_PORT_TABLE && offset == INPUT_PORT_OFFSET && from_id == 0 && to_id == INPUT_PORT_CAN_ID && msg_type == 1) {
      write_to_ms(myvarblk, myvaroffset, to_id, from_id, 1, &input_port);
  }  

works just fine for what it's supposed to do.

and i also consume PWM packets form MS:

Code: Select all

  if (block == OUTPUT_PWM_TABLE && offset == OUTPUT_PWM_OFFSET && from_id == 0 && to_id == OUTPUT_PWM_CAN_ID && msg_type == 0) {
    for (i=0;i<8;i++) {
      if (output_pwm[i] != databuffer[i]) {
        output_pwm[i]  = databuffer[i];
        change_pwm_port(i);
        show_this_packet = 1;
      }
    }
  } 

as well as the 16 bit output ports:

Code: Select all

  if (block == OUTPUT_PORT_TABLE && offset == OUTPUT_PORT_OFFSET && from_id == 0 && to_id == OUTPUT_PORT_CAN_ID && msg_type == 0) {
    if (output_port[0] != databuffer[0] || output_port[1] != databuffer[1]) {
      output_port[0] = databuffer[0] & 255;
      output_port[1] = databuffer[1] & 255;
      show_this_packet = 1;
      change_output_port();
    }
  }

which also works fine


the corruption does not always blip to 0b111 (0x07) for CANPWM1, i just captured a 0b11111111 (0xFF) (twice, it seems)

Code: Select all

set output PWM port 0 to 7
14707 6.80 589786
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 0;
7 0 0 0 0 0 0 0;
set output PWM port 0 to 0
21 4761.90 589797
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;
set output PWM port 0 to 255
125555 0.80 690284
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 15 myvaroffset: 0 varbyt: 0 - data: 11111111 0 0 0 0 0 0 0;
255 0 0 0 0 0 0 0;
set output PWM port 0 to 0
21 4761.90 690295
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;
set output PWM port 0 to 7
538 185.87 690720
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 0;
7 0 0 0 0 0 0 0;
set output PWM port 0 to 0
22 4545.45 690731
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;
set output PWM port 0 to 255
167668 0.60 824923
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 15 myvaroffset: 0 varbyt: 0 - data: 11111111 0 0 0 0 0 0 0;
255 0 0 0 0 0 0 0;
set output PWM port 0 to 0
21 4761.90 824934
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 0 myvaroffset: 0 varbyt: 0 - data: 0 0 0 0 0 0 0 0;
0 0 0 0 0 0 0 0;
set output PWM port 0 to 7
28358 3.53 847625
SIDH: 1011 SIDL: 11001000 EID8: 10 EID0: 10111000 block: 7 offset: 94 from_id: 0 to_id: 5 msg_type: 0 myvarblk: 7 myvaroffset: 0 varbyt: 0 - data: 111 0 0 0 0 0 0 0;
7 0 0 0 0 0 0 0;

[gurov]

in case you notice, offset 94 vs offset 95 discrepancy between packet captures is me changing the offset that's in CAN PWM output field, which would make zero sense, because that's the address that's written to on the remote controller, so it shouldn't matter at all.

[jsmcortina]

I loaded up your MSQ onto my test MS3 and used my CANanalyser to record the data.

In standalone mode, there aren't any instances of a rogue first byte in the CANPWM data (out of 43000 packets.)

Is there any chance that the data you are sending could be going to the wrong address? The Al-CAN system will allow you to overwrite data.

James

[gurov]

I loaded up your MSQ onto my test MS3 and used my CANanalyser to record the data.

In standalone mode, there aren't any instances of a rogue first byte in the CANPWM data (out of 43000 packets.)

Is there any chance that the data you are sending could be going to the wrong address? The Al-CAN system will allow you to overwrite data.

James

if it was consistent, and was in my code, that would be easy, i wish.

also, just sitting there, idling, there's not going to be rogue data sent back. i have to at least have a response to CANIN1_8 active, i'll put more debugging statements around that to see where it's writing the data, but that part sends a single byte, and works as far as MS is concerned.

for all intents and purposes, i'm getting a legit packet over the can bus (which only has the MS and my CAN-BUS shield on it) that matches the PWM output write.

The packets with corruption would also have ALL of the right data for ch 1-7, just ch0 would get flipped to an odd value, and then flipped back within 20-40 ms.

I could probably work around this by adding some kind of a trailing buffer of values written, and take 2 out of 3, and be able to toss out a rogue value that way, but that seems crappy as the other stuff works so well without secondguessing stuff coming across.

Any ideas on how else to debug this ?

What causes a packet to be sent from MS that writes a CANPWM output ? is it just a timer ? is there a comparison to the last state, and when that changes it sends the packet, or both ?

[jsmcortina]

The buffer-filling side of the CAN sending is in ms3_can.c, see around line 440. The on-the wire stuff is in ms3_can_isr.c

The CANPWM outputs are databytes in the datax1 struct, the main part of the code sets them as if they were a hardware PWM register. The CAN code then sends that data over the wire.

James

[gurov]

The buffer-filling side of the CAN sending is in ms3_can.c, see around line 440. The on-the wire stuff is in ms3_can_isr.c

The CANPWM outputs are databytes in the datax1 struct, the main part of the code sets them as if they were a hardware PWM register. The CAN code then sends that data over the wire.

James

can i assume this code hasn't changed in ages ?

[jsmcortina]

can i assume this code hasn't changed in ages ?

No changes in the area you are looking at between the published 1.3 source and pre-1.4.

James

[gurov]

can i assume this code hasn't changed in ages ?

No changes in the area you are looking at between the published 1.3 source and pre-1.4.

James

fixed.


can you spot it ? i verified that was the issue... so weird though. must be a quirk of the mcp2515

[makro]

So what did you change in your code gurov??