I have an ATWILC3000 wifi module connected to a Raspberry Pi Compute Module 3+ over 4-bit SDIO. It's throwing a lot of bus errors at higher frequencies (currently running at 1 MHz for stability when it should be closer to 50 MHz). In probing the bus, I found that the rise/fall times of the clock line are substantially worse than the data lines in violation of the 5ns maximum specified by Microchip for the clock. Shown below is the (presently 5 MHz) clock on scope CH1 (yellow) and D0 on CH2 (green):

scope trace

I can't seem to figure out why the clock line would be loaded down more than the data line, especially to that degree. Here's what I've looked at so far:

  • My oscilloscope probes are both set to 10X (10 Mohm/15 pF).
  • The issue is consistently on the clock line if I swap scope channels.
  • The rise/fall time numbers don't seem to change much at all as I vary the bus frequency in the OS config.
  • I have not looked at the CMD or other data lines yet.
  • The PCB is designed for a 50 ohm impedance on this bus.
  • All bus traces have the same number of vias (2) and are length matched to 38mm +/- 0.5mm. The clock line is on the longer side of this, but I wouldn't expect that to make this much of a difference.
  • Pullup resistors on the PCB are identical for the whole bus (47 kOhm to 3.3V).
  • I can't find anything in either datasheet that would indicate a variation in input capacitance on the clock line.
  • The rise time of the data line is within the realm of what I expected with the scope probe loading it down. I was looking at the bus edges because Microchip recommends trace impedances of 50, 68, or 75 ohms depending what piece of documentation you're reading.
  • The output driver strength of the ATWILC3000 is 13.5mA typical.
  • The default output current setting of the Pi CM3+ is 8mA. This is configurable (16mA max), but I'm not sure how to do it myself just yet. I think I found out how in the Linux Device Tree and I can't find anything other than the default 8mA in my current configuration.
  • I read through the driver source for the ATWILC3000 and couldn't find anything in there that would suggest that it has any control over GPIO drive strength (as expected).

Given the above, I'm wondering about the Pi drive strength. I know the Pi is sourcing that clock, but I don't know which direction the data lines are being driven in any given scope capture. If my good data rise times are coming from the wireless module, that would suggest the Pi is to blame.


1 Answer 1


As I suspected, I was able to resolve this by increasing the drive strength of the Pi GPIO to 16mA for all of the pins on the bus. I'm fairly certain that what I was seeing was the ATWILC3000 driving the data line while the Pi was driving the clock. With that change, I am now able to operate at 25MHz without issues.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.