NetBurner Community Forum

Using MOD5272 on Custom Hardware, NNDK 2.4 RC2

I use PC3 (J2.23) to enable and disable a MOSFET (BSH105) that switches a relay (G6RL-1) on and off. The gate has a pulldown resistor(2.2K) connected in parallel with the output signal from the module, so the relay stays off until after the boot is finished and it's enabled by the software.

On some boards, I have something strange going on. I basically do this (after configuring the port for output):

sim.pcdat |= 0x0008;

And exactly 5ms later, the board resets itself. Note that I see the output go high. I can watch it boot. The port initially comes up to about .69V, then it clears to 0 after the software starts. I turn it on, it raises to 3.3V, the relay clicks, and 5ms later it resets.

Any thoughts? Thanks, Dan B.

Are you calling any LED or DIPsw functions? I am not familiar w/ the 5272 platform, but on many of the platforms (5270, 5234, 5282, etc) there is an internal function called OnModDev70() that tests which development board is being used: Dev70 or Dev100. This call is executed the first time the LED or DIP resources are used, eg during the putleds(), getdipsw() calls and a few others. This test can impact all pins on the DataL and DataH ports the first time the resources are used. The following is from ioboard.c on the 5270 platform. On the 5234 and 5282 similar code seems to be in ioboard.cpp... It might explain why you see the pins go through a series of levels change right after boot. Depending on what's connected to them, I could see this causing a reset.


/*
The following function tests to see whether the MOD-DEV-70 or MOD-DEV-100 carrier
board is being used. This is done by pulling the lower data bus pins low and then
reading back their state. Since the LEDS on the MOD-DEV-70 board will pull these
pins high they will read back as 0xFF. The MOD-DEV-100 has these pins as unconnected
so they will remain low and read back as 0x0.
*/
BOOL OnModDev70()
{
if (!b_detected_device)
{
sim.gpio.par_ad &= ~(0x1); // Set the databus 15-0 pins to GPIO
sim.gpio.podr_datal=0; // Set the databus 7-0 pins low
sim.gpio.pddr_datal=0xFF; // Set the databus 7-0 pins as outputs
volatile int i;
for( i = 0; i < 4000000; i++) // Short delay to ensure pins are pulled low
asm(" nop");
sim.gpio.pddr_datal=0; // Set the databus 7-0 pins as inputs
asm(" nop"); // Short delay to allow pins to pull up
asm(" nop");
BYTE bv=sim.gpio.ppdsdr_datal; // Read the state of the lower bus pins

if (bv==0xFF) // If they were pulled up then board = DEV-70
{
b_is_moddev_70=TRUE;
}
else
b_is_moddev_70=FALSE;

b_detected_device=TRUE;
}

return b_is_moddev_70;
}


unsigned char getdipsw()
{
if (OnModDev70()) // Are we using a MOD-DEV-70 or a MOD-DEV-100
{
sim.gpio.par_ad &= ~(0x1); // Set the databus 15-0 pins to GPIO
return sim.gpio.ppdsdr_datah; // Return the databus 15-8 pins
}
else
{
if ( !bInit )
InitChipBoardSelect();
return *pSwitch;
}
}


void putleds( unsigned char c )
{
if (OnModDev70()) // Are we using a MOD-DEV-70 or a MOD-DEV-100
{
sim.gpio.par_ad &= ~(0x1); // Set the databus 15-0 pins to GPIO
sim.gpio.podr_datal = ~c; // Set the databus 7-0 pins to the desired LEDs (active low)
sim.gpio.pddr_datal = 0xFF; // Set the databus 7-0 to be outputs
}
else
{
if ( !bInit )
InitChipBoardSelect();
*pLed = c;
}
}

I immediately preface this with the fact that I'm a software guy. Is it possible that the relay and whatever's attached to the pin draws power from the same power supply that is feeding the CPU? I have seen situations in the past where doing something in software caused the power to temporarily dip below the threshold causing the CPU to reset.

Id vote for some power glitch with the relay or the thing attached to the relay...
Try disconnecting the relay coil and see if it still happens...

Ah yes, the horror of the glitch reset. I have had this problem many times on many designs.

1.Depending on the load, you can place a 'snubber' across the relay contacts, say .12uF/47ohms, that sort of thing
2.The relay should work on 5, 12, 24 volts and that supply should drive the 3.3 volt regulator with a nice big electrolytic next to the 3.3 volt regulator input side (along with a 0.1 uf cap for the higher frequency glitches)
3. If the load is obnoxiously big, use an opto device between the relay and the processor and decouple the processor supply from the load supply with, for instance, a completely different power supply for the processor subsystem.
4. caps caps caps. all over the place near the processor subsystem
5. star ground. The lowest impedance runs all come together in one spot in your chassis. The worst scenario is ground spikes being "heard" by your netburner module.

Best of luck!

Chris

Hey guys, thanks for the help so far, but I'm still not getting anywhere.

Ridgeglider - To answer your questions, no, I'm not using any of those functions. I'm really basic:
Setup Section:
sim.pcddr = 0xFFFF; // make them all outputs
sim.pcdat = 0x0000; // turn them all off

Then, when I need to toggle the relay on and off I use
sim.pcdat |= EN_HV_BIT;
(or)
sim.pcdat &= ~EN_HV_BIT;

tod, pbreed, and chris, I've been trying caps. I even added some to the MOD5272 itself, and it's just not helping. The coil voltage is about 2V, the current is 73mA. I've got 10uF, .1uF, and .01uF on the coil high side, lots of buffer caps on the DC-DC converter itself, and other caps sprinkled across the board.

When I sync the enable signal to everywhere else, I don't see a bump in the 3.3V anywhere. And I don't see a bounce in the ground, except for maybe 50mV, which is about my scope's noise threshold anyway.

When I look at the actual Port C output, here's what I see
In the first 7-8ns, the output rises from 0 to about 1.7->1.9V.
In the next 4ns it loses signal to about 1.3V, and holds there for about 4-6ns
In the next 60ns, it rises to 3.3V
It holds the line high at 3.3V for 5.2ms (An eternity by comparison to the rise time)
It drops to less than 1V, as the device has reset and the output is back to being an input with a weak pull-up.

Maybe it's the capacitance of the FET input. Datasheet says a BSH105 Cin is 152pF. At 2V/8ns, I suppose my C(dV/dT) could be upwards of 40mA. Could I literally be sucking power out of the core of the CPU and there's no way to buffer that?

Thanks again, Dan B.

What is your power supply like?

The MOD5272 takes 500 ma at 3.3V. What else is on the board? Is there enough power to go around?
It sounds like the relay is goes on and the voltage to the module drops.
Can you put a second channel on the scope to check the module power to see if it drops when the relay fires?
Also, what does your reset circuit look like? Perhaps put a scope channel on the reset.

Ed

I suppose that you have the counter EMF diode on the coil - but that only applies to when the relay is opened.

Did you try what Paul asked? not energizing the relay by disconnecting the coil alone? (leave everything else in incl. FET)

If you energize the relay, say, 10 seconds later- does the reset travel with the relay click?

Chris

ecasey, my power supply is a DC/DC converter made by Murata Power, P#: OKI-78SR-3.3/1.5-W36-C
Ratings are 3.3V, 1.5A. It should be buckets of extra. (Powered by an external 24V DC Linear.)

I have tried the dual probe, and I still can't see anything. No sags, no bumps, not even hash! That was a good thought to check the reset line, but no luck there either!

I'll try pulling the relay out of the board and I'll get back to you. Thanks - Dan B.

- MY EDIT -

So I pulled out the relay, and of course it works. But, it gets weirder. I decided to try having *just* the coils connected. So I put in some wire-wrap stakes and have the relay flying above the board. Now I can turn the relay on and off at will, and everything is just fine. So it has to do with what I'm actually switching on and off. I can't imagine what this is going to be.

Yeah, the magnetic field is generating a pulse in some high impedance line nearby. Make sure all signals are pulled up with 10k or something resistors and you may need to ground or pull up signals on the module

Chris