EVO X GSR Logging -->> CCP?

EVO X GSR Logging -->> CCP?

Postby hpd_wally » Fri Sep 03, 2010 7:50 pm

Hi guys, any nerds out there care to dare that the EVO X CAN Port is running over CCP?

The reason I am speculating this is that it is a standard ASAM spec, I have implemented it on some of our motorsports ECU's for the boxes that do not have ethernet comms.


Here is a sample header for a CCP protocol

Code: Select all
//Command Codes sent from Master
#define CMD_CONNECT          0x01
#define CMD_SET_MTA            0x02
#define   CMD_DNLOAD            0x03
#define CMD_UPLOAD            0x04
#define CMD_TEST            0x05
#define CMD_START_STOP         0x06
#define CMD_DISCONNECT         0x07
#define CMD_START_STOP_ALL      0x08
#define CMD_GET_ACTIVE_CAL_PAGE   0x09
#define CMD_SET_S_STATUS      0x0C
#define CMD_GET_S_STATUS      0x0D
#define CMD_BUILD_CHKSUM      0x0E
#define CMD_SHORT_UP         0x0F
#define CMD_CLEAR_MEMORY      0x10
#define   CMD_SELECT_CAL_PAGE      0x11
#define   CMD_GET_SEED         0x12
#define CMD_UNLOCK            0x13
#define CMD_GET_DAQ_SIZE      0x14
#define CMD_SET_DAQ_PTR         0x15
#define CMD_WRITE_DAQ         0x16
#define CMD_EXHANGE_ID         0x17
#define CMD_PROGRAM            0x18
#define CMD_MOVE            0x19
#define CMD_GET_CCP_VERSION      0x1B
#define CMD_DIAG_SERVICE      0x20
#define CMD_ACTION_SERVICE      0x21
#define CMD_PROGRAM_6         0x22
#define CMD_DNLOAD_6         0x23


The thing of interest is that current mode "23" seems to share the same hex id for CCP command CMD_DNLOAD_6, which I use in my tools to fetch up to 6 bytes worth of data.

Code: Select all
void ccp_download6(U8 mbi)
{
   U8 i=0;
   if(ccp_state.connected==0)
         return;

   while(i<6)
      {
      *ccp_state.mta_addr_0++ = message[mbi].data[2+i++];
      }
   ccp_return_ack_mTA0(ccp_state.ctr, CRC_ACK, (U32)ccp_state.mta_addr_0);
}


Being that this is wrapped on top of the 15676 Layer, I am going to assume that I may be able to try some of the other commands.

The openport 2.0 logger is currently spamming a request for data values using command 23. I have heard that the data limitation rate is held up because the EVO's ECU only services the can command on a periodic 10ms task ( Which is a great way of gating the user from sending too many commands, and making the RTOS suffer due to a long list of ISR's to handle)


This is where I wish to suggest a better way for gathering this data. Most all CCP programs have a model called DAQ, in that during the start of a session, you specify a bin, pointer, and data size. This is done to completion until you build your "DAQ" header. There are usally 4-5 different rates, the ecu holds the list, and once after setup you have completly filled everything that you need, you set the daq to "RUN" and watch the CAN messages fly by. There are periodic respsonse, which will come bundles at a much faster rate than waiting for mode 23 to return data on its periodic task.

Code: Select all
void ccp_set_daq_ptr(U8 mbi)
{
   if(ccp_state.connected==0)
      return;

   if((message[mbi].data[2]<=ODT_COUNT) & (message[mbi].data[3]<ODT_SIZE) & (message[mbi].data[4]<7))
   {
      ccp_state.n_write_daq = message[mbi].data[2];
      ccp_state.n_write_odt = message[mbi].data[3];
      ccp_state.n_write_odt_element = message[mbi].data[4];
      ccp_return_ack(ccp_state.ctr,CRC_ACK);
      }
   else
      ccp_return_ack(ccp_state.ctr,CRC_PARAM_OUT_OF_RANGE);
}

void ccp_write_daq(U8 mbi)
{
struct ccp_state_struct
{
   U8 * mta_addr_0;
   U8 * mta_addr_1;
   U32 station_addr;
   U8 connected;
   union {
         U8 R;
         struct {
               U8 RUN:1;
               U8 STORE:1;
                  U8 reserved_1:3;
                  U8 RESUME:1;
                  U8 DAQ:1;
                  U8 CAL:1;
               } B;
              } status;

   U8 ctr;
   U8 cpp_v_maj;
   U8 cpp_v_min;
   U8 start_daq;
   U8 protection_status;
   U8 protection_removed_que;

   U8 n_write_daq;
   U8 n_write_odt;
   U8 n_write_odt_element;
   union {
      U32 R;
      struct {
         U32 S3:8;
         U32 S2:8;
         U32 S1:8;
         U32 S0:8;
      }B;

   }seed;

   union {
      U8 R;
      struct {
            U8 reserved_2:1;
            U8 PGM:1;
               U8 reserved_1:4;
               U8 DAQ:1;
               U8 CAL:1;
            } B;
           } res_avail;

    union {
       U8 R;
      struct {
            U8 reserved_2:1;
            U8 PGM:1;
            U8 reserved_1:4;
            U8 DAQ:1;
            U8 CAL:1;
            } B;
         } res_prot;
};


struct odt_list_struct
{
   struct odt_struct
   {
      U32 ptr[7];
      U8 len[7];
      U8 used;
   } odt[ODT_SIZE];

   U8 event;
   U8 start_stop;
   U16 prescaler;
   U8 list_used;
   U32 eid_can;
};

#ifdef E1_INCA_CCP_ODP_ENABLED
   U32 addr;

   U8 len=0;


   len  = message[mbi].data[2];
   addr = ((U32)message[mbi].data[4]<<24) + ((U32)message[mbi].data[5]<<16) + ((U32)message[mbi].data[6]<<8) + ((U32)message[mbi].data[7]);
   if((addr>=0x40000000 ) & (addr<=0x40020000 ))
   {

      CCP_ODT[ccp_state.n_write_daq].odt[ccp_state.n_write_odt].len[ccp_state.n_write_odt_element] = len;
      CCP_ODT[ccp_state.n_write_daq].odt[ccp_state.n_write_odt].ptr[ccp_state.n_write_odt_element] = addr;
      //if(ccp_state.n_write_odt_element>CCP_ODT[ccp_state.n_write_daq].odt[ccp_state.n_write_odt].used)
//         {
   //      CCP_ODT[ccp_state.n_write_daq].odt[ccp_state.n_write_odt].used = ccp_state.n_write_odt_element;
         //}
      CCP_ODT[ccp_state.n_write_daq].odt[ccp_state.n_write_odt].used++;

      ccp_return_ack(ccp_state.ctr,CRC_ACK);
   }
   else
      ccp_return_ack(ccp_state.ctr,CRC_PARAM_OUT_OF_RANGE);
#endif
}

void ccp_start_stop_all(U8 mbi)
{
   if(message[mbi].data[2]==CCP_DAQ_START)
      {
#ifdef E1_INCA_CCP_ODP_ENABLED
      ccp_state.start_daq = CCP_DAQ_START;

      CCP_ODT[0].start_stop = CCP_DAQ_START;
      CCP_ODT[1].start_stop = CCP_DAQ_START;
      CCP_ODT[2].start_stop = CCP_DAQ_START;
      CCP_ODT[3].start_stop = CCP_DAQ_START;
#endif
      ccp_return_ack(ccp_state.ctr, CRC_ACK);
      }
   else if(message[mbi].data[2]==CCP_DAQ_STOP)
      {

      ccp_state.start_daq = CCP_DAQ_STOP;
#ifdef E1_INCA_CCP_ODP_ENABLED
      CCP_ODT[0].start_stop = CCP_DAQ_STOP;
      CCP_ODT[1].start_stop = CCP_DAQ_STOP;
      CCP_ODT[2].start_stop = CCP_DAQ_STOP;
      CCP_ODT[3].start_stop = CCP_DAQ_STOP;
#endif
      ccp_return_ack(ccp_state.ctr, CRC_ACK);
      }
   else
      ccp_return_ack(ccp_state.ctr, CRC_PARAM_OUT_OF_RANGE);

}


I LOVE what you have done, but I am going to write some software this weekend and see if I can successfully interface with the DAQ setup , and try to get a session running

For some people, having their data @ 10HZ is fine, but in motorsports we like to run closer to the 100-500Hz range on some channels.

I am also close to getting my Methanl Pump Controller running on my car. It runs of CAN's and currently mode 23's in to the car to pick up Boost Pressure. If anyone is willing to test it on their setup, please PM and maybee we can get some more experience with it.
hpd_wally
 
Posts: 22
Joined: Fri Aug 13, 2010 5:40 pm

Re: EVO X GSR Logging -->> CCP?

Postby Tephra » Sat Sep 04, 2010 2:31 am

Mode 23 is just KWP2000 readECUbyMemoryAddress or something like that.

I dont think it has anything todo with that CCP DNLOAD_6 thing :)

But yes I would love a faster sampling rate, but without hacks to the ECU it wont be done using KWP2000 :)
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: EVO X GSR Logging -->> CCP?

Postby hpd_wally » Sat Sep 04, 2010 6:46 pm

So Pure coincidence that they have the same command header <:

I can now sample data through [0x7E0]{05,23,xx,yy,zz,len}. Got this working in QT, I can pull around 85 samples a second.

I attempted to do a CCP_connect, set_daq_ptr, write_daq, and ccp_start_all), an obviously did not get the command responses we normally see on an enabled ECU.

Tephra....How big of length can you request in the databytes field on message 0x7e0..05..23? Can I request larger blocks and get a few closley packed variables at once?

I am assuming the response mechanism is triggered off a 10ms task, are there 5ms or 1ms tasks inside the ecu? We place our response CAN to CCP in a task as well to not allow the Dyno to pull too much information

I think it might be time to explorer the engine can bus, and try to find some variables there.


BTW Tephra, you are the man!!!! I owe you some funds <: I have been running X1 Mod on my 55571006 for a few hours, and am impressed with the functions that you are adding <:
hpd_wally
 
Posts: 22
Joined: Fri Aug 13, 2010 5:40 pm

Re: EVO X GSR Logging -->> CCP?

Postby hpd_wally » Sat Sep 04, 2010 11:19 pm

Okay, small correction. I have my software, did my first bit of logging, and was able to get ~ 200 samples a second now.

At 10 channels, I am getting ~ 20 HZ of data. I am going to place some of our ADC to CAN modules on the car next weekend to open the system up a little.

Cobly, would you be willing to add a can header in the log that would recieve custom periodic Regular CAN packets allong side mrcan packets? They would be coming at their own periodic rates, so you would only need to hold the variable and flush to the csv during the end of the scan chain.

IE

[0x330] [xx] [yy] [aa] [bb] [cc] [dd]


param=CAN_WG_Lin_Pot
source=CAN_0x330
byte=0
byte_length=2
scalling=x,1024,/,3,*

param=CAN_TC_EGT_THAK_AMP
source=CAN_0x330
byte=2
byte_length=2
scalling=x,0.0048828,*,50,-,800,*
hpd_wally
 
Posts: 22
Joined: Fri Aug 13, 2010 5:40 pm

Re: EVO X GSR Logging -->> CCP?

Postby Tephra » Sun Sep 05, 2010 12:54 am

0xFF is the max request size.

yes I have been bugging colby to add packet cutting so we can just request 1 long memory location and chop what we need out.

I have spent a lot of time on the CAN routines in the X ECU and found most of the timer based configuration, but when I tried to "speed" it up, I started getting a lot of errors (missing frames, duped frames, etc)
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: EVO X GSR Logging -->> CCP?

Postby hpd_wally » Sun Sep 05, 2010 3:04 am

Interesting.

I am more familiar with the Freescale Power PC environment ( MPC55x, MPC5566, MPC5674)
I am not sure how similar they are, but the Power PC chips usually have ~ 64 buffers per CAN circuit, and most people do not multiplex the buffers. You could be seeing just the opposite, shared send buffers?

I'll try some block downloading tomorrow, there are at least 6 groups you could do to catch 18 params @ around 30 ms for the whole trip ( I swear I was getting response @ 5ms)




#1
paramname=ECT paramid=0x808653
paramname=IAT paramid=0x80866D
paramname=MAT paramid=0x808672

#2
paramname=TPS paramid=0x80870D
paramname=Load Error paramid=0x80870F
paramname=PSIG paramid=0x80872E
paramname=RPM paramid=0x80875c
paramname=Load paramid=0x808784
paramname=MAF paramid=0x8087F8
paramname=Speed paramid=0x8087FF

#3
paramname=STFT paramid=0x8088BO
paramname=LTFT In Use paramid=0x8088c1
paramname=AFR MAP paramid=0x80890d

#4
paramname=TimingAdv paramid=0x808A1F
paramname=Knock_Sum paramid=0x808A63

#5
paramname=AWGDC paramid=0x808b6d

#6
paramname=IPW paramid=0x80AA88
paramname=Barometer paramid=0x80AA4D
















conditionrpn = RPM,1,>=
action = start

conditionrpn = RPM,0,==
action = stop
hpd_wally
 
Posts: 22
Joined: Fri Aug 13, 2010 5:40 pm

Re: EVO X GSR Logging -->> CCP?

Postby hpd_wally » Sun Sep 05, 2010 3:35 am

Just picked up a copy of ISO14230 pdf's

Now this makes sense <:

Can we run Commands 0x21, read local identifier?

I have a good feeling I am going to be sitting in my car all day tomorrow
hpd_wally
 
Posts: 22
Joined: Fri Aug 13, 2010 5:40 pm

Re: EVO X GSR Logging -->> CCP?

Postby Tephra » Sun Sep 05, 2010 3:37 am

yeah $21 works fine..

and yes depending what sub pid you request you will get multiple return bytes back... but only upto 4 i think...
Tephra
 
Posts: 59
Joined: Mon Aug 27, 2007 2:16 am

Re: EVO X GSR Logging -->> CCP?

Postby hpd_wally » Mon Sep 06, 2010 8:32 am

Wifes coming back in town, I ran out of time to play with big blocks...


I did confirm that I can sample ~ 200 mode 23 request per second. I am using a canusb.com adapter, and not the openport 2. It has a message callback function that triggers on any message, so as long as I send a new packet out in under 1ms or so, I can stay well above 180 samples per second, which is giving my 20Hz data <:
hpd_wally
 
Posts: 22
Joined: Fri Aug 13, 2010 5:40 pm


Return to Openport Stand-Alone Logging Beta

Who is online

Users browsing this forum: No registered users and 2 guests

cron