CompactLogix 1769-L24ER Series B Unsupported Firmware

[luanke]

Hello all, and thank you in advance for any assistance you may be able to provide! This is my first post, so if I need to reformat or change anything, please let me know and I will do so.

Quick Synopsis:
We unintentionally flashed a CompactLogix 1769-L24ER-QB1B Series B controller with firmware 30.011, which is unsupported by the Series B. Now it is seemingly stuck in a boot loop with no USB or ethernet connectivity available, and I get no response from attempting to reset the controller via faceplate reset button hold.

Longer Explanation:
My company used CompactLogix 1769-L24ER-QB1B (series A) controllers in a particular machine line that we produced for many years (and still support). However, now that the same controller in series A is no longer widely available, we must provide Series B controllers if a replacement PLC is needed in an existing machine. The most recent program used in the Series A controllers was made using RSLogix 5000 version 30, with controllers using firmware 30.011. We recently (~3 months ago) replaced a customer's Series A controller with a Series B for the first time, upgrading the firmware to 30.016 in the process (the lowest v30 firmware supported by the Series B), and they were back up and running with no issues.

Last week, I provided files to this customer to reload the program in their PLC via the SD Card. However, the SD Card backup files we sent them were created on a Series A controller running firmware 30.011. When I spoke to our local distributor and explained the situation (including the firmwares in use and the Series A vs B controllers), I was told this should be no problem and should cause no issues.

In preparing the SD card backup files for use, I verified that the XML config file within the "CurrentApp" folder dictated the following options for restoring the backup:
<ProgramLoadOption>
<ProgramLoadMode>ALWAYS_ENET_RESTORE</ProgramLoadMode>
and
<FirmwareSupervisor>
<UpdateMode>IN_ACTIVE</UpdateMode>

I also made the unfortunate choice to alter the "Load.xml" in the "Logix" folder from saying <MaximumRevision>2 to <MaximumRevision>3 to allow the controller to load the backup.

I see in hindsight that it is likely that the firmware "UpdateMode" was ignored and the firmware on SD Card flashed anyway since the program and controller revisions did not match.

The controller then went through the process of loading the SD Card backup files, and promptly defecated in its sleeping quarters. It now appears to be stuck in a boot loop, wherein upon power up the OK light is solid red for about 20 seconds before each of the other lights light up in sequence, but then it goes directly back to the OK light being solid red for another 20 seconds, followed by the same light sequence, followed by the OK light solid red for 20 seconds, etc. I have no ethernet or USB connectivity, and I have tried resetting using the faceplate button to no avail. I have also tried flashing a program and firmware via known-good SD Card backup which has a supported firmware (tried 30.016 and 32.015) and program on it from another controller with no effect.

I am pretty sure that the controller needs to have its firmware re-flashed at this point by someone who has the equipment necessary to connect directly to the board, but before we purchase a Rockwell support subscription (we do not use AB equipment often enough any more to justify the ongoing expense) or talk to a repair shop, does anyone happen to have any thoughts or ideas?

Any help is greatly appreciated.

 

[tarik1978]

Try this:

How to Soft and Hard Reset a CompactLogix 5069 PLC

Eric Hanley, Automation, HMI & Network Specialist at ES&E explains how to reset a PLC. A stage one reset will clear the application program and memory while ...

youtu.be

 

[luanke]

Try this:

How to Soft and Hard Reset a CompactLogix 5069 PLC

Eric Hanley, Automation, HMI & Network Specialist at ES&E explains how to reset a PLC. A stage one reset will clear the application program and memory while ...

youtu.be

Thank you for the suggestion! Sadly, I have tried the same reset procedure shown in the video multiple times with no results. Unfortunately the 5370 controllers (like the 1769-L24 I have) don’t have the two stage reset like the 5380 Controllers and some others have.

I was hoping there may be another way to accomplish the same thing on the 1769-L24 controllers, but I have not found anything yet.

 

[TJKraynik]

Do you have another controller in which you can program another SD card with valid 30.016 firmware in it and configure it to load on power cycle and see if that corrects the issue?

 

[luanke]

Do you have another controller in which you can program another SD card with valid 30.016 firmware in it and configure it to load on power cycle and see if that corrects the issue?

I tried that also, with no success. Using a different (functional) series B controller that was running 30.016 firmware, I stored a project to SD card using Studio5000, setting it to load on power up, including the firmware. However, nothing changed on the nonresponsive controller, and it was still going through the same boot / light sequence loop, with no indication of SD card activity other than the brief writing of a fault log to the SD card.

 

[luanke]

Update for reference:

Whenever an SD card is present on power up of the problematic controller, a folder is created in the SD card "Logix" folder structure called "Fault" (directly located within a folder that is named as the serial number of the controller). The controller writes some files into a folder called "Log" inside this folder each time the boot sequence loop occurs, including a 256byte file "FaultRecordN.bin" (where 'N' is the number of times the boot sequence loop is allowed to run - for example, if I power up the controller and let the boot loop occur 3 times, there is a "FaultRecord1.bin", "FaultRecord2.bin", and FaultRecord3.bin" - each 256 bytes), as well as "Executive.bin" and another ".bin" file named after the serial number of the unit.

I compared the "Executive.bin" from this folder with the 30.011 firmware .bin file and they are the same file. So it would seem to me that the controller did indeed try to update its firmware to version 30.011, even though the xml config file had the FirmwareSupervisor set to "IN_ACTIVE", which is likely the main cause of my problem. My best guess is that the controller is attempting to load the 30.011 firmware on power up, but is failing and causing the controller to reboot.

I am unsure what the serial .bin file is, as it is larger than either the Executive.bin or the NetLinx.bin firmware files, but smaller than the two combined, and it contains mostly zeroed out data anyway (most of the bytes are are 0x00).

I am unable to read the 256 byte FaultRecord.bin files, as even with a hex editor, they do not hold any intelligible strings of characters. My guess is that you must have some proprietary software or prior knowledge of their structure to decipher their meaning (or maybe just a better understanding of binary file structure than I have lol).

 

[TJKraynik]

Did you ever end resolving your issue?

 

[luanke]

Did you ever end resolving your issue?

Unfortunately the issue has not yet been resolved. From what I understand, even if we were to put in a Rockwell support ticket to get it repaired through them, a repair requiring reflashing of the firmware would likely cost us just as much as buying a brand new unit. I have alternatively looked into several different "PLC repair" services, but once I explain that the chip appears to be caught in a boot loop and that the firmware needs to be reflashed, I was told by each that they did not have the capability to repair an issue like this.

After some basic research, I believe that if one were to perhaps use JTAG debugging to force the executive loader to load the base firmware instead of the OS firmware, a functional OS firmware could then be loaded into the unit like normal via ControlFlash. That is, of course, assuming that this JTAG functionality has not been disabled by the factory at Rockwell (It appears that some of the newer controller lines have this ability removed by Rockwell before shipping). However, I do not have the hardware necessary to perform this type of repair (or approval from my bosses to tinker with it), and the repair services I have contacted do not appear to have the ability (or desire?) to do so either.

 

[tlf30]

To me, this sounds like a bug in the firmware that even allowed it to be put in this state to begin with. I would require RA to fix the issue at no cost or replace the controller.