Measuring the voltage of digital pins

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
david-given
Level 4
Level 4
10 sign-ins 5 sign-ins First solution authored

Some of the users of my device (http://cowlark.com/fluxengine) are reporting problems which I think could be due to bad termination of the cable used to connect the hardware being driven to my device.

I would like to measure the voltage of some of my digital input and output pins, so I can check the actual levels to make sure they're being driven correctly; this should let me detect this situation and warn the user. Is it possible to configure an ADC to a digital pin?

0 Likes
1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

DaGi,

/odissey1 is correct, you can read digital and analog on the same pin.  I'm currently in the process to verify /odissey1's statement about the ADC needs the VDDA as the vref.  If you can set the bandgap as the vref, you would be VDDA immune.  Since (according to the video) you are sourcing VDDA from the USB connection a VDDA dropout should not be an issue.  Note: The VDDA voltage from the USB will be between 4.2V to 5.2V.

I'd like to say:  BRAVO!   I like your design concept and your willingness to support "oddball" disk formats.  (I was a Amiga developer for over 11 years before Commodore stopped existing).   Please consider supporting the MSDOS format.  It's boring but ubiquitous.   This becomes even more important since it has been years since commercial PCs are shipped with 3.5" drives.  Many PCs are no longer shipped with CD/DVD drives.

I am concerned about two things I saw on the video,

  1. Your wiring to the 17 pins (of the 34 pin connector) highlights the flexibility of the PSoC to assignment and configuration of pins.    However, the other side (odd-numbered) of the 34-pin connector contains the GNDs for the signals on the even-side.  It's a pseudo-twisted pair to help minimize RE and RI induced noise.  I haven't looked at your code, I'm assuming you're using one of the signal lines as a pseudo-GND.  This could be a signal threshold issue when more than one output of the PSoC might be driven high.  This would cause a GND-lift/offset issue on the pseudo-GND causing a potential logic threshold issue on the target drive.  This is further exacerbated when the termination resistors are installed which are suppose to be 150 ohms.  In this case every output is trying to drive about 15mA.   On all output pins from the PSoC the current is spec'd at 4mA high source current.  This means the output series resistance of these pins in Voh mode is about 150 ohms.  Therefore when sourcing 5V, the output voltage from the pins is 2.5V.  Future Recommendation (?):  Have the odd-side of the connector wired to GND on the PSoC.  A simple 30 gauge wire can be soldered across the even pins and the other wire end soldered to PSoC GND.  This should eliminate the potential GND offset issue.

    One way to potentially eliminate the PSoC pin over-drive issue is to eliminate the termination and keep the cabling very short.  The only real issue could be the rise and fall times off the output drivers on the Floppy drive circuits.  If the rise/fall is too fast, you could get voltage glitches in the PSoC inputs.   In this case, deglitching or debouncing the inputs on the PSoC will probably eliminate this issue.
  2. The other issue I saw is that if the USB cable is disconnected, there is no VDDD or VDDA source on the PSoC.  The assumption is that the PSoC is powered off.  The reality is that if the Floppy drive power is ON and the floppy connector is connected, that the PSoC will be partially powered parasitically through the floppy drive interface signals that happen to be high.  The parasitic current flow goes through the ESD protection diode connected from the input to VDDD.  The resulting voltage would be about 0.6V lower than the voltage on the pin.  The concern here is that there could be potential damage of the ESD protection diodes on the PSoC GPIO pins.  The spec lists 100uA max.

My concerns may translate to some of the user complaints.  In a well behaved system, many of the concerns can be minimized.  However your project is a DIY.  Additionally, the floppy drive mechanisms the user provides are a bit of a "wildcard" since the input and output characteristics can have some "wiggle-room".

Len

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

0 Likes
13 Replies
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

I believe that it's possible. Configure pin as both digital and analog (chek both check marks). The ADC has to be set to Vss to Vdda. Here is a problem: on KIT-059, all Vdd  and Vdda (for all quadrants) come from single power source; if entire Vdda drops simultaneously with pin voltage, then changes on the pin won't show up, as reference voltage changes proportional. Otherwise, if only pin voltage dropped, but Vdda is stable,  ADC should record correct pin voltage.

/odissey1

P.S. You have interesting project going on. I think that I've seen the website before, but didn't realize that you are using PSoC5LP kit.

0 Likes

Excellent, thank-you. I'll give it a try and see what happens (in a couple of weeks, unfortunately).

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

DaGi,

/odissey1 is correct, you can read digital and analog on the same pin.  I'm currently in the process to verify /odissey1's statement about the ADC needs the VDDA as the vref.  If you can set the bandgap as the vref, you would be VDDA immune.  Since (according to the video) you are sourcing VDDA from the USB connection a VDDA dropout should not be an issue.  Note: The VDDA voltage from the USB will be between 4.2V to 5.2V.

I'd like to say:  BRAVO!   I like your design concept and your willingness to support "oddball" disk formats.  (I was a Amiga developer for over 11 years before Commodore stopped existing).   Please consider supporting the MSDOS format.  It's boring but ubiquitous.   This becomes even more important since it has been years since commercial PCs are shipped with 3.5" drives.  Many PCs are no longer shipped with CD/DVD drives.

I am concerned about two things I saw on the video,

  1. Your wiring to the 17 pins (of the 34 pin connector) highlights the flexibility of the PSoC to assignment and configuration of pins.    However, the other side (odd-numbered) of the 34-pin connector contains the GNDs for the signals on the even-side.  It's a pseudo-twisted pair to help minimize RE and RI induced noise.  I haven't looked at your code, I'm assuming you're using one of the signal lines as a pseudo-GND.  This could be a signal threshold issue when more than one output of the PSoC might be driven high.  This would cause a GND-lift/offset issue on the pseudo-GND causing a potential logic threshold issue on the target drive.  This is further exacerbated when the termination resistors are installed which are suppose to be 150 ohms.  In this case every output is trying to drive about 15mA.   On all output pins from the PSoC the current is spec'd at 4mA high source current.  This means the output series resistance of these pins in Voh mode is about 150 ohms.  Therefore when sourcing 5V, the output voltage from the pins is 2.5V.  Future Recommendation (?):  Have the odd-side of the connector wired to GND on the PSoC.  A simple 30 gauge wire can be soldered across the even pins and the other wire end soldered to PSoC GND.  This should eliminate the potential GND offset issue.

    One way to potentially eliminate the PSoC pin over-drive issue is to eliminate the termination and keep the cabling very short.  The only real issue could be the rise and fall times off the output drivers on the Floppy drive circuits.  If the rise/fall is too fast, you could get voltage glitches in the PSoC inputs.   In this case, deglitching or debouncing the inputs on the PSoC will probably eliminate this issue.
  2. The other issue I saw is that if the USB cable is disconnected, there is no VDDD or VDDA source on the PSoC.  The assumption is that the PSoC is powered off.  The reality is that if the Floppy drive power is ON and the floppy connector is connected, that the PSoC will be partially powered parasitically through the floppy drive interface signals that happen to be high.  The parasitic current flow goes through the ESD protection diode connected from the input to VDDD.  The resulting voltage would be about 0.6V lower than the voltage on the pin.  The concern here is that there could be potential damage of the ESD protection diodes on the PSoC GPIO pins.  The spec lists 100uA max.

My concerns may translate to some of the user complaints.  In a well behaved system, many of the concerns can be minimized.  However your project is a DIY.  Additionally, the floppy drive mechanisms the user provides are a bit of a "wildcard" since the input and output characteristics can have some "wiggle-room".

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

DaGi,

To restate my previous post:  Your project has tremendous merit!   You provide a DIY means to a community where older equipment is still in use and data transfer to these devices is important.

Future project suggestion

Your familiarity to the 34-pin floppy interface is significant and valuable.   Here's a new project idea:

Develop a HW/SW project that allows the user to replace the floppy drive on these older equipment to write (and read) to a SDHD card.

This could allow multiple floppy drive images on different partitions a single SDHD card.

In effect, your FluxEngine acts as the floppy master.  In this project, you would 'flip' the role to be a floppy slave.

This is the value of this project: If a floppy drive on older equipment fails (It is 80% or more of a mechanical device), replacing the drive can be very tricky since the equipment has been out of production for years.   The interface to the floppy is generally standard.  This includes the 34-pin interface and the power connection.   Features:

  • There would be a front panel SDHD card interface slot.  A
  • A momentary switch with multiple LEDs on the front panel to switch between partitions where the LEDs display the active partition.
  • The Floppy data could be stored on the SDHD card as 'raw' serial data with a track stored as a separate file.  The host program would decode the track data as you currently do for the FluxEngine.

Just a thought.  If you need some help with this idea, let me know.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Re grounding: yes, I figured that out eventually. I now tell people to solder one pin from the ground side of the FDD connector to the GND pin on the PSOC board. I can't comment on whether this fixed the termination issues, because they don't manifest on my setup, but a few other odd pieces of behaviour went away. I don't know yet whether all the pins need connecting; I'd have thought it was unlikely, as there's only one signal wire carrying high-bandwidth data and it's only about 250kHz to 500kHz anyway. I'm perfectly willing to admit that analogue stuff is not my forté.

Also, I wasn't aware that GPIO pins were specced at 4mA. I thought it was 20mA! This is kinda problematic.

Re glitching: I have, every now and again, seen weird double-bounce data pulses from the drive, so that could be it. I did add debouncing and that worked around it.

I have noted that the FDD is way pickier about voltages than the PSoC is. My computer's USB is about 4.8 to 4.9V and that's not good enough --- even a drive which will run at less than the USB limit of 500mA will flake out at that. Someone else (on a different forum) pointed out that the PSoC datasheet decrees that GPIO voltage must be <= Vddio. If the drive's at 5V and the USB is at 4.9V, then this constraint is violated. Any idea what problems this might cause?

Re your future project: you've just invented the HxC floppy emulator! HxC2001 HeadQuarters : HxC Floppy Emulator

0 Likes

DaGi,

Probably one GND pin will suffice.  It doesn't have to carry much current and the matched paired signal:GND for RE and RI are less a problem if the cable is short.

The GPIO pins are Ioh = 4mA (curernt source) and Iol=8mA (current sink).  The SIO pins which are on Port 12 of the 059 kit are Ioh = 4mA (curernt source) and Iol=25mA (current sink).

Glitching:  The termination resistors should minimize most glitching but the current drive requirements suck!  In place of the termination resistors, a user can put series resistors (~ 200 ohms).  This will slow down the rise and fall times of the switching edges.  This would help.

Many older FDD drive use TTL technology.  This is antiquated technology that has long be supplanted by higher current CMOS.  CMOS input voltage thresholds are basically VDD/2 as the logic switching threshold.  If VDD = 3V, then the switching threshold for a '0' or '1' decision is 1.5V.  With TTL it is more critical.  A '0' is <= 0.8V = Vil and a '1' is >= 2.4V = Vih.  The operational voltage for TTL is 4.5V to 5.5V.  It's a much narrower operational range.

Any GPIO output should be as close to VDDIO as possible (better noise immunity since it is further away from the logic switching threshold mentioned earlier).  The GPIO Voh @ 4mA source current is VDDIO-0.6V.  This means the internal series resistance of the high-side driver of the pin is about 150 ohms.  You can drive more current if needed (temporarily of course) but due to the series resistance of the driver your effective voltage is VDDIO-(150*Ioh).  This places you closer to the switching threshold.  For a TTL input circuit at the other end, this Vih limit is 2.4V.   This means the maximum Ioh you can support is 17.3mA @ VDDIO = 5V, 15.3mA @ VDDIO = 4.7V, etc.

HxC floppy emulator: Cool!

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

This all applies to output pins, though, which should be configured as open-collector drive-low pins. That is, the drive's pullup resistor pulls them high for a logic 1, and the PSoC is driving them low for a logic 0. The PSoC should never be driving them high. This is why the GreaseWeazle, based on a 3.3V Blue Pill, still manages to interact with the 5V FDD logic.

According to the datasheet here: https://hxc2001.com/download/datasheet/floppy/thirdparty/Teac/TEAC%20FD-05HF-8830.pdf  a representative 3.5" drive has an approximately (very approximately) 20k pull-up resistor in the receiver. (Page 17.) That means that the drive current for a logic 0 should be 0.3mA and the drive current for a logic 1 is nil, subject to leakages and differences in supply voltages between the board and the FDD.

However I've got faint memories of trying the open-drain drive-low output GPIO mode (which is roughly equivalent, right?) and it not working, so I'm using the pull-up resistor output GPIO mode, and not really understanding why.

0 Likes

Hello DaGi.

Great little invention.

For old 5.25" floppy drives, they used a couple of different termination schemes.

1) 150 Ohm pullup resistor to +5Vdc on each input

2) 220 Ohm pullup with 330 Ohm pulldown for an input impedance of 132 Ohm

3) no termination resistors at all, because they are connected in a multi-drive 'daisy chain' fashion.  Only the farthest drive has the termination resistors on the input lines.

These older drives use the 7438 open-collector NAND driver (connected as an inverter) and the 7414 input buffer(inverter).  BTW, the 7438 can sink around 40mA.

Here's a typical 5.25" drive, Shugart SA400.

http://www.classiccmp.org/dunfield/r/sa400.pdf

Siemens made a similar drive, FDD100-5.

These 2 drives were very popular.

Apple Computer contracted Shugart to use the SA400 guts with Apple's own design analog pcb.  This was used for the Apple II, II+, line of computers.

So, it could be that some of your DIY'ers are connecting drives without the termination resistors in place.  Hence the need for 5LP programmable pullup.  Heck, they might not even have the drive select signal selected properly.

And, there's nothing wrong with running 5LP (or STM32) at 3.3V driving low or driving high (in reference to GreaseWeazle).  The receiving TTL logic is quite happy with any signal below 0.8V (logic 0) and any signal above 2.4V (logic 1).  And if you take the termination resistors off, less stress on 5LP.

I'm guessing the 20k resistors in the Teac drive are only there so the inputs don't float.  20k doesn't do anything as far as signal integrity is concerned.  Again, this is likely why you needed the 5LP to have both active low and resistor high pullup capability.  As I recall, the 5LP resistor is not all that strong.  So, you could still have too slow a rise time for the data rate being transferred.  You could go back to the 5LP open-drain mode and apply your own say, 470 Ohm pullup resistor.  Although, you mentioned you don't see the issue so it would be hard for you to test.

I suspect you know a bunch of the info I just posted.  For other people reading your thread, maybe I've added a bit to their knowledge.

Keep up the good work.

Bill

DaGi,

The output drives on the FDD system are Push-pull with tristate enable.  Therefore when the output is suppose to be enabled, it pushes high (-4mA) or pulls low (8mA).  A output with open drain (or collector) mode will probably not work very well on clock or data lines because the rise time of the signal is dependent on the accumulated capacitance on the line and the total pullup resistance on the line.  The higher the pullup resistance, the lower the usable operating frequency.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

With regard to rise times, what kind of data rates would be problematic? The FDD bus has precisely one data line, which receives pulses about 0.1us to 0.8us wide at intervals from anything from 2us apart up (all the way up). There is no separate clock line.

So far, on my setup (which is notably trouble-free), open drain outputs look like they're working fine; I haven't heard back from any of the people who have been reporting problems yet.

0 Likes

DaGi,

The MFM type being placed on the disk is suppose to be self-clocking (kinda, sorta).  It appears based on the Teac datasheet you provided that the WRITE_DATA is almost directly written to the magnetic media head.  This allows the FDD host to provide write pre-compensation for inner tracks.

Sadly, there is very little info in the Teac datasheet about rise/fall time requirements.  I'm currently looking at other specs to derive meaningful info.

Is there a reason you do not use a STRONG drive for data output?  You could probably use open drain outputs for slower control signals.

Len

UPDATE:  I found this information on the internet:   Floppy Drive Pinout, Signal names, Pin out Description and Cable twist wiring

In the section "Floppy Disk Drive Legacy" it mentions the output drivers are open collector low (equiv to open drain low).  It also specifies the pullup is 1K ohm.

The issue with a DIY project is you can specify the external pullups but you can't insure the value is correct.

In general, you don't want the rise time to be slow otherwise the bit timing on the media gets marginal and could cause read failures later.

With the specified 1K pullup and assuming 50pF load capacitance on the signal line, the rise time is basically 2xRC where R=1K=1x10^3 and C=50p=50x10^-12

Therefore 2xRC = 2 x 1x10^3 x 50x10^-12 = 100 x 10^-9  = 100ns = 0.1us.  Not too bad.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

The drive circuitry uses the pulses on WDATA to switch the polarity of the magnetism on the disk --- each pulse causes a flux reversal from positive to negative and vice versa. So the pulse is actually triggering some logic inside the drive on a leading edge, rather than being simply amplified and sent to the head.

WRT the open drain output: the data sheet tells me to! http://www.bitsavers.org/pdf/mitsubishi/floppy/M4851/TJ2-G30211A_M4851_DSHH_48TPI_OEM_Manual_Nov83.p... explictly specifies a SN7438N as the driver at the host end. Previously I did have the pins set to strong drive, and I'm wondering whether that was the cause of the problems. I'm particularly concerned in the the CYC8KIT-059 and the drive are running off different power supplies at slightly different voltages, and if the 059 is driving the line high to a different voltage than on the drive end, there'll be a current flow. Open-collector drivers at both ends avoids this (AFAIK).

0 Likes

DaGi,

You are correct, the WDATA signal is processed through amplifiers to generate the proper flux.  However, the WDATA timing is critical.  Fall times shouldn't be a problem because the output impedance when driven low is about 75 ohms.  The concern I had with open collector drives is that the pull-up bias needs to be 1K or slightly lower to guarantee a rise time no greater than 0.1ms.  If the rise time is too slow, the timing of the flux edge might be too late.

It looks like open-collector (or open-drain) drive is the better way to go.  This means your user needs to ensure that a 1K pullup is used.

It is my belief that the difference between the FDD VCC @ +5V and the PSoC VDDD @ 4.5V is insignificant.  This is especially true if you are using the open-collector drive strategy.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes