Paul Crawford
Newbie level 4
i have built a project to collect data from various sensors. The central computer is an Odroid N2L SBC by Hardkernel running Ubuntu 22.04.1 LTS It acts as database server, web server and data collection server. The data provided by five independent devices is collected via an RS485 network using the Modbus protocol that is connected to the N2L through an RS485 to RJ45 ethernet industrial serial server. Two of the devices are analog to digital DC voltmeters, the third is an analog to digital AC power meter, the fourth is a single phase 240 VAC to three phase variable frequency drive connected to a 370 watt electric motor and the fifth is an ATmega328p MCU.
The MCU mainly collects data from sensors but does have a control function as well that turns on a cut-off relay if a temperature sensor value exceeds a predetermined maximum. The MCU is connected to the RS485 network by a half duplex RS485 to TTL serial converter that is connected to the serial RX and TX ports on the MCU. The software running on the MCU is pure C to retrieve data from the sensors and includes code to receive commands on the RS485 network in pseudo Modbus fashion and transmit the data back to the SBC for processing, saving in the database and preparing presentation as a web page.
There is no problem with any of this system while only the data collection segments are running. The problems start when the SBC sends a command to the VFD to start the motor at a given frequency. When that occurs communication with the MCU is disrupted and resets occur in the MCU. If the MCU were only collecting slowly varying data, it would be tolerable to wait until the VFD is commanded to stop and communication is regained. With the MCU control function getting corrupted by the reset, however, the source of the interference must be determined and corrected or, in the alternative the control function must be reworked to ensure that it continues to operate correctly in spite of the interference.
I am not expecting direct assistance on sorting out the interference issue, but I would appreciate some assistance on exploring the MCU reset. My understanding is that there are only four causes of a reset on the MCU:
1. Power-on
2. External
3. Brown-out
4. Watchdog System
I have added code to the beginning of the MCU initialization to read the MCUSR. I have discovered that when the resets that occur that are coincident with the VFD operation the MCUSR value is always 0x08 indicating a watchdog reset. The SBC can send an external reset to the MCU, independent of the RS485 network, and when it is sent the value of the MCUSR is found to be 0x02 which is correct. The MCU code for this is:
The value of mcusr is sent out to the RS485 network by the MCU with all of the sensor data on request from the SBC.
Since the interference seems to always trigger the Watchdog System Reset Flag, I wanted to try running the code without the WDT. If I comment out the wdt_enable line to get the default setting or explicitly stop the WDT with wdt_disable, there is no response from the MCU to commands sent from the SBC. Having run this code continuously for days without any resets, as long as the motor does not start, I am confident that there is no chance of runaway code or a hang so the watchdog may not be necessary. I realize that I should use it in the end anyway.
So my real question is: How can I prevent the WDT from running while still maintaining the command-response functionality at least as a test?
The MCU mainly collects data from sensors but does have a control function as well that turns on a cut-off relay if a temperature sensor value exceeds a predetermined maximum. The MCU is connected to the RS485 network by a half duplex RS485 to TTL serial converter that is connected to the serial RX and TX ports on the MCU. The software running on the MCU is pure C to retrieve data from the sensors and includes code to receive commands on the RS485 network in pseudo Modbus fashion and transmit the data back to the SBC for processing, saving in the database and preparing presentation as a web page.
There is no problem with any of this system while only the data collection segments are running. The problems start when the SBC sends a command to the VFD to start the motor at a given frequency. When that occurs communication with the MCU is disrupted and resets occur in the MCU. If the MCU were only collecting slowly varying data, it would be tolerable to wait until the VFD is commanded to stop and communication is regained. With the MCU control function getting corrupted by the reset, however, the source of the interference must be determined and corrected or, in the alternative the control function must be reworked to ensure that it continues to operate correctly in spite of the interference.
I am not expecting direct assistance on sorting out the interference issue, but I would appreciate some assistance on exploring the MCU reset. My understanding is that there are only four causes of a reset on the MCU:
1. Power-on
2. External
3. Brown-out
4. Watchdog System
I have added code to the beginning of the MCU initialization to read the MCUSR. I have discovered that when the resets that occur that are coincident with the VFD operation the MCUSR value is always 0x08 indicating a watchdog reset. The SBC can send an external reset to the MCU, independent of the RS485 network, and when it is sent the value of the MCUSR is found to be 0x02 which is correct. The MCU code for this is:
C:
#include <avr/wdt.h>
...
int main(void)
{
cli();
mcusr = MCUSR;
MCUSR = 0;
wdt_enable(WDTO_8S);
...
The value of mcusr is sent out to the RS485 network by the MCU with all of the sensor data on request from the SBC.
Since the interference seems to always trigger the Watchdog System Reset Flag, I wanted to try running the code without the WDT. If I comment out the wdt_enable line to get the default setting or explicitly stop the WDT with wdt_disable, there is no response from the MCU to commands sent from the SBC. Having run this code continuously for days without any resets, as long as the motor does not start, I am confident that there is no chance of runaway code or a hang so the watchdog may not be necessary. I realize that I should use it in the end anyway.
So my real question is: How can I prevent the WDT from running while still maintaining the command-response functionality at least as a test?