I am trying to understand how/why I get odd voltages on some port-B pins.
Port-B.0 and Port-B.2 on an RCM3700 are set up as inputs to monitor the levels of various signals that are logically combined into the INT1 input. The signals have pull-down networks of 10k to ground and 1k in series, giving 11k to ground. There are also 10k->1n networks into an XOR forming an edge->pulse function. The effect is to detect changes on any of four inputs and generate an interrupt; detect the various input levels and drive some outputs as a consequence.
The problem is that Port-B.0 and Port-B.2 behave strangely. Occasionally and apparently when the inputs are released, Port-B.0 and Port-B.2 do not return to the <= 0.3V level I expect, but rather they drop only to 0.8V, which level usually causes the TTL-compatible CMOS edge-pulse generator to misbehave.
The strange voltages last typically less than two seconds before reverting to <= 0.3V. The debugger loses contact with the Rabbit, so debugging is difficult. Lower value pull-downs can circumvent the problem, but raise other operational issues. Setting the pins to outputs also stops the problem, but of course the unit then no longer functions as needed.
I have two other signals monitored on Port-D and they behave normally.
I have some evidence that Port-B.3 might also have gone to a funny voltage at some stage, though as this is normally an output the incidence if, fortunately, rare … fortunately because this output results in a catastrophic failure. High or low are fine, 0.8V causes rapid meltdown of some MOSFETs, together with all the coloured flashes and smoke that that implies.
Does anyone have any understanding of what’s going on here? I can’t find anything else touching the port, either in my software or in libraries I’m using.
Hi I am trying to understand how/why I get odd voltages on some port-B pins.
Port-B.0 and Port-B.2 on an RCM3700 are set up as inputs to monitor the levels of various signals that are logically combined into the INT1 input. The signals have pull-down networks of 10k to ground and 1k in series, giving 11k to ground. There are also 10k->1n networks into an XOR forming an edge->pulse function. The effect is to detect changes on any of four inputs and generate an interrupt; detect the various input levels and drive some outputs as a consequence.i want to know more about this.
I’ve reduced the 10k pull-down to a 1.5k pull-down, which is as low as I dare go for TTL compatibility, the intention being to overwhelm whatever causes the 0.8V. Bizarrely, though, the voltage levels are now 1.2V rather than earlier 0.8V, which appears illogical, though this is a new batch of Rabbit modules.
I’m pretty sure now that that happens because the watchdog timer expires and causes a reset of the machine. The IDE has already lost contact, so fails to report that.
Just for the record, with the RCM3710A removed, all these signals behave exactly as expected, so the Rabbit is implicated in some way.
I’ve now tried this with several modules and have similar behaviour, though it’s possible the changed voltage is module (batch?) related.
Any ideas anyone? This is being a significant problem and at present I can’t see any reason this would happen.
I’ve attached a schematic clip of one of the two identical areas. CHAN_C_TTL_IN is the signal with the problem and in this case goes to PB.0.
When the external input comes from a true TTL drive things behave fine, when from an external switch to a 1k pull-up to +5V, I have the problem.
When the problem occurs, the voltage at the input is around the 0.8V level, so the 1k…1.5K is operating simply as a potential divider on the 1.2V.
The diodes are to 0V & +5V and are for static protection. The 5V rail is stable during all this.
If I now make PB.2 an output, set low, the PB.0 pin behaves sensibly. The INT1B line pulses high cleanly on a rising input (1k/+5V). On release, rather than the rapid oscillatory burst for 2s, I get just a brief (8 us?) burst, presumably as the charge on the C falls through the threshold, then the remainder of the pulse is clean.
With PB.2 as an input, on the release, PB.0 goes to 1.2V and PB.2 goes to the 0.8V. In this circumstance I get rapid oscillation on the INT1B line, presumably until the watchdog resets it.
The INT1B line normally switches cleanly, but in the oscillation case is a neo-sinusoidal ripple around 2V-ish nominal and maybe 300mV p-p, perhaps slew-rate limited in the CMOS, though it’s only at a few MHz, which may suggest some other effect.
i had the same problem with my 4510w. i have found that port B bits 0 and 1 are used for the programing comunication. the voltage you are seeing might be the programing signal
On RCM3700 PB1 is used for programming, but it does not go off of the module. PB0 is used as a clock for serial EEPROMs, but I don’t knowingly use the EEPROMs.
PB2 appears not connected to anything, though as I can’t machine-search the I might have missed it, but I don’t think so.
Port B is used in conjunction with Port A for the slave port and auxilliary port, but again I’m not knowingly using them.
At this point we’re making and external ‘dongle’ to take switch inputs and convert them to CMOS so the drive overcomes whatrever it is on PB[0|2] that gives the bad levels.
FWIW, when looking at the traces I get a short ‘stand’ after releasing the input, which stand looks rather like some combination of linearity change and charge store. There’s some ripple on the stand.