• State Resolved
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 83 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM0C1104-Q1: Muxing I2c_clk and nRST

Blake Carpenter
Expert 7245 points

Part Number: MSPM0C1104-Q1
Other Parts Discussed in Thread: SYSCONFIG

Hi, 

My assigned focus customer in the automotive space is trying to get LIN and i2c working using the 16 pin package.

The only choice for i2c is to use the nRST pin as a i2c_SCL.

The are using a JLINK and IAR as their tool chain.

They have their code working on the 20 pin EVM (which uses PA11 instead of PA1 / nRST for I2c_SCL).  When they try and port it to the 16 pin and have to share nRST and I2c_SCL it breaks the code.

The customer has disabled nRST

Will they be able to use i2c normally - but still be able to reprogram the part with the JLINK at reset?  Are there tricks to get the part to connect to the JLINK when power cycling to initiate the ability to reprogram?

Best Regards, Blake

 

 

  • 0
    TI__Mastermind 32145 points

    Hi Blake,

    Blake Carpenter said:
    Will they be able to use i2c normally - but still be able to reprogram the part with the JLINK at reset?

    No, when you disable NRST, it can not enter reset state via NRST pin.

    A power cycling with NRST held low can work. 

    Blake Carpenter said:
    Are there tricks to get the part to connect to the JLINK when power cycling to initiate the ability to reprogram?

    I think we can try add a certain delay before disable NRST which reserve a time window for reset after power cycling.

    Additionally, without NRST held low, the debugger should maintian the ability to reprogram, unless the MCU enter fault stauts.

    B.R.

    Sal

  • 0 in reply to Sal Ye
    TI__Expert 7245 points

    Hi Sal, 

    Thanks for the help!

    I just met with the customer today.  They have i2c working on the EVM with i2c_SCL on PA11.

    When they attempt to move i2c_SCL to the PA1 / nRST pin they no longer get a i2c_SCL clock.  This is true for their board OR their EVM.  Keep in mind they have the obsolete Rev B EVM.

    I will send you their sysconfig file by email.  I suspect a problem their.  I am reviewing as well.  

    Do you know the i2c limitations with the REV B EVM vs the E3 EVM?

    Thanks!

    Best Regards, 

    Blake

  • +1 in reply to Blake Carpenter
    TI__Expert 7245 points

    All, 

    So Owen in Dallas Apps did some work that I will detail here:

    What can the customer do to create the I2C_SCL signal on PA1 on a B rev EVM?

    Owen:  PA0 and PA1 are open-drain pins, you will need to ensure that there are external pull-ups on the pins. On the LaunchPad, populating jumpers on J6 and J8 should satisfy this. Also ensure that NRST is disabled. Seems like they have done this in their SysConfig file.

    Here's what I see when I run an SDK example. It NAKs because I have no target attached.

    As for "Can you Debug while the nRST is repurposed as I2C_SCL" - 

    Owen says:

    For SWD you do not need the NRST pin to program or debug. I used an XDS110 and only connected the following: SWDIO to SWDIO, SWCLK to SWCLK, 3V3 to VTREF, and GND to GND. I have not done this with a JLINK, but it should not be different since SWD is a standardized protocol.

    If Owen is able to debug while removing the nRST jumper on the XDS110 - it should be possible to debug using the JLINK.

  • 0 in reply to Blake Carpenter
    TI__Expert 7245 points

    The customer tried suggestions above:

    I had already tried the methods suggested in the forum, including using the XDS110 debugger for flashing and debugging with NRST and I2C_SCL configured on PA11 and PA1, respectively. In this configuration, I did not encounter any issues with either I2C functionality or debugging when the XDS110 debugger was connected.

    As a next step, I evaluated the J-Link debugger for flashing and debugging using the same NRST and I2C_SCL configurations. When I2C_SCL was configured on PA11 and J-Link NRST was connected, both debugging and I2C communication worked correctly without any issues.

    However, when I2C_SCL was configured on PA1, although I was able to enter debug mode successfully on the Rev B EVBs, the I2C interface reported a status error and communication was not functional. I2C operation was restored only after disconnecting the J-Link debugger and resetting both the controller and target devices.

    The answers for your below email are as follows:

    Regarding Point 1: [TI asked the customer to try the XDS110 on their board] Since an XDS110 debugger is not available in our setup, we are unable to carry out this verification at the present time.

    Regarding Point 2: [TI asked if the customer had tried the TI tool suite] The analysis referenced above was conducted using TI's i2c_controller_rw_multibyte_fifo_interrupts

    I was able to flash the TI MCU successfully. However, I did not observe any clock signal on those pins. I also removed the resistor connecting our reset circuit and observed the same behavior.

  • 0 in reply to Blake Carpenter
    TI__Expert 7245 points

    I have asked the customer to contact IAR about the JLink Driver as it appears that the IAR driver is expecting a certain behavior on the nRST line.  I have also given them 4 wires to jumper over to test the XDS110 (which appears to be functioning correctly) onto their board and also notes on the potential of getting the XDS110 to work on EWARM (as a workaround)

  • 0 in reply to Blake Carpenter
    TI__Mastermind 32145 points

    Hi Blake,

    Thanks for your udpate

    B.R.

    Sal