0

XC43 System mismatch with Newer MD4-7

Justin Wagner 4 months ago in IQANdesign updated by Gustav Widén (System support) 4 months ago 4

I've been having some very strange issues today with XC43 "System mismatch" errors on a system with an MD4-7 and XC43. We're on IQANdesign 6.01.6. There's 1 XC43 with address 1 on CAN-C. When I load this program on new MD4-7 and XC43 I get the XC43 "System mismatch" error and the XC43 has internal state "Failed 306". The amber LED continuously blinks very quickly.


When I move the XC43 to CAN-A or CAN-B and reload the program, everything works. I then move the XC43 back to CAN-C, reload the program, and everything works.


Having the XC43 on CAN-D seems to result in the same "System mismatch" error.

We've used this same program and these same modules on many other machines without this issue, so looking closer at the MD4-7-T1E2 modules I was testing with, it seems like something changed with the modules with 2023 manufacture dates (2302040070 is the earliest SN that I experienced this issue with). All our modules that are later than 2208040660 don't seem to load the firmware onto the XC43 on CAN-C or CAN-D or something. 2208040660 and earlier have no problem operating the XC43 on CAN-C.


Did something change in the CAN-C and CAN-D ports on the MD4-7 suddenly sometime after SN: 2208040660 that they can no longer load firmware onto expansion modules? Or am I doing something wrong?


This could become a fairly serious issue with replacing XC43 modules in the field in the future. If CAN-C and CAN-D can't load firmware on the modules, we'd need to either reprogram the existing system or make sure the firmware is updated before it ships out. This isn't always easily done and kind of defeats the major advantage of expansion modules (forward/reverse compatibility without reprogramming). And if we can't use CAN-C/D for expansion modules, it severely limits their usefulness, since we're already advised not to use these buses for the diagnostic bus.

Image 3707

We have also seen this problem. On one of our systems we need to move the expansion bus temporarily to CAN B for the firmware update to the XC43's using a temporary program for that purpose, then we can return them to CAN C for operational use. This is not something we can expect field technicians to take care of. We have problems with permanently moving the XC43's to CAN A or B due to wiring harness production / documentation and A / B are already quite busy.

The MD4 has been updated with a new co-processor for handling buses CAN-C/D. 


There were some problems with the new firmware, the symptom with updating XC4 over C-C/D can be solved by updating to 6.08.30, see Release notes - IQANdesign 6.



I've updated to 6.08.30 and the XC43 firmware does now seem to load on CAN-C, but after loading the program onto the machine, I get a No Contact error with the XC43 and a very long blink code. Cycling power to the system twice seems to take care of this No Contact error and communication with the XC43 is restored.

Is this normal behavior? Does the XC43 require two power cycles after being updated to SW version 1.03.7?

+1

Yes, two restarts are expected after updating XC4x from firmware versions <1.03. 

See also Appendix B

Image 3722