This is a follow-up on a previous question that I have asked before, after making some changes as suggested through valuable inputs by other members, but with the problem persisting.

In a nutshell, the situation is as follows: I have a system that controls a lot of solenoids. Wires from the switching circuitry are rather long - between 2 to 10 meters. The heart of the system is a Microchip PIC32 microcontroller.

As stated in my previous question, the PIC undergoes intermittent resets when the solenoids are switched. This happens at random and not necessarily with a particular switching sequence.

The system consists of two PCBs - one contains all of the switching circuitry (from here on referred to as the "host" PCB), and the other (from here on referred to as the "core" PCB) contains only the PIC32 and a few other ICs (EEPROM and USB/UART bridge). The idea of having the PIC32 on a separate PCB is to make it easier to maintain the system in the event of a software bug/update, where only the small PCB containing the PIC32 can be replaced, and not the whole system (to make it a modular design).

Having said this, the core PCB is rather small - 66 x 38 mm. All of the unrouted area on this PCB is filled with a ground plane on both sides. Furthermore, there is only one single pin on this PCB that connects to the power and ground signals to the host PCB.

On the host PCB, all of the switching circuitry is optically isolated from the core PCB. There are also separate power connections between the two sides of the host PCB (thus, the two grounds are also separated). The system does make use of only one external power supply, with separate power connections for the two parts of the host PCB that are branched as close to the power supply as possible. The location where these power wires meet are thus as far away as possible from the circuitry to help prevent the inductive kickback from the solenoids coupling into the power supply for the core PCB.

This is an excerpt from the core PCB circuit showing the PIC pins in question:

PIC32 power pins

This is the actual PCB layout of the circuit described above:


So far, I have taken the following steps to keep the power supply to the core PCB as clean and constant as possible and to prevent the unintentional resets:

  • Use Schottky diodes at the switching circuitry side of the host PCB for faster response against the inductive kickback caused by switching the solenoids.
  • Decoupling capacitors (C2-C7 in the above circuit) for all the power pins of the PIC on the core PCB, including at the MCLR pin.
  • Replacing the pull-up resistor at the MCLR pin (R1 in the above circuit) with a short circuit to force it high at all times.
  • Added a 1000 uF capacitor across the power supply for the FET drivers ("Local battery concept" as recommended by user analogsystemsrf in the previous question)
  • Placing a common-mode choke in the power supply circuit for the core PBC, as in the circuit below:

PIC power supply

As mentioned, the resets still occur. I can only think of the following to further attempt the prevention of the resets:

  • Add a big capacitor (in the order of 1000 uF) across the main power and ground pins on the core PCB that come from the host PCB.
  • Add additional decoupling capacitors of various values to all of the power pins.
  • Use a completely separate power supply for the core PCB (this would be a last resort if all else fails).

Although I can perhaps just use a completely separate power supply for the core PCB, I do not want to resort to that unless I really have no other option. I am convinced that this problem can be solved by other means.

Please comment and provide some guidance on my options that I have listed here. Also, if there is anything else that anybody can recommend, that will be greatly appreciated.

  • \$\begingroup\$ I remember some time ago having a problem determining the real reset reason using EXTR so this is just a thought in case you've got your mindset stuck with a hardware problem - try it all with the solenoids disconnected if you haven't already to make sure it's not an obscure firmware problem. \$\endgroup\$
    – PeterJ
    Aug 15, 2017 at 12:18
  • \$\begingroup\$ @PeterJ: I haven't experienced the same reset issue with the solenoids disconnected. That is why I am focusing on the hardware the whole time. However, you do make a valid point about the firmware. It has also crossed my mind that there could be a very slight chance that it is firmware related. You mention that you had a similar problem, could you perhaps indicate if it was indeed a firmware problem? If it was, could you also describe how you solved it? \$\endgroup\$
    – wave.jaco
    Aug 15, 2017 at 12:31
  • \$\begingroup\$ It was going back a while and can't remember the exact details but in general I remember EXTR was being set for other reset reasons - but it wasn't that critical for what I was working on just threw me a bit while debugging a problem that was elsewhere, I just thought it might have thrown you out as well. Just remembered - it was a watchdog reset problem but for some reason that was being set but didn't look further why when I found that problem. \$\endgroup\$
    – PeterJ
    Aug 15, 2017 at 12:35
  • \$\begingroup\$ @PeterJ: Thanks. I will have a look at the watchdog timer configuration and the other configuration bits and see if something is out of line. I only focused on the hardware so far and it is perhaps worthwhile to have a look at the firmware. \$\endgroup\$
    – wave.jaco
    Aug 15, 2017 at 13:18
  • \$\begingroup\$ Magnetic fields? FET drivers upsetting GND? \$\endgroup\$ Aug 15, 2017 at 18:09

2 Answers 2


I suspect it's going to be caused by high frequency power noise. You can also use an oscilloscope to confirm this. If this is the issue, I would switch to a four layer board so that the power is routed through a plane. Additionally, you might want to add lower value capacitors targeted to the frequency of the noise.


If it was me, I would use opto ICs to drive the solenoid valves with back EMF blocking diodes. This would stop the sudden decrease of power to the micro and put less strain on the circuit. Still drive the optos with FETs or darlington drivers.

If you're using a PIC32, then you could interface with a secondary PIC to control the solenoid valves - this way you can recover the secondary and primary PIC by a protocol between the two (fail safe). I have used SIL 5V relays and opto/FET switches with no problems. Some of the units I developed are still running 2 years solid, without being turned off - albeit these are PIC18s, but it proves how robust these PICs are.

In another project, I had failed to CLRWDT() during a lengthy process and yes, it reset, so check that you have plenty of them in your code.

Also check your timings for USARTs and any interrupts causing your program to be busy, include CLRWDT() in your interrupts too if this is where the program fails.

I would advise getting the interrupt - dealing with it and getting out as quick as possible so that you do not miss another interrupt. Timing is a pain and yes, I have had to go through code time and time again due to typos etc. Good look.

Hope this helps.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.