4

I’ve noticed that if measure the rise time of GPIO on a CM3+L in a carrier board, I get very different results. GPIO22 for example, manages <2ns, which seems inline with the electrical specification. But GPIO34 barely manages 12ns.

This is after controlling for parasitic capacitance, trace impedance and measurement error.

I see from http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications that drive strength is controlled by enabling parallel drivers. But I don’t know if:

  1. This is specific to certain versions of the Pi.
  2. Whether this is under software control.
  3. Whether the pin mode limits/dictates the options. Is there some auto bandwidth control going on or something?
Heath Raftery
  • 265
  • 1
  • 8

2 Answers2

2

A few facts:-

All Pi models up to Pi4 have identical peripheral modules. The Pi4 is different, although AFAIK almost electrically identical and similar functionality.

You can set GPIO drive strength, slew and hysteresis. The settings apply to all GPIO in the group.

The only tools I know which facilitate this are pi-gpio, Pi.GPIO & pigpio (not sure if this handles slew). See https://raspberrypi.stackexchange.com/a/117592/8697

My pi-gpio/examples/getPAD shows (which is the default although this differs between models):-

Pi 3 Model B+
slew = 1 
hyst = 1 
drive = 3

Pi 4 Model B
slew = 1 
hyst = 1 
drive = 7 

  NOTE You need to be running as root to use these functions

int getPAD(unsigned group) - Return the current PAD settings (slew, hyst, drive)
   group: - 0-2


Returns
   padstate: - 0-0xF
   slew = (padstate >> 4) & 1
   hyst = (padstate >> 3) & 1
   drive = padstate & 7


void setPAD(unsigned group, unsigned padstate) - Set the PAD (slew, hyst, drive)
   group: - 0-2
   padstate: - 0-0xF : padstate = slew << 4 | hyst << 3 | drive

NOTE This is not documented in Peripherals documentation and was undocumented but is now listed at GPIO PADs Control

Milliways
  • 59,890
  • 31
  • 101
  • 209
  • Oh, that’s interesting! There’s a lot of misinformation (or missing information) out there so this eye-opening. Do you know if the device tree supports these settings (so drivers can take advantage at boot), or only pull and function? – Heath Raftery Oct 25 '22 at 07:45
  • There is peripheral documentation (but it is incomplete). You may be able to write a custom dtb but AFAIK there is no official support. I wrote my code while exploring hysteresis because I could not find any documentation. – Milliways Oct 25 '22 at 07:49
  • Wow. That was exactly it. Using Pi.GPIO I found get_PAD(0) == (1,1,3), get_PAD(1) == (1,1,0) and get_PAD(0) == (1,1,3). Since GPIO34 is in group 1, I ran set_drive(1,3) and rise time immediately dropped from 12ns to about 2.5ns. And that's despite the pin being configured for the SD1 function and in active use running the clock for the WiFi chip! Also, this is the mysterious missing documentation that seems to be otherwise hidden from view: https://www.scribd.com/doc/101830961/GPIO-Pads-Control2 – Heath Raftery Oct 25 '22 at 10:23
  • 1
    For posterity, it turns out the dt-blob for the CM3 doesn't contain a drive strength setting for any pin in bank 1, and the logic is to set the drive strength to the lowest acceptable setting. Hence why bank 1 is set to 0 on a CM3! This is easy for us to change, like demonstrated here for the RPi 3: https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts#L1167-L1172 – Heath Raftery Oct 26 '22 at 04:57
0

If you look at the specifications for the processor they will give you that information but they also qualify it by stating what the port load is with ie. capacitance, VCC voltage, resistance and other parameters if required. The way we did it was using a good scope and an environmental oven. We then loaded each pin to specification (determined by experience with the process) and cycled them measuring rise and fall times on the scope over time. We would then adjust appropriately. This was not a short lab exercise.

This was done over several batches of processors. The results were checked and a specification written that we could meet 100% of the parts. That safety margin was called (guard band).On the production floor we had test equipment that would do it for us. If we did not measure it we would state by design.

Contrary to many beliefs there is a lot of engineering time spent in writing a data sheet. The manufacturer guarantees the part to meet the specification, no more. Yes they use a guard band but that is not consistent, it changes from lot to lot but the part will do what the data sheet states.

Gil
  • 1,228
  • 4
  • 5
  • Wow, great insight. Yes, I'm well aware of the effort that goes into it and understand the caveats involved. Turns out (as per the accepted answer) I just had to set the drive strength correctly! Now it's meeting spec nicely. – Heath Raftery Oct 26 '22 at 04:51