we are using a PCAN-Ethernet Gateway FD DR, which is communicating with a Linux application via UDP sockets. Our application sends UDP messages to the gateway, which are meant to be forwarded to the connected CAN FD. However, as soon as our application starts to send the UDP packets, the gateway shuts down (LED Status off), tries to restart (LED Status green, but not blinking), but somehow isn't able to start. The LED status doesn't reach the blinking state as long our application is sending UDP packets. Once our application is terminated, the gateway starts as expected.
We exported the configuration (see attachments) and tried the same configuration on another PCAN-Ethernet Gateway FD DR. There it is working fine. Hence we assume that our application and the configuration is fine. Did you ever face such behavior? Do you have any hints or suggestions? Or could this even be a hardware issue?
- Exported gateway configuration
- (4.37 KiB) Downloaded 27 times
I've never seen this behavior yet. Can you provide some further details? Does it always happen on the first message, so even this one is not sent on CAN? Is it the same for both CAN channels?
thank you for the quick reply. We'll have to check these points. I'll get back to you with more information as soon as possible.
I tried to reproduce the behavior in our lab to answer your questions, but actually I wasn't able to. In our lab environment the gateway was working perfectly fine, which leaves me kind of unsatisfied.
I tried to think of possible differences between our system integration (where the issue was seen) and our lab assembly, but did not find something. The only point I came across is, that we do not connect the gateway to any ground potential. It's not connected to a DIN rail and neither Pin 4 of the power supply (shield / top hat rail potential) nor CAN Pins 3 + 4 (CAN-GND and CAN-Shield) are connected. So far we had no issues with leaving those empty, but could you imagine, that this could be a reason for the resets?
Sorry for bothering you with such vague information. Would be great if you would have some further hints.
I can't see any how a missing shield connection could lead to a module reset. The application to create the UDP messages you're using in the lab is the same as in the final system, right?
Is the power supply the same as in the system (same voltage at least)? Is it possible that the UDP messages or the resulting CAN frames have any influence to the power supply?
please see my answers to your questions:
- The application to create the UDP messages you're using in the lab is the same as in the final system, right?
-> Yes, it is.
- Is the power supply the same as in the system (same voltage at least)?
-> It's a different power supply, but with the same voltage (12V).
- Is it possible that the UDP messages or the resulting CAN frames have any influence to the power supply?
-> No, that's impossible.
is the module you're testing now the same one that has shown the failure in the target platform or the second one you tested the configuration with? Was the web interface working right inside the system. How much current can your power supply provide? Are you sure that there wasn't a wiring issue?
- is the module you're testing now the same one that has shown the failure in the target platform or the second one you tested the configuration with?
-> I'm testing the one, which showed the failure in the target platform.
- Was the web interface working right inside the system?
-> As long as I was not sending UDP messages, the web interface was working fine. As soon as I started to send UDP messages, the gateway was resetting. I could not reach the web interface after that anymore. When I stopped to send UDP messages the gateway started again and the web interface became available again.
- Are you sure that there wasn't a wiring issue?
-> Yes, I'm sure. Meanwhile we replaced the gateway by another one, but we kept the cables as they were before. Everything is working fine there.
- How much current can your power supply provide?
-> The gateway is connected to a 12V car battery. Hence it should be able to provide by far enough power in general. However, now that I'm thinking of it, I cannot guarantee that the battery was in a very good state of charge. All I know on that is, that at the same time a second gateway was connected to the same battery. This one was working fine.
is the system that generates the UDP messages also connected to the same battery? Beside power issues I have no idea what should cause resets when receive or process messages. The module takes more current while it is booting then it needs in idle mode. So if the supply was marginal it could be possible that the module resets during boot.
- is the system that generates the UDP messages also connected to the same battery?
-> No, it's connected to a separate power supply.
- Beside power issues I have no idea what should cause resets when receive or process messages.
-> Yes, meanwhile we also got the feeling that this might have been the issue.