"WHY DOES THE SECOND EXECUTION NOT WORK?"

[mpersisth]

"WHY DOES THE SECOND EXECUTION NOT WORK?"

[root@localhost tjz]# candump vcan0
vcan0 7E0 [3] 02 10 03
vcan0 7E8 [7] 06 50 03 00 96 00 96
vcan0 7E0 [3] 02 11 01
vcan0 7E8 [3] 02 51 01

vcan0 7E0 [3] 02 10 03

[root@localhost test]# python3 example.py
2024-10-11 11:27:25 [INFO] Connection: Connection opened
2024-10-11 11:27:25 [INFO] UdsClient: DiagnosticSessionControl<0x10> - Switching session to extendedDiagnosticSession (0x03)
2024-10-11 11:27:25 [DEBUG] Connection: Sending 2 bytes : [1003]
2024-10-11 11:27:25 [DEBUG] Connection: Received 6 bytes : [500300960096]
2024-10-11 11:27:25 [INFO] UdsClient: Received positive response for service DiagnosticSessionControl (0x10) from server.
2024-10-11 11:27:25 [INFO] UdsClient: ECUReset<0x11> - Requesting reset of type 0x01 (hardReset)
2024-10-11 11:27:25 [DEBUG] Connection: Sending 2 bytes : [1101]
2024-10-11 11:27:25 [DEBUG] Connection: Received 2 bytes : [5101]
2024-10-11 11:27:25 [INFO] UdsClient: Received positive response for service ECUReset (0x11) from server.
2024-10-11 11:27:26 [INFO] Connection: Connection closed
[root@localhost test]# python3 example.py
2024-10-11 11:27:31 [INFO] Connection: Connection opened
2024-10-11 11:27:31 [INFO] UdsClient: DiagnosticSessionControl<0x10> - Switching session to extendedDiagnosticSession (0x03)
2024-10-11 11:27:31 [DEBUG] Connection: Sending 2 bytes : [1003]
2024-10-11 11:27:32 [DEBUG] Connection: No data received: [TimeoutException] - Did not received ISOTP frame in time (timeout=0.5 sec)
2024-10-11 11:27:32 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. P2 timeout time has expired (timeout=0.500 sec)
2024-10-11 11:27:32 [INFO] Connection: Connection closed

Unhandled event1: 15
Unhandled event1: 15
Unhandled event1: 15
Unhandled event1: 15
Unhandled event1: 15
Unhandled event1: 15
^CSIGINT received
server exiting
[root@localhost linux_server]#
[root@localhost linux_server]#
[root@localhost linux_server]#
[root@localhost linux_server]# make clean
rm -f server
[root@localhost linux_server]#
[root@localhost linux_server]#
[root@localhost linux_server]# ls
main.c Makefile
[root@localhost linux_server]#
[root@localhost linux_server]#
[root@localhost linux_server]# make
cc -DUDS_TP_ISOTP_SOCK=1 -g ../../release/iso14229.c main.c -o server
[root@localhost linux_server]#
[root@localhost linux_server]#
[root@localhost linux_server]#
[root@localhost linux_server]# ./server
server up, polling . . .
2040392907, recv, 0x7e0 (phys), 10 03
2040392908, sends, (phys), 50 03 00 96 00 96
2040392925, recv, 0x7e0 (phys), 11 01
2040392959, sends, (phys), 51 01

static uint8_t fn(UDSServer_t *srv, UDSServerEvent_t ev, const void *arg) {
switch (ev) {
case UDS_SRV_EVT_DiagSessCtrl:
return kPositiveResponse;
case UDS_SRV_EVT_EcuReset:
return kPositiveResponse;
case UDS_SRV_EVT_SessionTimeout:
return kServiceNotSupported;
case UDS_SRV_EVT_DoScheduledReset:
return kServiceNotSupported;
default:
printf("Unhandled event1: %d\n", ev);
//TEST_INT_EQUAL(UDS_SRV_EVT_DoScheduledReset, ev);
return kServiceNotSupported;
}
}

[driftregion]

Hi @mpersisth , after the server positively responds to an ECU reset request, the standard mandates that no further responses are sent until the server resets.

[mpersisth]

Will the server simulate a reboot or do I need to manually restart the server to begin diagnostics?

[driftregion]

The server should reboot on receiving UDS_SRV_EVT_DoScheduledReset. In the handler for this event, your server should either reboot or call UDSServerInit(...) to simulate a reboot.

[mpersisth]

hello

[mpersisth]

hello，
case UDS_SRV_EVT_EcuReset:
return kPositiveResponse;
case UDS_SRV_EVT_DoScheduledReset: {
uint32_t EcuResetTime = 10000;
sleep_ms(EcuResetTime);
if (UDSTpIsoTpSockInitServer(&tp, "vcan0", 0x7E0, 0x7E8, 0x7DF)) {
fprintf(stderr, "ECU Reset failed\n");
exit(-1);
}
fprintf(stderr, "ECU Reset true\n");
return kPositiveResponse;
}
Don't really understand why UDS_SRV_EVT_DoScheduledReset is being triggered all the time?

[root@localhost linux_client]# ./client
-1194538665, sends, (phys), 10 03
-1194538645, recv, 0x7e8 (phys), 50 03 00 96 00 96
-1194538645, sends, (phys), 11 03
[root@localhost linux_client]#

[root@localhost linux_server]# ./server
server up, polling . . .
-1194538656, recv, 0x7e0 (phys), 10 03
-1194538655, sends, (phys), 50 03 00 96 00 96
-1194538636, recv, 0x7e0 (phys), 11 03
ECU Reset true
-1194528625, sends, (phys), 00 00
ECU Reset true
ECU Reset true
ECU Reset true
ECU Reset true
ECU Reset true

C[root@localhost ~]# candump vcan0
vcan0 7E0 [3] 02 10 03
vcan0 7E8 [7] 06 50 03 00 96 00 96
vcan0 7E0 [3] 02 11 03
vcan0 7E8 [3] 02 00 00

[mpersisth]

Hello,are there any test cases for 36 services?

[driftregion]

hello， case UDS_SRV_EVT_EcuReset: return kPositiveResponse; case UDS_SRV_EVT_DoScheduledReset: { uint32_t EcuResetTime = 10000; sleep_ms(EcuResetTime); if (UDSTpIsoTpSockInitServer(&tp, "vcan0", 0x7E0, 0x7E8, 0x7DF)) { fprintf(stderr, "ECU Reset failed\n"); exit(-1); } fprintf(stderr, "ECU Reset true\n"); return kPositiveResponse; } Don't really understand why UDS_SRV_EVT_DoScheduledReset is being triggered all the time?

[root@localhost linux_client]# ./client -1194538665, sends, (phys), 10 03 -1194538645, recv, 0x7e8 (phys), 50 03 00 96 00 96 -1194538645, sends, (phys), 11 03 [root@localhost linux_client]#

[root@localhost linux_server]# ./server server up, polling . . . -1194538656, recv, 0x7e0 (phys), 10 03 -1194538655, sends, (phys), 50 03 00 96 00 96 -1194538636, recv, 0x7e0 (phys), 11 03 ECU Reset true -1194528625, sends, (phys), 00 00 ECU Reset true ECU Reset true ECU Reset true ECU Reset true ECU Reset true

C[root@localhost ~]# candump vcan0 vcan0 7E0 [3] 02 10 03 vcan0 7E8 [7] 06 50 03 00 96 00 96 vcan0 7E0 [3] 02 11 03 vcan0 7E8 [3] 02 00 00

Hi @mpersisth, it seems you may be resetting the transport, not the server. Please see this example:

iso14229/examples/linux_server_0x27/server.c

Line 114 in 251b16f

if (UDSServerInit(&srv)) {

Hello,are there any test cases for 36 services?

No, there aren't any at the moment.

[mpersisth]

case UDS_SRV_EVT_DoScheduledReset: {
srv->notReadyToReceive = false;
return kPositiveResponse;
}
I think this should be fine, right?

[driftregion]

Sure, that seems OK.

I'd still recommend calling UDSServerInit(&srv), but if you'd like to reach inside the server state, you can do it this way:

case UDS_SRV_EVT_DoScheduledReset: {
srv->notReadyToReceive = false;
srv->ecuResetScheduled = 0;
return kPositiveResponse;
}

The standard says:

This document does not define the behaviour of the ECU from the time following the positive response
message to the ECU reset request until the reset has successfully completed. It is recommended that
during this time the ECU does not accept any request messages and send any response messages.