Change CAN ID Mapping on the Fly

[tr.gt]

Hey,

we are currently developing a tester and our ECU changes the addressing when switching to the ECUProgrammingSession.

The ECU jumps to the bootloader when switching to the programming session and the bootloader uses different addressing information.

Here some example trace:

Code: Select all

;   Message Number
;   |         Time Offset (ms)
;   |         |        Type
;   |         |        |        ID (hex)
;   |         |        |        |     Data Length Code
;   |         |        |        |     |   Data Bytes (hex) ...
;   |         |        |        |     |   |
;---+--   ----+----  --+--  ----+---  +  -+ -- -- -- -- -- -- --
     1)      8970.6  Rx         02F1  8  02 10 02 00 00 00 00 00 
     2)      8996.0  Rx         04F1  8  03 7F 10 78 FF FF FF FF 
     3)      9040.5  Rx         0400  8  06 50 02 48 53 05 52 FF

The ECU responses with response pending on the first address (0x4F1), jumps to the bootloader and then returns a positive repsonse to a different address (0x400).

Is it possible to changes the CAN ID mappings in the middle of this request <-> response pair?

I tried to realize it with waitForSingleMessage() etc. to wait for the response pending, change the mapping and waitForService() (with adjusted request), but with no luck.

Do you have any hints or samples to solve this problem and how to correctly use the waitFor... functions.

Thanks,
Tobias

[K.Wagner]

Hello Tobias,

You can add several maps. Did you try to add a mapping for the case you mentioned (0x400)?

[tr.gt]

Hello Keneth,

yes I did. However it isn't possible to associate two CAN IDs with on tester UDS address, is it?

Adding the new addresses will end up to something like:

Tester App: CAN: 0x4F1, UDS: 0x01
ECU App: CAN: 0x2F1, UDS: 0x02

Tester Bootloader: CAN: 0x400, UDS: 0x03
ECU Bootloader: CAN: 0x200, UDS: 0x04

I can add these mappings. But how to switch the PUDS_PARAM_SERVER_ADDRESS value form 0x01 to 0x03?

What I tried:
1. Send request
2. Wait for "Response Pending" respone on 0x4F1 (waitForSingleMessage(...))
3. Set new mappings and/or PUDS_PARAM_SERVER_ADDRESS
4. Wait for positive response on 0x400

Do you see any change to listen to several CAN IDs for one UDS address or switch the PUDS_PARAM_SERVER_ADDRESS in the middle of the request-response pair?

Thanks,
Tobias

[F.Vergnaud]

Hello Tobias,

In fact you can add as many mappings as you want as long as it is unique.
Uniqueness depends on the CAN ID, the format addressing and/or the target addres and/or the remote address:
- with NORMAL format addressing, only the CAN ID must be unique.
- with EXTENDED format addressing, the CAN ID and the target address must be unique.
- with MIXED format addressing, the CAN ID and the remote address must be unique.

To sum up the following mappings (which use the same previous source and target address) should be fine in your case:

Code: Select all

// Tester to ECU
TPCANTPStatus s = CANTP_AddMapping( ch, 0x2F1, 0x4F1,
                                          PCANTP_ID_CAN_11BIT,
                                          PCANTP_FORMAT_NORMAL,
                                          PCANTP_MESSAGE_DIAGNOSTIC,
                                          0x01, 0x02,
                                          PCANTP_ADDRESSING_PHYSICAL,
                                          remoteUds );
// ECU to Tester
s = CANTP_AddMapping( ch, 0x4F1, 0x2F1,
                            PCANTP_ID_CAN_11BIT,
                            PCANTP_FORMAT_NORMAL,
                            PCANTP_MESSAGE_DIAGNOSTIC,
                            0x02, 0x01,
                            PCANTP_ADDRESSING_PHYSICAL,
                            remoteUds );

// Tester Bootloader to ECU Bootloader
TPCANTPStatus s = CANTP_AddMapping( ch, 0x400, 0x200,
                                          PCANTP_ID_CAN_11BIT,
                                          PCANTP_FORMAT_NORMAL,
                                          PCANTP_MESSAGE_DIAGNOSTIC,
                                          0x01, 0x02,
                                          PCANTP_ADDRESSING_PHYSICAL,
                                          remoteUds );
// ECU Bootloader to Tester Bootloader
s = CANTP_AddMapping( ch, 0x200, 0x400,
                            PCANTP_ID_CAN_11BIT,
                            PCANTP_FORMAT_NORMAL,
                            PCANTP_MESSAGE_DIAGNOSTIC,
                            0x02, 0x01,
                            PCANTP_ADDRESSING_PHYSICAL,
                            remoteUds );

Regards,

[tr.gt]

Hello Fabrice,

thank you for our answer.

While setting mappings for tester outgoing messages, the last set mapping overrides the previous ones. This makes sense and we can handle that.

For incoming message the multiple mappings seem to work.

However, I have some problems regarding the PUDS_PARAM_SERVER_ADDRESS. I set it like you recommended in my last post (http://www.peak-system.com/forum/viewtopic.php?f=182&t=1446). I get some strange behavior setting the value. Sometimes is seems to work and sometimes not.

I also tried the default address (0xF1) without setting PUDS_PARAM_SERVER_ADDRESS and the tester does not send any message.

My plan to solve the whole problem:
* use fixed test UDS address, say 0xF1
* use some target UDS address, say 0x01
* set PUDS_PARAM_SERVER_ADDRESS to 0xF1
* set outgoing mapping: current CAN ID (0x2F1) -> Tester UDS (0xF1)
* set incoming mappings:
* CAN ID App(0x4F1 ) -> ECU UDS (0x01)
* CAN ID Bootloader(0x400 ) -> ECU UDS (0x01)

If ECU changes to Bootloader
* remove outgoing mapping: CAN ID (0x2F1) -> Tester UDS (0xF1)
* set outgoing mapping: CAN ID (0x200) -> Tester UDS (0xF1)

If ECU changes to App
* remove outgoing mapping: CAN ID (0x200) -> Tester UDS (0xF1)
* set outgoing mapping: CAN ID (0x2F1) -> Tester UDS (0xF1)

But as mentioned above I have massive problems setting PUDS_PARAM_SERVER_ADDRESS.

Here is my current version without setting the mutliple mappings for incoming:

Code: Select all

Message setUdsAddressMapping( Api::CanInterface::Channel channel,
                              unsigned long source,
                              unsigned long target )
{
   unsigned char ch = toPcanChannel( channel );

   unsigned char sourceUds = PUDS_SERVER_ADDR_TEST_EQUIPMENT;
   unsigned char targetUds = mapToUdsAddress( target );
   unsigned char remoteUds = 0x00; // TODO???

   std::cout << "source " << std::hex << (int) sourceUds << std::endl;
   std::cout << "target " << std::hex << (int)targetUds << std::dec << std::endl;

   // Set the "server address" for the UDS driver. If not set to the source
   // (tester), the driver won't forward the messages!
   // See: http://www.peak-system.com/forum/viewtopic.php?f=182&t=1446
   TPCANTPStatus s = UDS_SetValue( ch, PUDS_PARAM_SERVER_ADDRESS,
                                   &sourceUds, 1);

   if ( s != PCANTP_ERROR_OK )
   {
      return toMessage( s );
   }

   // TODO: How to set the different formats, addressing? In the Config?

   // When source sends the outgoing CAN ID must be the target address.
   s = CANTP_AddMapping( ch, target, source,
                         PCANTP_ID_CAN_11BIT,
                         PCANTP_FORMAT_NORMAL,
                         PCANTP_MESSAGE_DIAGNOSTIC,
                         sourceUds, targetUds,
                         PCANTP_ADDRESSING_PHYSICAL,
                         remoteUds );

   std::this_thread::sleep_for( std::chrono::milliseconds( 50 ) );

   if ( s != PCANTP_ERROR_OK )
   {
      return toMessage( s );
   }

   // When target sends back the incoming CAN ID must be the source address.
   s = CANTP_AddMapping( ch, source, target,
                         PCANTP_ID_CAN_11BIT,
                         PCANTP_FORMAT_NORMAL,
                         PCANTP_MESSAGE_DIAGNOSTIC,
                         targetUds, sourceUds,
                         PCANTP_ADDRESSING_PHYSICAL,
                         remoteUds );

   std::this_thread::sleep_for( std::chrono::milliseconds( 50 ) );

   return toMessage( s );
}

The function mapToUdsAddress use some internal singleton to provide unique uds addresses.

The above code does not work currently. It is not possible to send any message.

What's wrong here?

Thanks,
Tobias

[F.Vergnaud]

Hello Tobias,

You are right, I was a bit to quick to respond in my previous answer and the last set of mapping overrides the previous ones..
I have made a simulation to check your use case and here is the right configuration:
- Test equipment address is 0x10, ECU address is 0x01 and ECU "Bootloader mode" address is 0x02. Using a different address for the ECU in bootloader mode allows you to define the mappings once and for all.

Code: Select all

	// Tester to ECU
	TPCANTPStatus s = CANTP_AddMapping(Channel, 0x2F1, 0x4F1,
		PCANTP_ID_CAN_11BIT,
		PCANTP_FORMAT_NORMAL,
		PCANTP_MESSAGE_DIAGNOSTIC,
		0x10, 0x01,
		PCANTP_ADDRESSING_PHYSICAL,
		0x00);
	// ECU to Tester
	s = CANTP_AddMapping(Channel, 0x4F1, 0x2F1,
		PCANTP_ID_CAN_11BIT,
		PCANTP_FORMAT_NORMAL,
		PCANTP_MESSAGE_DIAGNOSTIC,
		0x01, 0x10,
		PCANTP_ADDRESSING_PHYSICAL,
		0x00);	

	// Tester to ECU Bootloader
	s = CANTP_AddMapping(Channel, 0x200, 0x400,
		PCANTP_ID_CAN_11BIT,
		PCANTP_FORMAT_NORMAL,
		PCANTP_MESSAGE_DIAGNOSTIC,
		0x10, 0x02,
		PCANTP_ADDRESSING_PHYSICAL,
		0x00);
	// ECU Bootloader to Tester
	s = CANTP_AddMapping(Channel, 0x400, 0x200,
		PCANTP_ID_CAN_11BIT,
		PCANTP_FORMAT_NORMAL,
		PCANTP_MESSAGE_DIAGNOSTIC,
		0x02, 0x10,
		PCANTP_ADDRESSING_PHYSICAL,
		0x00);

The problem you were having is that our UDS API defines standard mappings used for OBD communications:
- Functional request using 11 bits CAN identifier and normal addressing, from External Test Equipment
address (0xF1) to OBD functional address,
- Physical requests and responses using 11 bits CAN identifier and normal addressing, between the External
Test Equipment address (0x01) and standard ECU addresses (ECU 0x01 to 0x08)

This results in several mappings using a different CAN ID but with similar network address information which is not good as the first entry found will be used.

Concerning your code, I think you also have swapped the source and target address. To simplify CANTP_Mapping only defines a entry stating that for [a source address, a target address, a format type and a message type] a CAN ID is associated, with the above example it means:
- First mapping: message from address 0x10 to address 0x01 with normal addressing and a diagnostic message will use CAN ID 0x2F1 (and if CAN messages are segmented the other side will use CAN ID 0x4F1 to control ISO-TP communication)
- Second mapping: any messages with CAN ID 0x4F1 will get the following network information: source is 0x01, target is 0x10, etc. (and again if CAN messages from this source are segmented, the client will use CAN ID 0x2F1 to control ISO-TP communication).

[tr.gt]

Hello Fabrice,

thank you for your answer. I will try your suggestion, provide you feedback.

Regarding the standard mappings, I just removed them:

Code: Select all

   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_FUNCTIONAL_REQUEST );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_1 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_1 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_2 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_2 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_3 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_3 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_4 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_4 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_5 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_5 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_6 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_6 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_7 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_7 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_REQUEST_8 );
   CANTP_RemoveMapping( ch,  PUDS_ISO_15765_4_CAN_ID_PHYSICAL_RESPONSE_8 );

I did this as I started experimenting with the addressing. Is this helpful or I can just keep these mappings?

Regards,
Tobias

[F.Vergnaud]

Hello Tobias,

When an ISO-TP message is received internally by the ISO-TP API, it will check the received CAN ID against a dictionnary of mappings. So if you plan to add many mappings, I would say to remove the standard mappings : lesser items in the dictionnary will slightly improve performances. Otherwise it is not necessary.