+1

XC43 System mismatch with Newer MD4-7

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

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.

+1

I exactly have the same issue. XC43 not working, and text "Firmware Update" in System menu > Module. Solved by First connect XC43 to canbus B, upload software (IQANdesign 7.00) again,  and then switch back to canbus C again.

MD-4-7 and XC43 are recently buyed from Parker.

With 7.00 in the MD4, the the XC4 update should have worked also on CAN-C. 


In the module, the MD4 info page should say ccCAN version 2.05. 

Gustav, This morning I had the same problem again. Not possible to upgrade the firmware of the XC43.

I have to swap the CAN port to B and change the program. After that I put everything back to the CAN C bus and was working fine. We use a new ordered MD4-7 and XC43. IQANdesign 7.01

I also restart the system several times, but without result.

Is there anything I can do, without changing the software?

Image 4191

There was a problem with sending XC4 updates over CAN-C/-D, but with 7.01 in the MD4, the MD4 will have the latest firmware for CAN-C /-D. You can check on the MD4 module info in the menu system to see what it says on ccCAN; it should say 2.05.

XC4 firmware update occurs on system startup. If the MD4 was powered up after the XC4 modules that can explain why the XC4 updated did not work the first time.

Thanks Gustav, Waht do you exactly means by "If the MD4 was powered up the XC4 modules that can explain why the XC4 updated did not work the first time".

We did restart the system several times, but without succes. Do I have to restart in a soecial order?

The master module tries to update XC4 modules before it starts the application. 

The next attempt will be at the next startup of the master. So the XC4 must be powered on before or at the same time as the MD4. Powering up at the same time is of course the easiest.  

Ok, strange, MD4 is on the same 24Vdc supply as the XC4, so powered at the same time. If we have this problem again, I will try to unplug the MD4, so that I'm sure that the XC4 is started before the MD4 starts. I will let you know. Thanks anyway.

I agree, that is strange. 

One thing you can also do is check the MD4 module info page, at the bottom it will say ccCAN version. This should show 2.05. 

Also see 

MD4 firmware for CAN-C/D, use 6.08.30 or newer to update / Knowledge base / IQAN

Turns out there was a problem with the update of ccCAN2 in version 7. Fixed with the introduction of in 7.02.31

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