Documentation bugs: RPi2&3 GPIO electrical specs

[gwideman]

Seeing as you can't be bothered to read what I write why should I bother writing anything?
Perhaps
HYSTERYSIS IS ALWAYS ENABLED BY THE FIRMWARE AND NOT CONTROLLABLE FROM LINUX
is big enough.
[...]
Yes, I am getting fed up with this thread!

I am not sure the customer relations effect you are trying to have here, but it's a little "unusual".

Moving on, let's take your points one by one.

What you previously wrote is that hysteresis is not exposed VIA linux, which I took to mean that the OS does not expose the hysteresis setting to applications. What you have now written is something different -- that Linux, apparently including the boot process, does not have access to those settings. Fair enough, point now understood based on your new information.

>> 14 and 15) default to having a pull-down resistor.
> Which aren't inputs (hence the uart0 designation), therefore pulling resistors are irrelevant.

Wait, are you saying that neither of GPIO14 nor 15 are inputs? Or that they are dedicated only to UART0 duty and can't be reassigned if UART0 is unused ?

>> [email protected]_DISK_ACTIVITY section [... what does it mean, any interaction with GPIO2... ]

> Look again at the values used for those functions and NONE of them have ever been
> accessible via the GPIO header on the board,

I'm looking, and what I see is that there are pin_define sections, the documentation for which I don't have, so I'm just guessing, but it appears to associate a name, suggestive of a function, to a "number", which is possibly a GPIO number. For example GPIO 2. Which is one exposed on the 40-pin header. In the absence of documentation, I don't know what to think. If the "number" doesn't refer to GPIO number, OK, fine, it's irrelevant to the current discussion. If "number" does refer to GPIO, but the function is not implemented, then OK, fine, again not relevant, but one wonders why that section is in the file. Other parts of these pins_xxx sections are relevant to understanding the GPIOs, maybe these pin_defines are not.

> so a whinge about reserving GPIOs and not being available for general GPIO is just hot air.

Not sure where you're seeing a whinge in that question.

[hippy]

Seeing as you can't be bothered to read what I write why should I bother writing anything?
Perhaps
HYSTERYSIS IS ALWAYS ENABLED BY THE FIRMWARE AND NOT CONTROLLABLE FROM LINUX
is big enough.

According to Gert's PADS documentation; the hysteresis control bits are in the same registers as the bits are which control drive strength. My belief was that, if it is possible to set the drive strength from within a user application under Linux or using bare metal, then it should likewise be possible to set the hysteresis bits, on or off, or is that not correct ?

[DougieLawson]

I am not sure the customer relations effect you are trying to have here, but it's a little "unusual".

On a forum that's run on a purely volunteer basis (nobody gets paid for posting on here), what possible "customer relationship" are you imagining exists?

You're not paying for support, 6by9 is not getting paid for the stuff outside his regular day job at the RPF/RP(T)Ltd. I don't get paid for the stuff I write on here although some folks have sent me some freebies.

[gwideman]

According to Gert's PADS documentation; the hysteresis control bits are in the same registers as the bits are which control drive strength. My belief was that, if it is possible to set the drive strength from within a user application under Linux or using bare metal, then it should likewise be possible to set the hysteresis bits, on or off, or is that not correct ?

As it's a feature set in a register, then one would assume software at some level can set it. There is doubtless code that makes the initial settings including hysteresis; 6by9 says in the firmware. Then there would be driver code (that runs with enough permission to twiddle hardware) that knows how to set bits for a variety of features, in conjunction with data from the device tree blob (and this driver perhaps lacks code to change the hysteresis bits). And finally, some driver features will be receptive to messages from user applications, so allow setting in/out and pullups/downs.

So it could be that if you really wanted to disable hysteresis you would need to modify the driver in question. Personally I would not have too much inclination to disable hysteresis, but I am interested that it's enabled, and beyond that would like to know the amount -- that is specs for the gap between high and low threshold voltages. (Along with the other specs that I hope become available as previously discussed.)

[hippy]

Personally I would not have too much inclination to disable hysteresis, but I am interested that it's enabled, and beyond that would like to know the amount -- that is specs for the gap between high and low threshold voltages. (Along with the other specs that I hope become available as previously discussed.)

Agreed; it's not whether one should or would but having details about the electrical specs if one did which are missing. It's in the hands of RPT/RPF and we will have to wait to see what is delivered.

[gwideman]

I am not sure the customer relations effect you are trying to have here, but it's a little "unusual".

On a forum that's run on a purely volunteer basis (nobody gets paid for posting on here), what possible "customer relationship" are you imagining exists?

You're not paying for support, 6by9 is not getting paid for the stuff outside his regular day job at the RPF/RP(T)Ltd. I don't get paid for the stuff I write on here although some folks have sent me some freebies.

The relationship is that between an employee of the organization that hosts this forum and which also sells Raspberry Pis and instructs customers to go to the forum for support, and me, a purchaser of Raspberry Pis.

Is there some part of this relationship that makes OK the all caps large font statement incorrectly implying that I was mentally incapable of understanding a previously posted piece of information?

FWIW, I've noted that the person concerned has a long history of helpful posts and contributions to the RPi project, so I'm assuming that he was just having a bad day on top of misinterpreting something earlier in the thread. So I'm not inclined to be upset -- just thought it was a little over the top.

[mahjongg]

can we stop the shouting? its not okay, even though being under the impression someone does not want to listen, keep it nice and cool.

for wat it's worth I'm glad to learn that the PI's GPIO's have input hysteresis (permanently enabled) although I have always suspected the PI would have input hysteresis.

For one it explains why no simply ViH ViL data exist, (and no grey zone) but it would be nice to learn the (semi) exact thresholds for low to high, and high to low transitions (even though you can find this out with a 10K potmeter between 3V3 and GND in about 5 minutes, it would be nice to have it documented somewhere).

[hippy]

it would be nice to learn the (semi) exact thresholds for low to high, and high to low transitions (even though you can find this out with a 10K potmeter between 3V3 and GND in about 5 minutes, it would be nice to have it documented somewhere).

The problem with measuring it oneself is that only gets a result which applies to the Pi being measured. It tells one little about any other Pi or what the official electrical specs would say.

[gwideman]

For one it explains why no simply ViH ViL data exist,

Datasheets give an exact spec of the range of values that may be encountered across a population of components and temperature range, (outside of which range a component would be considered defective). Hysteresis just adds one line to that.

Example datasheet of a different SoC:
https://www.nxp.com/docs/en/data-sheet/ ... 120SF5.pdf
Page 7 gives us all the DC specs for inputs, and p8-9 for outputs, corresponding to discussion here. To your point, there is a spec for worst case VIL and VIH, and for hysteresis. As hippy mentioned, your proposal for measuring these values with a pot will indeed discover values for the unit under test, but does not tell you what the range of values can be, as the datasheet will.

(Caution: values on that K64 datasheet should not be taken as shedding light on the values for RPi's SoC.)

[6by9]

I am employed by RPT as a software engineer, not for forum support. Any time I invest here is therefore my own, and is voluntary (frequently including time outside of working hours, such as now). That is the main reason I include the text "Views expressed are still personal views." in my forum signature - I am not reflecting official policy on anything.

As with most people, I have bad days. Push my buttons on a bad day and I will get tetchy. Having gone around in some circles on this thread, you apparently totally ignoring a response made by me (I did not make any comment about your mental capabilities) will hit those buttons hard, and you got a very annoyed response back. I shouldn't have, so I apologise.

To answer some of the outstanding comments on here:

• Hysteresis is enabled by the firmware. Linux is the only OS supported RPT and it does not provide any control over hysteresis. It will therefore be on.
• Gert has released some register information (I don't know with what permissions). The use of that data is not a supported configuration, therefore you are on your own if you alter those register values.
• The way I read the datasheet for how the hysteresis is working is that you will need to take the input below VIL for it to toggle to a 0, and above VIH for it to toggle to a 1, same as a Schmitt trigger. I will see if I can confirm that.
• Almost all the GPIOs have alternate functions (see the peripheral spec section 6.2). GPIOs 14&15 are configured by default as connecting to uart0 (txd and rxd respectively), therefore if you are wanting to use them as inputs you will have to reconfigure them, and that is the appropriate time to set pulling resistors. The default pulling is therefore irrelevant.
• pin_defines set up various GPIOs that the firmware controls, eg camera control, SMPS control, some LED control. Parts of it are covered in the Compute Module section of the documentation pages as there you will be wanting to configure the camera and display GPIOs. The only reference to a "2" I can see in the pins_3bplus section is

  Code: Select all

             [email protected]_PWR_OK {
                 type = "external";
                 number = <2>;
  }; 

  External (cf internal) is denoting that it is on the GPIO expander, so no it isn't going to touch GPIO2 on pin 3. There are no "collisions" between the normal GPIO header and any of these internal functions. Yes the documentation could be extended, but it is a very niche area so resource is generally better spent elsewhere.

As my time on here is voluntary I will be ignoring this thread from now on, except to report back should I get updated values for the electrical characteristics.

[gwideman]

I apologise.

Thank you.

you apparently totally ignoring a response made by me

I accept that it appeared that way to you, though as I explained subsequently, I paid specific attention to the point you had written. But let's move on.

I thank you for your most recent answers. A couple of points

Hysteresis

[*] The way I read the datasheet for how the hysteresis is working is that you will need to take the input below VIL for it to toggle to a 0, and above VIH for it to toggle to a 1, same as a Schmitt trigger. I will see if I can confirm that.

I think you're saying you infer the hysteresis to be the difference between VIH and VIL? That is not what the datasheet VIL and VIH tell us.

Taking the specs for the CM, for the VDD_IO=2.7V case...
(https://www.raspberrypi.org/documentati ... T-V1_0.pdf)
page 13, we have:
VIL, max column = 0.8V
VIH, min column = 1.3V

... and I think you're saying you infer the amount of hysteresis to be 1.3-0.8 = 0.5V.

VIH and VIL values on a datasheet are min and max values respectively across devices and temperatures, and have only a tangential relationship to hysteresis which would be a separate spec (not given on the CM datasheet). Note that the VIH row has a value in the Min col, and the VIL row has a value in the Max col. So these are the worst values you would expect to find on any individual device. So these are properly know as VIHmin and VILmax (appropriately subscripted, which I'm butchering here), as opposed to VIH and VIL that one might measure on a particular sample device at a particular temp.

(Because the min and max specs are so often needed, engineers might abbreviate those to just "VIH" and "VIL", dropping the min and max designators, because by context we know it's a population worst-case spec or manufacturing guarantee we're talking about).

A plausible hysteresis spec (VHYSmin) for this type of input would be say "minimum 0.2V". The spec presented is a minimum because the feature being provided is an amount of noise immunity (for slow-changing input signals), and thus the manufacturer guarantees that you get at least that worst case amount.

So the VILmax and VIHmin of the datasheet tell the worst-case values, outside of which range an input (on any random sample device at any temperature) will definitely interpret a logic zero or one. These specs do not relate to hysteresis VHYSmin, other than the hysteresis has to be contained within VIL/VIH. They specifically don't guarantee that any particular device requires crossing VILmax or VIHmin levels. Indeed, they almost guarantee that a specific device will not require crossing those values, as it's statistically unlikely that device is right at the edge of the worst-case spec. (And that's why you can't learn these worst-case specs by inspecting a few individual devices.)

Within this spec we might find an individual sample of the device (at some temperature) with the following behavior:
0->1 threshold at 1.15V and a 1-->0 threshold at 0.85V.

• That sample (at temp) has VHYS = 0.3V (0.1V "better" than the VHYSmin spec that I posited).
• It has a zero threshold at 0.85V (0.05V better than the VILmax spec 0f 0.8V).
• It has a one threshold at 1.15V (0.15V better than the VIHmin spec of 1.3V).

Hopefully that clarifies how hysteresis relates to VIL and VIH, and how the characteristics of an individual device relate to the datasheet min and max specs giving worst case values for the population of devices.

Interpretation of dt-blob info

The info you provided here adds to our understanding of what the sections of dt-blob mean, though I found a couple of points confusing. I'll expand a little here to make sure I got it right, and for others reading along, and maybe someone will correct if not.

> [type = ...] External (cf internal) is denoting that it is on the GPIO expander,

My distillation of these notes and previous discussion, with regard to interpreting the dt-blob file is:

• [email protected]<number> refers only to GPIO pins of the SoC. GPIO3 corresponds to [email protected]
• [email protected]<some_name> supplies a name for a pin either on the SoC (type = "internal") or of the GPIO expander chip (type="external").
• Here "GPIO expander" means an IO expander chip on the RPi (let's say RPi 3), previously linked as http://www.onsemi.com/PowerSolutions/pr ... id=FXL6408, (not shown on the abridged RPi schematic, and specifically not what google returns for "Raspberry Pi Expander", which would be boards external to the RPi to expand signals of the GPIO header.)
• The signals of interest on the RPi GPIO header are all connected to the SoC (not expander), and are GPIOs 2 through 27. None of these appear in the list of pin_defines (for 3b2 for example).
• So within a particular pins_xx block, (eg: pins_3b2), only the [email protected] and [email protected]<number> (number 2..27) blocks are pertinent to the GPIO header.

> so no it isn't going to touch GPIO2 on pin 3.
"pin 3" referring to pin 3 on the RPi GPIO header (ie: not to be confused with [email protected]).

> There are no "collisions" between the normal GPIO header and any of these internal functions.
Where "these internal" here means the functions mentioned in pin_defines marked "external", and also those marked "internal" but using GPIOs other than 2..27. That is, we know that functions mentioned in pin_define blocks are not on the GPIO header because "external" means associated with the on-board I/O expander, which does not serve the GPIO header. And other pin_defines marked "internal" have numbers not corresponding to the range on the GPIO header.

Again, thanks for your additional info, and looking forward to the answer to the DC Electrical Characteristics at VDD_IO 3.3V question when it becomes available.

[Several edits due to trickiness of avoiding typos and ambiguities etc.]

[hippy]

[*] The way I read the datasheet for how the hysteresis is working is that you will need to take the input below VIL for it to toggle to a 0, and above VIH for it to toggle to a 1, same as a Schmitt trigger. I will see if I can confirm that.

I think you're saying you infer the hysteresis to be the difference between VIH and VIL? That is not what the datasheet VIL and VIH tell us ...

VIH and VIL values on a datasheet are min and max values respectively across devices and temperatures, and have only a tangential relationship to hysteresis which would be a separate spec (not given on the CM datasheet).

That reflects how Microchip describe things in their datasheets. VIL (max) is the voltage below which an input is guaranteed to read low, VIH (min) is the voltage above which an input is guaranteed to read high, and is given this way for both TTL and Schmitt Trigger inputs.

Those values are not switching points, they do not specify when any particular chip may actually read low or high nor indicate what any hysteresis would be.

That issue came up when we had customers finding the hysteresis was a lot less than what they thought the datasheet was indicating and switching points were far away from the stated values.

As you say, without additional information, one can only say the actual points at which an input will switch from high to low or low to high will be somewhere between VIL (max) and VIH (min).

It is correct to say an input must be driven below VIL (max) for the input to be guaranteed to be read as low, must be driven above VIH (min) to be guaranteed to be read as high.

[gwideman]

Hippy I agree with your post, including the problem that people commonly misunderstand these specs, especially interpreting hysteresis to be the entire VIL..VIH range.

One other point:

That reflects how Microchip describe things in their datasheets.

Perhaps you meant Broadcom under discussion here, or perhaps you are comparing to Microchips's PIC MCU specs? Regardless, for readers who may not know, these specs are not at all peculiar to a particular manufacturer, they are ubiquitous in the industry.

For example, this book page 169: https://books.google.com/books?id=z9H8B ... &lpg=PA169 :
"These levels are characterised for each logic or microprocessor family, and worst-case values of VIL and VIH can be found on any datasheet."

[jamesh]

We are looking in to getting/generating the required data, might take a while.

Hopefully will result in an updated datasheet, plus an extra section on the docs part of the website.

[jamesh]

OK, the requested data (or at least quite a bit of it), has now been published in a new CM datasheet.

https://www.raspberrypi.org/documentati ... tasheet.md

and the specific table has been extracted to here

https://www.raspberrypi.org/documentati ... /README.md

(Note, formatting has gone a bit weird on the table between github and the site - will fix that now)

[vaypay]

Thanks a lot for this !

[gwideman]

OK, the requested data (or at least quite a bit of it), has now been published in a new CM datasheet.

Thanks jamesh for letting us know, and also to whoever assembled the data for 3.3V. A very useful step forward.

There is one significant missing spec, of the ones we discussed in this thread, and that's the input hysteresis spec. For GPIOs receiving outside-world signals, it's very useful that hysteresis is enabled, and it would substantially complete the real-world-interface picture to know the magnitude of that hysteresis.

That would be a VHYSmin value: effectively the minimum noise immunity that the inputs are guaranteed to provide.

This value may differ for the different VDD_IO levels.

In case there's confusion, as we've discussed earlier in the thread, the hysteresis value is not the same as the difference between the VILmax and VIHmin values, thought that's a common misunderstanding. At VDD_IO = 3.3V, the newly published data shows VIHmin-VILmax is 0.7V, and based on data of other comparable chips, VHYSmin is likely in the range of 0.1V to 0.25V.

Thanks again jamesh for the efforts.

[jamesh]

OK, the requested data (or at least quite a bit of it), has now been published in a new CM datasheet.

Thanks jamesh for letting us know, and also to whoever assembled the data for 3.3V. A very useful step forward.

There is one significant missing spec, of the ones we discussed in this thread, and that's the input hysteresis spec. For GPIOs receiving outside-world signals, it's very useful that hysteresis is enabled, and it would substantially complete the real-world-interface picture to know the magnitude of that hysteresis.

That would be a VHYSmin value: effectively the minimum noise immunity that the inputs are guaranteed to provide.

This value may differ for the different VDD_IO levels.

In case there's confusion, as we've discussed earlier in the thread, the hysteresis value is not the same as the difference between the VILmax and VIHmin values, thought that's a common misunderstanding. At VDD_IO = 3.3V, the newly published data shows VIHmin-VILmax is 0.7V, and based on data of other comparable chips, VHYSmin is likely in the range of 0.1V to 0.25V.

Thanks again jamesh for the efforts.

I'll alert the HW guy who did the work.

[jamesh]

OK, quick chat around the team, we will not be supplying that information, simply because Broadcom do not supply it to us, and we do not have the resources to determine it ourselves.

Not sure how significant the number actually is; in the past this GPIO block has been used by a number of mainstream manufacturers (Samsung, Apple, Nokia and others) who used Videocore of varying vintage in their products, without being supplied with this particular specification, so they must have managed somehow.

Sorry.

[Z80 Refugee]

Without a specification, the hysteresis is practically irrelevant*. Anyone needing input hysteresis in their project should provide their own.

* I've changed my mind. See later post:

Hysteresis is useful when taking an input voltage that varies relatively slowly - eg a switch debouncing circuit. In that context, I take back what I was saying about hysteresis being irrelevant without a specification (and it might as well be there as not).

Hysteresis specifications are vital if designing a circuit which depends on them for its operation, but that will be rare for general inputs to a processor (which are obliged to exceed Vin Hi Min to register as a '1' and Vin Lo Max to register as a '0').

[hippy]

Not sure how significant the number actually is; in the past this GPIO block has been used by a number of mainstream manufacturers (Samsung, Apple, Nokia and others) who used Videocore of varying vintage in their products, without being supplied with this particular specification, so they must have managed somehow.

When supplying a SoC with voltage levels which meet the specification there is little need to know what the hysteresis specifications are. For things like set-top boxes, phones and the like which those big names produce everything likely will be nice, clean digital, within spec.

Knowing the hysteresis and/or exact switching points is mostly useful for 'bodging things' and being able to utilise out of spec signals and the big boys won't usually be doing that. It is therefore not surprising Broadcom don't have those figures even though they can be useful for 'hardware bodgers' like myself.

Thanks for checking, and thanks for the other figures which are very useful.

[Z80 Refugee]

Hysteresis is useful when taking an input voltage that varies relatively slowly - eg a switch debouncing circuit. In that context, I take back what I was saying about hysteresis being irrelevant without a specification (and it might as well be there as not).

Hysteresis specifications are vital if designing a circuit which depends on them for its operation, but that will be rare for general inputs to a processor (which are obliged to exceed Vin Hi Min to register as a '1' and Vin Lo Max to register as a '0').

[gwideman]

Thanks again jamesh for getting back to us regarding the unavailability of the minimum hysteresis magnitude spec. So be it.

You would not be able to determine it definitively yourselves because the best you could do is a statistical analysis of measurements of a modest number of sample units, which would only hint at the limit value that Broadcom's manufacturing is set to remain clear of.

Regarding the "many players have succeeded without that spec" argument. As irrelevant as it has been throughout this thread. It's very likely that their products don't interface with unanticipated signals of the outside world, but rather with chips selected by themselves, using signals that have high-speed transitions, and with extremely short wiring. For those purposes, hysteresis is largely irrelevant. (Possible exception: GPIOs connected to physical switches.)

That said, just knowing that hysteresis is enabled is helpful (an earlier fruit of this conversation). The magnitude would have helped some additional calculations, and understanding of troubleshooting scenarios, but is of less import than the specs you did dig up for us.

Complementing a couple of recent comments:

The usefulness of understanding that hysteresis is enabled is almost entirely for understanding how tolerant the RPi3 is when supplied with slowly-varying input signals. Slow relative to small numbers of nanosec -- under which many experimenters' input signals would qualify.

Without hysteresis, two issues could arise:

1. Harmful intermediate state: As the slowly changing input signal (or even just an unconnected floating input) reaches the exact 0/1 threshold, it could spend an appreciable amount of time where, inside the SoC, one or more stages of input processing have both their high and low transistors turned on, effectively shorting the power supply. This creates unwanted noise on the ground and + supply, unwanted heat, and possible damage.

2. Susceptibility to noise: A slow transition from one logic state to the other, plus a small amount of noise on the signal, or on ground, would cause the MCU/SoC to see multiple transitions. This is particularly disruptive for edge-triggered activity, like interrupts, or incrementing built-in counters, and would also confuse the MCU when it's polling rapidly enough.

Among scenarios that are helped by hysteresis, a common one involves an input from a plain-old single-throw switch with a pull-up resistor (pushbuttons, microswitches). Here a switch press or flip results in multiple electrical state transitions due to mechanical switch bounce. Hysteresis doesn't directly help that.

But a common way to address the switch bounce is to add a capacitor across the switch, which "smooths out" the bounces, by making the transition slower (in combination with the R). Input hysteresis does help here, but one needs to examine this more closely to determine how adequate that solution is, and here magnitude of hysteresis would be a helpful number. (More cleanly, one would instead use a double-throw switch plus C and R, in which the switch has to move from one contact to the other to change state, and the new state is unaffected by bounce.)

And yes, of course one could use software debouncing, but that requires a whole additional processing function that has to keep track of time across several milliseconds, so a bit of a speed bump for quick-and-dirty experimenter scenarios.

There are other (relatively) slow-transition situations, such as an analog signal processed by op-amps into a binary result, but the transition speed is limited to the relative slow operation of op-amp output.

Finally I would add to hippy's comment about knowing switching points exactly, and using out-of-spec signals (and no doubt hippy knows all this, just adding it for other readers):

My impetus for starting this thread was not to be able to use out-of-spec signals, but rather to ascertain what signals would be reliably in-spec across different samples of RPi3. Such signals might be out-of-spec as inputs or outputs of (say) a typical LVC chip, by being slow-varying, or drawing a lot of current, and so on, but would be in-spec for connection to the RPi SoC.

It's true that one could go even further, and measure an individual RPi3 and determine, for example, its particular VinHi, VinLo (and thus hysteresis as well), and connect only-just-works signals to it. That's less interesting to me, because of the high likelihood that substituting a different RPi3 would not work.

Anyhow, this has certainly been an interesting thread. Thanks to all participants!

[Z80 Refugee]

It's really quite simple: do not apply a noisy signal to an RPi input and expect reliable results. Hysteresis protects inputs from a slow monotonic transition, not a noisy one.

All digital systems are susceptible to metastability. If an input isn't held at a defined logic level for the specified length of time before the sample clock edge, the output of the respective latching circuit may not be stable at the time it needs to be for the successive circuits - and that can cascade through the system.

If you have a noisy signal, by definition that's analogue and you need to make it non-noisy before applying it to a digital input. You must not rely on a little bit of input hysteresis to eliminate noise.

There is no need for the hysteresis on the RPi inputs to be specified, because you must supply input signals that meet the logic high and low voltage specifications. If your actual signals don't match the specifications, you need to provide conditioning before they get to the RPi.

[joan]

Is hysteresis really that difficult to measure. I sort of expected this to be a pretty standard test from a hardware viewpoint. Is there no standard testing device? Wouldn't something as simple as a digital POT allow a test?