Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings
- Dominant language
- C
- Stars
- 4k
- Forks
- 1.7k
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 237
Description
Discussion from [STM32 IO compensation cell initialization fix. Discussion](https://github.com/apache/incubator-nuttx/pull/1544#issuecomment-671897714)
I discovered some issues with the massive over shoot on SPI. (way out of spec, MAX VIH to the receiving IC's) I am sure there are others. This is total a HW use case dependent setting and effects EMI, crosstalk etc.
I think we need to do a pass on ALL the pin mux files to removes the slew-rate setting from the pin maps. Unfortunately has massive ripple effects and will need to be done in such a way to allow an override, and not break all the boards.
@fjpanag:
@davids5 I think that the default slew rate is for 50Mhz. This is not excessive for SPI.
This seems like a hardware design problem (lines termination etc), and I don't thing we should make a change in NuttX for this. It make break other user's code. Maybe we should add a new configuration in Kconfig, so the user can select the slew rate for every SPI, while keeping the default at 50Hz.
(As a side note, ringing usually does not have enough energy to cause latch-ups in other chips, although max. VIH is violated. But of course you know better, as you tested the actual hardware...)
@davids5:
>@davids5 I think that the default slew rate is for 50Mhz. This is not excessive for SPI.
I here you, I original thought the same thing, hence the defaults*.
> This seems like a hardware design problem (lines termination etc), and I don't thing we should make a change in NuttX for this.
This is the point. The line termination and characteristic of an interface is hardware dependent, really board dependent.
1) Signal integrity is effected. (cross talk) but over driving the lines.
2) FCC certifications is effected by slew-rate (drive strength).
Our EE group (amazing Wizards) have suggested we want to set the minimum drive strength that achieves quality signal integrity and no more.
Contrast a board 3 x 3 cm PCB (controlled impedance) with an SoC and SPI to devices on it and one with connectors and cables to it devices. The impedance will vary greatly. This really requires looking at the signals (with proper equipment) and adjusting drive strength correctly.
>It make break other user's code. Maybe we should add a new configuration in Kconfig, so the user can select the slew rate for every SPI, while keeping the default at 50Hz.
Yes I 100% agree we should not make a change that is breaking, and I would choose to default it as is.
> (As a side note, ringing usually does not have enough energy to cause latch-ups in other chips, although max. VIH is violated. But of course you know better, as you tested the actual hardware...)
The failure was on an H7 using SPI DMA on a mems sensor 7mm from the SoC. When the clock was continuous because of the DMA the device failed at the high drive strength. Lower it and it works. Probe it with a 10X 14pf Probe and it works. Probe it with .9 pf active Probe and you see .7V over VDD on every rising edge.
My suspicion is that the current injection to the substrate via the body diodes, caused the ADC to or loose its bias and clamp as the data was a FIFO full of 00s. Lower the drive strength and once the over shoot was gone it works fine.
The code need to fix the overcome the problem is [ugly and does not scale well](https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v6x/nuttx-config/include/board.h#L411) but moreover we [state](https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/hardware/stm32h7x3xx_pinmap.h#L67-L70) the setting should be done in board.h. We (I) broke that contract based on *above.
This opens another heated can of worms. There are defaults. where the pin mux has only one appearance. These will need to be have numbers added (I suggest _0 to make it obvious). To allow proper usage. Again massive ripple.
Contributor guide
Assessment
This issue has not been assessed yet.