This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] MSPM0G3107:在 i2c 中断模式下、控制器在读取操作中不提供确认。

Guru**** 2393725 points
Other Parts Discussed in Thread: MSPM0G3107, SYSCONFIG

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1512256/mspm0g3107-controller-is-not-giving-ack-in-read-operation-in-i2c-interupt-mode

器件型号:MSPM0G3107
主题: SysConfig 中讨论的其他器件

工具/软件:

您好、

我正在为我的项目使用 TI mspm0g3107微控制器,在这里我使用 i2c 来控制我的显示器和 EEPROM。

当我继续尝试使用示例代码 i2c_controller_rw_multibyte_fifo_interrupts 从 EEPROM 写入和读取时遇到问题

在这种情况下、如果我在读取和写入操作之间提供延迟、那么只有我能够读取。  

我不想使用假阳具、因为在我的实际项目应用中、它会延迟我的循环周期。

我为您提供 SysConfig 和代码。

e2e.ti.com/.../i2c_5F00_controller_5F00_rw_5F00_multibyte_5F00_fifo_5F00_interrupts.c

/**
 * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
 * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
 * @cliArgs --device "MSPM0G350X" --part "Default" --package "LQFP-64(PM)" --product "mspm0_sdk@2.04.00.06"
 * @v2CliArgs --device "MSPM0G3507" --package "LQFP-64(PM)" --product "mspm0_sdk@2.04.00.06"
 * @versions {"tool":"1.22.0+3893"}
 */

/**
 * Import the modules used in this configuration.
 */
const GPIO  = scripting.addModule("/ti/driverlib/GPIO", {}, false);
const GPIO1 = GPIO.addInstance();
const I2C   = scripting.addModule("/ti/driverlib/I2C", {}, false);
const I2C1  = I2C.addInstance();

/**
 * Write custom configuration values to the imported modules.
 */
GPIO1.$name                          = "GPIO_LEDS";
GPIO1.port                           = "PORTA";
GPIO1.associatedPins.create(2);
GPIO1.associatedPins[0].$name        = "USER_LED_1";
GPIO1.associatedPins[0].initialValue = "SET";
GPIO1.associatedPins[0].assignedPin  = "0";
GPIO1.associatedPins[1].$name        = "USER_TEST";
GPIO1.associatedPins[1].initialValue = "SET";
GPIO1.associatedPins[1].assignedPin  = "15";

const Board                       = scripting.addModule("/ti/driverlib/Board", {}, false);
Board.peripheral.$assign          = "DEBUGSS";
Board.peripheral.swclkPin.$assign = "PA20";
Board.peripheral.swdioPin.$assign = "PA19";

I2C1.basicEnableController             = true;
I2C1.basicControllerBusSpeed           = 400000;
I2C1.advControllerTXFIFOTRIG           = "BYTES_1";
I2C1.intController                     = ["ARBITRATION_LOST","NACK","RXFIFO_TRIGGER","RX_DONE","TX_DONE"];
I2C1.$name                             = "I2C";
I2C1.advAnalogGlitchFilter             = "DISABLED";
I2C1.peripheral.$assign                = "I2C1";
I2C1.sdaPinConfig.$name                = "ti_driverlib_gpio_GPIOPinGeneric0";
I2C1.sdaPinConfig.hideOutputInversion  = scripting.forceWrite(false);
I2C1.sdaPinConfig.onlyInternalResistor = scripting.forceWrite(false);
I2C1.sdaPinConfig.passedPeripheralType = scripting.forceWrite("Digital");
I2C1.sclPinConfig.$name                = "ti_driverlib_gpio_GPIOPinGeneric1";
I2C1.sclPinConfig.hideOutputInversion  = scripting.forceWrite(false);
I2C1.sclPinConfig.onlyInternalResistor = scripting.forceWrite(false);
I2C1.sclPinConfig.passedPeripheralType = scripting.forceWrite("Digital");

const SYSCTL                 = scripting.addModule("/ti/driverlib/SYSCTL", {}, false);
SYSCTL.forceDefaultClkConfig = true;
SYSCTL.clockTreeEn           = true;

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
GPIO1.associatedPins[0].pin.$suggestSolution = "PA0";
GPIO1.associatedPins[1].pin.$suggestSolution = "PA15";
I2C1.peripheral.sdaPin.$suggestSolution      = "PA10";
I2C1.peripheral.sclPin.$suggestSolution      = "PA11";

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    典型的 EEPROM 需要一些时间来写入您请求的页面。 这会在其数据表中提到(可能命名为"TWR"等内容)、但通常为3ms 至5ms。 在此期间、I2C EEPROM 会关闭其 I2C 接口、因此您将看到 NACK。

    我不知道有任何 EEPROM 会在它再次准备就绪时通知您。 通常的策略:

    1) TWR 的显式延迟。 您提到了您不想执行此操作、但如果您使用 RTOS、这种情况并不会太麻烦。

    2)重复发送0长度(即良性) I2C 写入请求、直到您获得 ACK。 这也是"忙碌"、但完成时间通常短于 TWR。 这通常称为"阿克投票"。

    3)重试 EEPROM 读取(或下一次写入)请求、直到成功(可能在 TWR 处超时)。 这样做的优点是提供了回写功能、即在执行其他操作时、EEPROM 的部分(甚至完全)写入完成;您只会在需要时(以及需要的时间内)等待。

    [编辑:细微澄清。]