Wrong documentation for the slew rate (SRE) setting for pads

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Wrong documentation for the slew rate (SRE) setting for pads

Jump to solution
133 Views
stefano-quantic
Contributor III

I'm using iMXRT1176 and MCUXpresso IDE (v11.8.0 [Build 1165] [2023-07-26]).

Many pads have a "Slew rate" option, to choose between "fast" and "slow" rise/fall times.

The datasheet ("IMXRT1170IEC", Rev. 5, 01/2024) describes the correct behavior. For example, in table 40, "AC specifications for GPIO_AD/GPIO_LPSR/GPIO_DISP_B2 bank", we see that the rise/fall time in normal conditions is 3ns (row #1, DSE = 0, SRE = 0), and the rise/fall time is 6ns when the slew rate is limited (row #2, DSE = 0, SRE = 1).
From physical testing, it is indeed the case that SRE=0 results in fast transition times, while SRE=1 results in slower times, so that SRE seems to mean "Slew-rate-limiter enable".

However, the reference manual and all the source code uses the opposite (wrong) meaning: 0 is "slow", 1 is "fast".

In the reference manual ("IMXRT1170RM", Rev. 2, 06/2023):
* Table 11.2 indicates "SRE - Fast slew rate" (which implies that SRE=1 means "fast")
* Section 12.4.4.18.4 indicates:
====
SRE - Slew Rate Field
[default value: 0]
Select one out of next values for pad: GPIO_LPSR_00
0b - Slow Slew Rate
1b - Fast Slew Rate
====
This section is for SW_PAD_CTL_PAD_GPIO_LPSR_00, but a similar one appears for all the other pads with SRE capability (§12.4.6.210.3, §12.4.6.276.3, etc.).

The source code file "board/pin_mux.c" present in the SDK examples, contains the wrong definitions (used with the SETUP, SETUPG macros):
====
#define DISP_B2_SLEW_FAST (1<<0) /* fast slew rate */
#define DISP_B2_SLEW_SLOW (0<<0) /* slow slew rate */
#define AD_SLEW_FAST (1<<0) /* fast slew rate */
#define AD_SLEW_SLOW (0<<0) /* slow slew rate */
#define LPSR_SLEW_FAST (1<<0) /* fast slew rate */
#define LPSR_SLEW_SLOW (0<<0) /* slow slew rate */
#define SNVS_SLEW_FAST (1<<0) /* fast slew rate */
#define SNVS_SLEW_SLOW (0<<0) /* slow slew rate */
====

The code generated by Config Tools is wrong too. For instance, choosing "Fast slew rate" in the GUI, leads to the following code being generated in "board/pin_mux.c":
====
- {pin_num: L17, peripheral: LPSPI1, signal: SCK, pin_signal: GPIO_AD_28, direction: OUTPUT, pull_up_down_config: no_init, pull_keeper_select: Keeper, slew_rate: Fast}

IOMUXC_SetPinConfig(
IOMUXC_GPIO_AD_28_LPSPI1_SCK, /* GPIO_AD_28 PAD functional properties : */
0x03U); /* Slew Rate Field: Fast Slew Rate
Drive Strength Field: high drive strength
Pull / Keep Select Field: Pull Disable, Highz
Pull Up / Down Config. Field: Weak pull down
Open Drain Field: Disabled
Domain write protection: Both cores are allowed
Domain write protection lock: Neither of DWP bits is locked */
====
SRE is bit #0, so the configuration 0x03U has this bit set to 1 (meaning "fast", which is wrong).

The wrong description is also present in the debugging "Peripherals" view, in MCUXpresso.
For instance, for IOMUXC.SW_PAD_CTL_PAD_GPIO_AD_28.SRE, the values shown are "SRE_0_Slow_Slew_Rate" and "SRE_1_Fast_Slew_Rate".
Also, for IOMUXC.SW_PAD_CTL_PAD_GPIO_AD_28.DSE, the values shown are "DSE_0_normal_driver" and "DSE_1_high_driver".

Labels (1)
0 Kudos
1 Solution
63 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, sorry for the late response, I made the report, and the department told me the fixed document will scheduled in June.

SRE = 1 means slow slew rate.
So, when the tool follows RM, the result is also wrong.

Best regards,
Pavel

View solution in original post

0 Kudos
2 Replies
64 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, sorry for the late response, I made the report, and the department told me the fixed document will scheduled in June.

SRE = 1 means slow slew rate.
So, when the tool follows RM, the result is also wrong.

Best regards,
Pavel

0 Kudos
103 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, my name is Pavel, and I will be supporting our case, let me get into your case, when I have more information, I will contact you.

Best regards,
Pavel

0 Kudos