Parallax Bs2P40 (SX48BD/TQ) Spontaneous Reboot
chrisdlove
Posts: 53
Hello Parallax forum,
I have seen a few instances where my BS2P40 OEM SMT IC has rebooted spontaneously. I have removed my external brownout circuitry connected to the RESET Pin 1 and applied a 10K pull up on this pin as per the guidelines activating the internal reset circuitry. I've still seen the CPU reset on occasion. In reviewing the data sheet of the SX48BD/TQ, there 4 reset possibilities:
1. Power-on reset
2. Watchdog reset
3. External reset
4. Brownout reset
I am not aware of how the watchdog reset is programmed so i don't believe this is involved. I have disconnected my external reset circuitry so i know this is no longer present. I do know that the DC power drops as i load the circuit board from 4.98 VDC to about 4.7 VDC. I do not have decoupling capacitors present (yet) on the 4 Vdd pins - (will plan to add those) in a future board spin. That being said, unless the undershoot of the Vdd voltage is triggering the internal brownout circuitry, i would have to rule out brownout as a reset condition. As well, this is not a power-on reset so i also rule this out as the CPU is running an active program when this occurs.
Does anyone have any other possible reasons or easy checks to see why the CPU is rebooting?
Thanks very much,
Chris.
I have seen a few instances where my BS2P40 OEM SMT IC has rebooted spontaneously. I have removed my external brownout circuitry connected to the RESET Pin 1 and applied a 10K pull up on this pin as per the guidelines activating the internal reset circuitry. I've still seen the CPU reset on occasion. In reviewing the data sheet of the SX48BD/TQ, there 4 reset possibilities:
1. Power-on reset
2. Watchdog reset
3. External reset
4. Brownout reset
I am not aware of how the watchdog reset is programmed so i don't believe this is involved. I have disconnected my external reset circuitry so i know this is no longer present. I do know that the DC power drops as i load the circuit board from 4.98 VDC to about 4.7 VDC. I do not have decoupling capacitors present (yet) on the 4 Vdd pins - (will plan to add those) in a future board spin. That being said, unless the undershoot of the Vdd voltage is triggering the internal brownout circuitry, i would have to rule out brownout as a reset condition. As well, this is not a power-on reset so i also rule this out as the CPU is running an active program when this occurs.
Does anyone have any other possible reasons or easy checks to see why the CPU is rebooting?
Thanks very much,
Chris.
879 x 819 - 267K
758 x 727 - 83K
Comments
-Phil
sorry for my tardiness but i have been busy trying to isolate the rebooting issue. It seems to be affecting several parts of the circuit: LCD display going crazy, some relays tripping, keypad freezing up, CPU doing a full reboot, etc. - all of this, of course, is being driven or controlled by the CPU. I agree the decoupling capacitors are key and I will add them. One item of note, is that when i test the PCB in a lab environment it is stable and "never" exhibits any of the aforementioned issues - ever. The lab environment is not an exact replica of the application, but it is pretty close. Once i place it in the real world application, I get all of the wonky behavior. This fact seems to suggest noise somewhere. I will focus my attention there and try to break down the application by functions to see if i can isolate the root cause. If either of you have any other ideas, please let me know, and thank-you both for the feedback.
Chris.
Rule of thumb, particularly in the days of medium density TTL logic chips, has been to have one 0.1uF capacitor per IC. These days you need 1-4 capacitors per IC depending on the power requirements.
I've used a MPC3208 on a separate board and connected to my prop board via a ribbon cable. If the cable was too long it would cause erratic readings. Or maybe your board needs a ground plane under the prop chip etc.
the schematic more or less mirrors what Parallax has designed on their education board. What the collage picture indicates is that all 4 Vdd are tied together (pin 4 tied to 46, and then that connection ties to 18 and 32) and then that 3-way connection is tied to a 15uF/16V electrolytic capacitor. Unless the response time of the 15uF capacitor is inadequate to dampen the high frequency noise, it should be OK? My Fluke has min/max settings, but may not be able to capture the high frequency AC noise on the Vdd, so i won't argue that point too hard....I don't have an oscilloscope although that would be very helpful.
In the top right photo, i could add a 0.1uF ceramic capacitor across Vdd and digital ground....that may not be a bad idea and i don't think it will hurt. Given the Vdd are all tied so close together, placing it near where the three are connected and then connecting to digital ground should do the job, agreed?
FYI, the application has two A/C loads activated via relays (water pump and a water heating element) - a water heater.
Back to it tomorrow morning...
Chris.
I've had problems switching a/c loads with the prop and relays. Even with the relays opto isolated. It would disrupt my USB read stream. I was able to cure the problem by adding 600v 1-5uf caps on the relay coils. If I'm using a BS2 OEM I follow there schematic with the brownout detector etc.
The relay coils have operated fine for many years without an issue. When I disconnected the A/C loads but still operated the coils last night and there was absolutely no issues, 20X test. I have operated a stripped down version in my lab office space with a desk lamp as an A/C load (smaller current draw) as well and zero issues so this suggests that the coils are not creating any form of significant EMF. The problem is elsewhere. As soon as i introduce the pump (about 1.5A) i get the unstable behavior.
I also added the 0.1uF cap across where the three Vdd connect to the digital ground of C18 and unfortunately this did not improve things. I will continue to troubleshoot. If I find anything interesting, I will report back here.
Thanks both for your suggestions.
Chris.
Since it's not depicted at the images you'd published, what kind of power source(s) are you using to feed you equipment?
Any chances that your entire circuit, naturaly with the exception of A/C loads, could be operated from a battery-sourced power supply?
At least for a sufficient long time for you to be ensured that mains isn't the pathway used by load switching noise to invade your system?
Another possible point of view; in case you have access to such instrument, have you thought about using a high bandwidth digital storage oscilloscope and search for a suitable trigger, to trace some more clues about that uncommon behavior?
Henrique
P.S. Another idea: along time, load switching relay contacts does wear, generating sparks during close/open movement.
And you'd also mentioned a pump as the load. What kind of pump (motor, gas or liquid)? Number of phases being switched, starting current/time relationship. Every detail can help finding the culprit.
For relay bouncing (and arcing) during contact close, jump to 2:53.
https://youtube.com/watch?v=8B8N7e-4hmI
thank-you for your suggestion. In fact, I currently applied a DELL P/S from a PC with 12 VDC input to isolate the A/C from the D/C on the board to see if there was any noise being contributed this way. The 12 VDC output was then regulated down to 5 VDC using a LM2940CT. I also applied a 0.1 uF decoupling capacitor as mentioned above across the Vdd for the BS2P40 and another on my LCD display from CrystalFontz. I took this to my lab and ran with a backup water pump and desk lamp as a heater element. The system performed flawlessly aside from the occasional LCD display (Hitachi on board micro) getting corrupted. I suspect a better choice of decoupling capacitors may correct this.
I wish i had an oscilloscope so i could observe the inrush current and voltage response, both undershoot and overshoot. I am a little surprised that the voltage regulator, together with the high quality DELL P/S still has caused issues with the LCD display. At least I am not getting a hanging keypad, CPU rebooting, etc. That is an improvement at least. I do need to figure out now how to get back to my own P/S being used with a similar or better result now.
BTW, the PCB is very new and the relays are also brand new - good for 100K cycles - I would be optimistic if I've used them more than a few hundred times in testing. The water pump is single phase, draws about 1.2 A - very small - commercial grade. The heater draws about 11A and is also single phase -all to be used on a single 15A circuit.
Regards,
Chris.
I remember I used to buy a USB relay card made by measurement computing USB-ER808. I was switching some relays on a 400 hertz 120v system. The 400 hz would disrupt the USB every time and made the relay card useless. The called the mfr. and they where surprise said the 400hz was the disruption. So I found a solution by using the the USB-ER808 to switch a standard SPST octal relay with 120v 60hz coil and ran the 400hz through the contacts of the Octal relay. Problem solved.
So A/C on the contacts is the issue in my experience. Snubbing the A/C load.
Good to know you have it nailed down, except for an eventual LCD display malfunction.
Since I don't know the exact model of CrystalFontz LCD display you are using, its interface type (4/8-bit parallel or SPI) and the schemactic of the interconnection, its a bit hard to provide any hints, appart from the usual ones.
The following isn't a compreensive listing of each and every possible solution, but those are the ones I usualy try first:
- Begin here;
- When searching for a solution to noise problems, consider everything, that everyone has told you about capacitors (there is also a link, about snubber circuits, at the end of my post);
- Check grounding, looking for any subtle ground loops;
- Interface cables are very sensitive to interference, thus avoid long cable runs with paralleled conductors;
- Whenever possible, and even when it's hard to do, surround each and every signal conductor between grounded ones;
- If the cables are more than a few inches long, consider using twisted pairs, one being ground, to connect the circuits;
- If the circuit operation needs to be preserved at maximum, and the number of conductors is large, consider a ground sleeve, surrounding the whole group of conductors. If needed, the ground sleeve should only be connected to peripheral board GND;
- The same advice as above if you must resort to coaxialy shielded conductors: connect every shield only to peripheral board GND;
- Never; Never use signal grounds as the unique means of sharing GND between separated circuit boards;
- Never; Never use one (or more) of the paralleled conductors to feed power to peripheral circuits, even in the case it will be localy regulated, at the peripheral PCB;
- If you find yourself out of options and MUST use the same cable to interconnect power, please, use the maximum available number of conductors to do the connection, remembering to begin with the positive power supply conductors, then the ground connections, then the signals;
- Whenever possible, run power to peripheral circuits thru a higher gauge wire connection. In extemis, use a GND wire gauge whose resistance amounts, at least, to 1/10 of the paralleled group of signal ground conductors;
- Electrons love lower resistance paths; beautyfull colored plastic doesn't conduct electrons, higher gauge copper does it, nicely;
- If each circuit board has its own voltage regulator, consider using differential circuits to connect the signaling between them;
- Before loosing your remaining hair, trying to find that last/pesky noise, consider Galvanic isolation between separated boards supplys and use optocouplers to connect the signal runs;
- If (glitch hit rate lessens but don't disapears) Then: Jump to Begin Here; Else: You've won the battle.
Henrique
https://illinoiscapacitor.com/pdf/Papers/spark_suppression.pdf
Sure I must agree with you, but... I live in Brazil, and here we mostly find single phase AC motors driving pumps, with all those pesky centrifugal switches, in series with motor's start windings and their series-associated capacitors.
During motor spin-up, there will be a moment when the centrifugal switch will open, removing the winding-capacitor association from the mains circuit, thus there will be a real contact opening in the near future of a solid state relay-driven circuit closure.
I know, normally, the start winding current will be very low in that moment, tending to be zero if ideal conditions are in play, and arcing will be very unlikely to occur, at this time.
But, since everything tends to wear out, dust to pile up, and pumps overloading tends to be some fatal reality, it's my believe that there will be a bouncing contact anyway; an audible and perhaps visible one, in fact.
After some time, a circuit breaker will finally give-up, removing the cause of an almost bad smelling, overloaded motor from the mains circuit.
I can bet today's lunch in a statement: subtle arcing situations will be chances for many bad-sleeping nights.
Henrique
first i will reply to Henrique regarding the LCD display. I am using a CrystalFontz 2X16 backlit display in a 4-bit mode, model (CFAH1602A-YYH-JT 2X16) - a very simple and straight forward model and using Pins 1-7 of the BS2P40 - Parallax Book Reference manual suggestion for LCD control. A schematic of it is attached here for your reference. As a side note, I recently added extra pull down resistors - noted in RED font to manage the unused data bus pins, DB4-DB7. As per Mike and DigitalBob's suggestion i also attached a 0.1 uF capacitor across Vdd to digital ground (but still seen the internal microprocessor on-board the LCD display become corrupt. I see two reasons for this:
1. Lower frequency noise on the power and/or ground line
2. EMI entering the 12" ribbon cable.
Given my previous issues, I am leaning heavily towards the noise (option #1), as i have never had any issues with the ribbon cable in previous versions of the board.
To further improve noise management, I was thinking to add a larger capacitor - maybe the same as being used for the CPU (15 uF/16 V electrolytic). My reasoning is that this combination of a high and low frequency capacitor must be increasing the suppression across a wider frequency range which is enough to suppress noise for the BS2P40 - since adding the high frequency 0.1 uF capacitor i have not seen any further CPU reboots - roughly 30X consecutive trials - previously 3x-10X trials resulted in a fail. I will apply this tomorrow in my home office setup.
As for the single phase relays managing the A/C loads...I am using TE Connectivity (RZ03-1A3-D005) SPST-NO, Form A relay, again nothing too special. I am 99% certain that the noise from these relays is not materially contributing to the issues i am facing.
Thanks all for your amazing help and suggestions- myself and others are all very fortunate to have such great people on this forum!
Regards,
Chris.
I've added a 15uF electrolytic capacitor in parallel with the 0.1uF ceramic capacitor and continued to see corruption of the LCD Hitachi processor about every 10X trials. I also noticed that the LCD ribbon cable connecting the LCD display to the board was sitting against an A/C line cord connecting the water pump - pure coincidence. As a thought, I held the LCD display in my hand far from the A/C line cord and redid the test and ran it for almost 50X consecutive trials without a single error. My conclusion is that EMI interference with the A/C line cord was causing induction onto the ribbon cable which was corrupting the LCD processor. The EMI interference was most likely impacting the LCD commands and changing their value. As a FYI, the LCD display never "hung" at any point, but only was garbled - like it was operating in an unconfigured baud rate.
In my design, the LCD display is extended far away from any A/C power cords or the like, but this is troubling none-the-less. Rebooting the system restores everything as the LCD display goes through a formal configuration process.
This test was done in my home office lab. I will now have to move the modified PCB to the prototype product and retest to see if i get similar results. At least, there is no more CPU rebooting or hung keypad - each of which was most likely due to CPU corruption, which the decoupling capacitor has now resolved.
Regards,
Chris.
I have now tested the setup with the prototype and i am seeing similar failures, including LCD corruption again. I have run it with and without the heater load, so water pump only, and water pump and heater together and i am seeing similar failures modes- including LCD corruption again. I will try to further isolate the issues by adding items from my office lab setup downstairs to see if i can pin point where it is coming from - power cords, cables, etc.
Very strange...
Regards,
Chris.
Since my last post, I'd spent some time gathering my previous experiences with LCDs, driven thru 4/8-bit parallel interfaces.
I also have downloaded the datasheet for the particular LCD model you are using, and surprisingly, reading it in some 'holistic' way, most of it's contents are about of how sensitive they are to any kind of interference.
Since my own memories span from the end of the 80's (Z80), traversed the 90's (8051) and had come to an end (collection) at early 2000's, using Rabbits and ....exactly ... the SX line (28, 48 and 52), it was a good bunch to pass behind my eyesight, looking for any problems I may had faced with that kind of signaling.
Since that exercise has someway refreshed my memories, I've remembered that, for the Z80 and to match the LCD timming specs, I'd used A0 as the conveyor for the LCD R/~W, and A1 for RS; E was generated from A[7:2] (negative-going decoded output), further gated by ~IORQ with a NOR gate, ANDed with ~M1 to avoid conflicting any possible confusion with an Interrupt Request/Acknowledge Cycle, IIRC. Ouch, It's addicting.
In that way, EVEN I/O port accesses were READs and the ODD ones were WRITEs. Z80's R/~W signal was totaly forgotten, on that LCD application.
I'm not stating that the parallel interface and cabling your project uses could be surelly pointed as being the real problem, but I can't entirely ignore it, even because, in the way I'm viewing it, the 'glitches' could be masked by heavily filtering the LCD power source, to the point its occurence would fall at the 'hard to observe' cathegory, due to becoming so 'infrequent', but not 'non existent', if you can understand what I'm trying to tell in my 'nested-spaghetti' English.
Among the CPUs I've cited above, the SX line is by far the most capable one, when it comes to fast signaling and its characteristic slew rate. Since fast slew rates tend to cause ringing, and ringing, when associated with long and unterminated conductors, at least to me, are a bit closer to a perfect storm situation than I would like to face every day.
I'm not sure if my view of the situation does applies or not to the present case, but since it's not too hard to rule it out, before you try to improve the power supply filtering, so to don't mask it, and have to face a ghost in your future, suddently escaping from its tomb.
As for the ways I'll suggest to try, the simplest one is tearing appart the flat cable vias, at the point to being capable of slanting each one in a different plane, from their neighbour's perspective.
Kind of a random, zig-zag setup, or even as in some stair case steps arrangement.
That procedure will not have any effect at some slew rate-related ringing, but sure will diminish the capacitive and EMF coupling between the signal lines.
If the above procedure does have any effect at the frequency that the LCD shows a messy behaviour, the next step would be inserting low-valued resistors in series with the signals; If it was me, I would start with the data lines, since those four tends to change their values simultaneously. Next try would be E, then R/W and finally RS.
As for the resistor values, appart from a valuable advice from other members of the forums, I would start with something in the range of 100 to 470 Ohms.
Hope it helps a bit.
Henrique
i've purchased an oscilloscope as it is difficult to hit the target shooting in the dark. I am more confident that this will help to see where the noise is coming from, and the magnitude/shape of it, and then what can be done to correct. Once i've had a chance to troubleshoot, I will respond back.
thanks again for all the advice!
Chris.
I know its been a while but the troubleshooting has also taken a lot of time
As always, users are very lucky to have great board advisors as yourself!
Thank-you all,
Chris.
Excellent news! It's always good to know that someone has achieved its goals.
At the end, since arcing has proven to be the utmost headache generator, it has also revealed some other possible weaknesses of the whole circuit, being EMI/EMC sentitivity the most prominent ones.
At least to me, your case was trully special, because you've paciently tried almost each and every hint the community has shared with you, tolding us about your own observations and insights, as the analisys progressed.
Even when you was defyed by don't achieving a solid result, you've persisted, untill reaching a complete victory.
Thanks for bringing that big learning opportunity for everyone, now fully documented at this thread.
Henrique
I would appreciate some advice and/or suggestions. I recently received my completely upgraded board (all SMT) and I was so upset after powering it up, the BASIC Stamp software was unable to detect the stamp CPU (BS2P40).
I have checked on my previous board and my laptop and cable are successful on re-downloading the software so i know the laptop, software, and cable are working properly.
I had two new [img][/img]boards built and both are unable to boot. The CPU, EEPROM, oscillator and this section has had minimal changes - only added some decoupling caps as per our earlier discussions. I have checked the component values as much as possible with the board assembled, checked continuity on each and every connection. I've checked that the four +5V VDD and all four VSS on the CPU and all EEPROM and all have +5V and proper ground. RESET on pin 1 remains at +5VDC so it is not in continual reset. The circuitry involved in downloading the software is identical - no changes.
My thought is that the oscillator is not working, low probability or there is an open somewhere on the data transmission pathway - maybe more likely. If anyone has any suggestions, I would be very happy to try them.
Thanks very much in advance,
Chris.
Since you have already verified power and ground are good the next step would be to verify the oscillator is working using a scope, frequency counter, or led tester. After that it's a brute force check of interconnects using an ohmmeter or continuity tester. Make sure signals go only where they are supposed to go, and nowhere else. Having a net list really helps with that.
Brings back memories of troubleshooting brand new but dead S100 boards. Most common problem was shorts between data/address lines because the boards were silk screened, and when the silk screen was lifted the resist occasionally splashed and created a short between two lines.