[参考译文] LP-MSPM0L1306：将 PINCMx 寄存器中的 PF 字段更改为0x0时产生干扰

您好、Stefan：

有趣...让我们来看一下。

您好、Stefan：

我很抱歉耽误你的时间。

我设置它、但看不到您看到的内容。 PA10的行为与 PA25相同。  当它们被禁用时、它们与外部引脚断开连接、因此如果您看到任何残余信号/电压、而不是衰减至0v、则该引脚必须连接某种器件导致这种情况。

尊敬的 Dennis：

干扰非常短。 您绘图中的分辨率可能不够高。 因此、您必须在示波器上使用相当高的分辨率才能看到它。 我在测试中使用了2us、触发电平为2.8V、正如您在我上一篇文章中看到的图像所示。

此外、技术参考手册 MSPM0 L 系列32MHz 微控制器中的第9.2.5章规定、上拉/下拉电阻器的配置与外设功能配置无关。 图9-1也支持这一点。 TRM 中的超集 IO 切片。

那么我期望信号保持高电平、即3.3V。 这也是它在我的设置中的 PA10上的作用、不过两者之间存在干扰。

如果 ELF 文件有助于重现干扰、我可以在 LP-MSPM0L1306评估板上提供用于下载的 ELF 文件。

此致、

Stefan

我也看到了。 我的示波器测量值为400mV、可能持续3usec。

我想知道这是否 与 PA10为高速(HSIO)和 PA25为标准(SDIO)有关。

[编辑：根据数据表(SLASEX0D)第7.10.1节、VDD -0.4在 VOH (HSIO)规格范围内。]

非常感谢 Bruce 跳到这张幻灯片上。  我们总是超级感谢你的帮助！！！ ；)

我正在等待我们的设计人员回复这一问题。

这种干扰是否会导致您的应用出现问题？

是的、由于我们在该引脚上运行通信、这可能会导致该通信出现问题。

此致、

Stefan

您好、Stefan：

我对迟迟不答复表示歉意。  有2名系统设计人员研究了这个问题。  他们已验证您所看到的内容、并尝试确定根本原因以及是否存在解决方法。  我希望明天2月13日再次听到他们的声音。

您好、Stefan：

很抱歉耽误你的时间。  我们的设计人员花了几天时间来运行仿真并提出了一个解决方法。  以下是他们的注释、您会看到这种干扰的原因。

1. 输出模式(GZ=0)下的上拉行为：
   1. 当该引脚主动驱动时、内部上拉电阻断开、只有弱 PMOS 上拉电阻(输出驱动器的一部分)处于活动状态。
   2. PMOS 上拉电阻比内部上拉电阻弱得多、因此在时它无法强烈地保持电压 引脚转换为高阻抗。

2. 转换至高阻抗：
   1. 清除连接的引脚和 PF 后、该引脚会进入高阻抗状态。
      
      
      
      
   2. 此时、即使弱 PMOS 上拉电阻不再激活、并且内部上拉电阻(如果已启用)也会重新连接。
   3. 但仍然有一段短暂的时间、引脚悬空、电压仅由寄生电容保持(电容值在每个 IO 上可能会有所不同)。
      
      

3. 电压骤降和恢复
   1. 在转换到高阻抗期间(清除了 PF 和 PC)、弱 PMOS 上拉被禁用、内部上拉电阻需要时间才能重新连接和稳定电压。
   2. 由于漏电流导致电压骤降至2.24V、寄生电容会略有放电
   3. 内部上拉电阻完全激活后、会对寄生电容重新充电、从而使电压恢复到3.3V

此处有效的权变措施是在启用上拉时保持启用高阻态(Z1 = 1)、在这种情况下不会出现干扰。 我已经尝试了这种方法、在相同的配置但保持启用高阻态(Z1 = 1)的情况下、看不到电压骤降。

尊敬的 Dennis：

感谢您的详细回答。

我已经测试了您的解决方法、发现它在我的设置中也可以正常工作。

但是、当使用引脚 PA10作为 UART 的 TX 输出时、干扰仍然存在。 我们无法保持高阻态、因为我们正尝试在该 UART 上实现半双工通信。 切换到高阻态(Z1 = 1)或将备用功能从 UART 切换到禁用仍然会导致干扰。 不过、仅当通过 TX 发送数据时、才会看到干扰。

这是我使用的代码。 我已将 UART 波特率设置为1000000波特。

#include "ti_msp_dl_config.h"


__STATIC_INLINE void disableGPIO(uint32_t pincmIndex)
{
//    IOMUX->SECCFG.PINCM[pincmIndex] |= IOMUX_PINCM_HIZ1_ENABLE;
    IOMUX->SECCFG.PINCM[pincmIndex] &= ~(IOMUX_PINCM_PC_CONNECTED |  IOMUX_PINCM_INENA_ENABLE);
    IOMUX->SECCFG.PINCM[pincmIndex] &= ~(IOMUX_PINCM_PF_MASK);
}


int main(void)
{
    uint32_t i=0;

    SYSCFG_DL_init();

    // burn some time
    while(i<4700u)
    {
        __asm volatile("NOP");
        i++;
    }

    DL_UART_Main_transmitData(UART_1_INST, 0xA5);

    while(true==DL_UART_isBusy(UART_1_INST))
    {
    }

    IOMUX->SECCFG.PINCM[GPIO_UART_1_IOMUX_TX] |= IOMUX_PINCM_HIZ1_ENABLE;

    disableGPIO(GPIO_UART_1_IOMUX_TX);


    disableGPIO(GPIO_UART_Grp_PIN_PA25_IOMUX);


    while (1) {
    }
}

void SYSCFG_DL_GPIO_init(void)
{
    const uint8_t unusedPinIndexes[] =
    {
        IOMUX_PINCM3, IOMUX_PINCM4, IOMUX_PINCM5, IOMUX_PINCM10,
        IOMUX_PINCM12, IOMUX_PINCM16, IOMUX_PINCM17, IOMUX_PINCM18,
        IOMUX_PINCM19, IOMUX_PINCM22, IOMUX_PINCM23, IOMUX_PINCM24,
        IOMUX_PINCM25, IOMUX_PINCM27, IOMUX_PINCM1
    };

    for(int i = 0; i < sizeof(unusedPinIndexes)/sizeof(unusedPinIndexes[0]); i++)
    {
        DL_GPIO_initDigitalOutput(unusedPinIndexes[i]);
    }

    DL_GPIO_clearPins(GPIOA,
        (DL_GPIO_PIN_2 | DL_GPIO_PIN_3 | DL_GPIO_PIN_4 | DL_GPIO_PIN_9 |
        DL_GPIO_PIN_11 | DL_GPIO_PIN_15 | DL_GPIO_PIN_16 | DL_GPIO_PIN_17 |
        DL_GPIO_PIN_18 | DL_GPIO_PIN_21 | DL_GPIO_PIN_22 | DL_GPIO_PIN_23 |
        DL_GPIO_PIN_24 | DL_GPIO_PIN_26 | DL_GPIO_PIN_0));
    DL_GPIO_enableOutput(GPIOA,
        (DL_GPIO_PIN_2 | DL_GPIO_PIN_3 | DL_GPIO_PIN_4 | DL_GPIO_PIN_9 |
        DL_GPIO_PIN_11 | DL_GPIO_PIN_15 | DL_GPIO_PIN_16 | DL_GPIO_PIN_17 |
        DL_GPIO_PIN_18 | DL_GPIO_PIN_21 | DL_GPIO_PIN_22 | DL_GPIO_PIN_23 |
        DL_GPIO_PIN_24 | DL_GPIO_PIN_26 | DL_GPIO_PIN_0));

    DL_GPIO_initPeripheralInputFunction(
        GPIO_UART_1_IOMUX_RX, GPIO_UART_1_IOMUX_RX_FUNC);

    DL_GPIO_initPeripheralOutputFunctionFeatures(
         GPIO_UART_1_IOMUX_TX, GPIO_UART_1_IOMUX_TX_FUNC,
         DL_GPIO_INVERSION_DISABLE, DL_GPIO_RESISTOR_PULL_UP,
         DL_GPIO_DRIVE_STRENGTH_LOW, DL_GPIO_HIZ_DISABLE);

    DL_GPIO_initDigitalOutputFeatures(GPIO_UART_Grp_PIN_PA25_IOMUX,
         DL_GPIO_INVERSION_DISABLE, DL_GPIO_RESISTOR_PULL_UP,
         DL_GPIO_DRIVE_STRENGTH_LOW, DL_GPIO_HIZ_DISABLE);

    DL_GPIO_setPins(GPIO_UART_Grp_PORT, GPIO_UART_Grp_PIN_PA25_PIN);
    DL_GPIO_enableOutput(GPIO_UART_Grp_PORT, GPIO_UART_Grp_PIN_PA25_PIN);

}


static const DL_UART_Main_ClockConfig gUART_1ClockConfig_1 = {
    .clockSel    = DL_UART_MAIN_CLOCK_BUSCLK,
    .divideRatio = DL_UART_MAIN_CLOCK_DIVIDE_RATIO_1
};

static const DL_UART_Main_Config gUART_1Config_1 = {
    .mode        = DL_UART_MAIN_MODE_NORMAL,
    .direction   = DL_UART_MAIN_DIRECTION_TX_RX,
    .flowControl = DL_UART_MAIN_FLOW_CONTROL_NONE,
    .parity      = DL_UART_MAIN_PARITY_NONE,
    .wordLength  = DL_UART_MAIN_WORD_LENGTH_8_BITS,
    .stopBits    = DL_UART_MAIN_STOP_BITS_ONE
};

void SYSCFG_DL_UART_1_init(void)
{
    DL_UART_Main_setClockConfig(UART_1_INST, (DL_UART_Main_ClockConfig *) &gUART_1ClockConfig_1);

    DL_UART_Main_init(UART_1_INST, (DL_UART_Main_Config *) &gUART_1Config_1);

    DL_UART_Main_setOversampling(UART_1_INST, DL_UART_OVERSAMPLING_RATE_16X);
    DL_UART_Main_setBaudRateDivisor(UART_1_INST, UART_1_IBRD_32_MHZ_1000000_BAUD, UART_1_FBRD_32_MHZ_1000000_BAUD);

    DL_UART_Main_enable(UART_1_INST);
}

此致、

Stefan

如果 PF 您将 GPIO 设置为输出为1、然后更改为 PF = 1 (GPIO)、并按照 TRM 的第9.2.2节"逻辑高电平到 PF Hi-Z 转换"页面735、会发生什么情况？

您好、Stefan：

很抱歉、延迟的回复。  我已经向我们的设计人员分享了您关于 UART 半双工使用的后续问题。

Antony 引出了一个有趣的问题、但我认为是从 PF = UART (TX)切换到 PF = GPIO (=1)、还是从任何其他外设将该引脚驱动至 Hi-Z 状态、引脚上会出现一些电压泄漏、如上所述。  在转换到 Hi-Z 状态期间保持启用内部上拉电阻是合理的。

询问 Stefan -也许我对您的半双工拓扑没有完全了解、此引脚是否同时用于 UART TX 和 RX、换言之、半双工的"单线"类型？  或其他什么吗？  如果是、无论使用何种引脚、使上拉电阻器保持启用状态有何危害？

尊敬的 Dennis：  

我怀疑的一些事情：

1。 毛刺下降斜率的 dV/dt 看起来非常快。 与 UART 信号从高电平转换为低电平时的斜率大致相同。 这实际上只是通过使 PMOS 栅极放电来实现吗？ 您确定 NMOS 不会产生使其通电的干扰吗？

在 TI 设计工程师第2.a.部分中 上面、他们引用了 TRM 第735页：何时 未选择外设功能(PF =0) 。 输出锁存器 输入到 A 中 复位 状态、导致输出 NMOS 和 PMOS 被禁用(将 IO 引脚保持在 Hi-Z 状态、但任何启用的上拉/下拉电阻除外)。 如果 PF 设置为 GPIO、我认为这些输出锁存器保持开启状态、直到高阻态亮起？

只是想知道看看图9-1。 超集 IO 层、传输数据的:Output Logic"DOUT 路径独立于 Hi-Z 路径。 如果您设置 DOUT=ZERO、会在 PF 线上设置零吗？ 使用 GPIO =高电平然后处于高阻态可能会使 DOUT 线路保持高电平、因此没有竞争条件干扰 NMOS 的风险？

尊敬的 Anthony：  

我已经向我们的设计人员提出了这些问题。

嗨、Dennis、Gary 帮助我了解了图9-1。 超集 IO 切片图更好一点、我怀疑在外设级别可能有与 UART TXD 和 RXD 引脚关联的外设寄存器、这些寄存器不在 TRM 中。 如果与 SPI 外设类似、我想知道 UART TXD 引脚是否有偏移小于20h 的寄存器、该寄存器可能具有 HIGHZ1和 HIGHZ0位？ 如果是、它可以在 Hi-Z 外设仍处于连接状态时馈送 UART 输出多路复用器、因此无需设置 PF 0并获取干扰。

嗨、Antony 和 Stefan

据我所知、UART IP 中没有具有这些 HIGHZ1、Z0位的寄存器。  

以下是 Stefan 的问题...

Unknown 说：

但是、当使用引脚 PA10作为 UART 的 TX 输出时、干扰仍然存在。 我们无法启用 HiZ、因为我们正在尝试在该 UART 上实现半双工通信。

youfa xiong 说：

所以向 Stefan 提问-也许我对半双工拓扑没有完全了解、所以此引脚是否同时用于 UART TX 和 RX、换言之、是"单线"半双工"类型？  或其他什么吗？  如果是、无论使用何种引脚、使上拉电阻器保持启用状态有何危害？

很抱歉再次询问、但您能解释一下为什么在启用高阻态的情况下启用内部上拉电阻器不合适吗？

尊敬的 Dennis：

是的、它是通过一根线进行的半双工通信。 参与通信的两个 UC 上连接了 TX 和 RX。 当一个 UC 发送完毕后、它会将 UART 切换到仅 RX 模式、需要禁用 TX 引脚、以便另一个 UC 连接并发送数据。

在我们的应用中、始终启用 RX 上的上拉电阻器。 保持高阻态始终处于启用状态会导致 UART 线路上的信号失真以及通信问题。

根据您的请求、我在 TX 上使用47.5k Ω 的外部上拉电阻进行了测试、代码如前所述、在 UART1上发送了一个字节。 这不会改变干扰。 不过、使用3k Ω 上拉电阻可以略微降低干扰、但总共没有解决问题。

此致、

Stefan

您好、Stefan：

非常有趣。  我认为上拉电阻会使 TX 引脚保持高电平、并通过防止任何引脚电容放电来消除尖峰。  但对我来说、这几乎听起来逻辑中有某种东西、在很短的时间内、尝试在变为高阻态之前将引脚拉至低电平  我更新了我们的设计人员、看看他们是否能解释。

您好、Dennis & Stefan、正如您在我的其他相关文章中所知道的、我想做一件类似的事情、除了使用 SPI：

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1475464/mspm0l1306-spi-single-bidirectional-pico-poci-for-hoperf-module-interface/5695905#5695905

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1486538/mspm0l1306-peripheral-register-access---unexpected-interrupt-for-spi-registers-lower-than-0x0800h-offset

我认为、在保留所选外设的同时实现快速硬件 IO 更改方法的选项已消失。 而且、如果在 GPIO 选择6位模式中、= UART (或在我的情况下为 SPI)到 PF = 1 (PF)之间的位模式变化一次超过一位、则先前在不使用建议的 PC 断开连接的情况下跳转到 GPIO PF PF 动态选择的方法仍可能导致干扰。

我期待设计团队的回应。

此致、

安东尼  

大家好！

我想给大家一个关于这个问题的更新。  我们的设计工程师目前很忙、没有机会查看这些最新信息。

您好、Stefan：

我想与您核实您是否能够继续推进您的项目、尽管现在出现了这些故障、还是这是一个"限量"？  我想重新与我们的设计师联系、让他们知道、以便他们可能会参与到这个问题上。