Major crash of kernel and/or firmware. What happened?

This was sent to me by a Runtime Support Team member:

Please try a Type 2 reset using the procedure described on page 32 of the user manual. Afterwards, please wait a long time (up to 30 minutes) before cycling power to the device again, just to make sure the recovery procedure has finished.I have managed to recover a device that was in the state you describe, but I had to repeat this procedure a few times.However, I know there are others who have not been able to successfully recover a PLC from this state. If that is the case for you, then I am afraid you will need to contact the Phoenix Contact office in your country to arrange a repair or replacement. If you are able to tell me what country you are in, I can notify someone in the relevant office about this issue and ask them to contact you.My next question is: Does Phoenix Contact know what puts a PLC into this state? Is it avoidable?

The reason I wrote this as a direct message to you is because we need to know what country you are in, in case the device needs to be returned. If you are happy to tell us what country you are in, in a public forum, then that’s fine.

Does Phoenix Contact know what puts a PLC into this state?No. This happens very rarely, we have not been able to reproduce this problem, and our developers need a unit that displays this behaviour in order to investigate the problem further. That’s why we need to know what country you are in, so we can arrange the return and replacement of the device.
Is it avoidable?Since we don’t know the cause, we also don’t know how to avoid this at the moment.
This shouldn’t be in a direct message to me. It should be in the forum so that people know the solution to a problem.What we generally do in cases like this, to avoid a lengthy conversation (which might include personal information) in a public forum, is that we contact the person directly and if/when we resolve the problem we post the solution back to public forum, so everyone can see the solution to the problem. However, if you would like to have this conversation in public, that’s also fine.
Please let us know what country you are in, so I can ask someone in the local Phoenix Contact office to contact you.

I’m in the US. I’m going to restore the controller with the same code I had running before to see if I can recreate the issue. It was a very simple program, just writing to an integer in the PLC runtime as fast as it could with rsc from a python program run at boot as a service.

Thanks for the info.

If a Type 1 or a Type 2 reset restores the device to working order, then it is not the rare problem that I mentioned - in those cases, the device could not be recovered. Instead, it may be an application issue. If the problem can be reproduced reliably, then we have a good chance of identifying the cause.

Thanks for the info.</p>If a Type 1 or a Type 2 reset restores the device to working order, then it is not the rare problem that I mentioned - in those cases, the device could not be recovered. Instead, it may be an application issue. If the problem can be reproduced reliably, then we have a good chance of identifying the cause.</p>

Hello, Martin.
It looks like I’ve come across the rare case you mentioned.
AXC F 1152
Boot flashing red. There is no other indication.
The PLC is not pinged and is not defined as a network device.
Resetting type 1 and type 2 gives no results.

This PLC has been in operation since the end of last year, and this problem appeared a few days ago.
I also want to add that this is not my first project, at the beginning of last year I implemented exactly the same project with similar equipment and program.
I didn’t have any problems with this PLC.
What would you recommend to do in my situation?
I am in Russia. Unfortunately, last month the Phoenix Contact representative office stopped working. And I have nowhere to turn now.
If you provide the address, I can send you this PLC, if it is still possible. Maybe this one will somehow help to deal with this rare and unpleasant problem.

With respect,
Roman Yun