SSP 1.7.5 IIC not opening; does on SSP 1.5

I've got a project that uses the touch screen and SX8650 (I've converted the driver from 8654).  This works fine on SSP 1.2.1 and SSP 1.5.0-RC1 but the open in the driver before the user GUI thread starts fails in SSP 1.7 with and SSP_ERR_ABORTED status code being returned in r_riic.c (line 1157).  On exactly the same board so I know this isn't a hardware problem per se.

Anyone seen this and have any idea what is the problem here?  I haven't gotten deep enough into it to figure it out just yet...

  • Looking at the I2C bus in question, I see no activity on it at all meaning the write in question isn't even starting.
  • In reply to rjl:

    Good day, rjl!

    How are things going so far? It seems that it might have something to do with the update. Have you referred to the SSP 1.7.5 user's manual yet?

    Best regards,
    Sai
    RenesasRulz Forum Moderator
    https://renesasrulz.com/
    https://academy.renesas.com/
    en-us.knowledgebase.renesas.com/

  • In reply to Sai:

    I wasn't working on this yesterday, but this is a bit strange. This is all happening inside canned code so far basically, almost none of mine (what would be none of mine if I hadn't make some tweaks to it). This happens during the bring up of the framework before it the use portion of the GUI thread so this is all happening before I have control of it.
  • In reply to rjl:

    What happens here is we come into gui_thead.c via the gui_thread_func() which at like 488 calls sf_touch_panel_i2c_init0()

    This calls the open of of sf_touch_panel_i2c.c via:
    ssp_err_g_sf_touch_panel_i2c0 = g_sf_touch_panel_i2c0.p_api->open(
    g_sf_touch_panel_i2c0.p_ctrl, g_sf_touch_panel_i2c0.p_cfg)

    that (line 181) does an open call which works.

    at line 185 it does: a p_ctrl->p_chip_reset(p_ctrl); which is the reset of touch_panel_i2c_sx8454.c (which I've changed up a little bit to deal with the sx8650 and some other issues that happen with people putting a finger ont he touch panel prior to it talking to it)

    SX8654_reset() goes along reseting carious things and then attempts to set up the part with a write of various registers. It is that write that never attempts to do anything on the bus but comes back with the SSP_ERR_ABORTED message. This happens without bus traffic at all (not even a start condition).

    that, of course, sets the SSP_ERR_INTERNAL which comes back and into the various error trapping places...

    So this is all happening in the first place where we attempt to do anything on the I2C bus itself.   The Aborted message froms from r_riic.c line 1157 so it must have soemthing to do with the interaction of the I2C driver and the DMA stuff somehow as the code bit

            while (transaction_completed)
            {
                /* The transfer descriptor is updated during interrupt processing */
                if (BSP_LOCK_UNLOCKED == p_ctrl->resource_lock_tx_rx.lock)
                {
                    transaction_completed = false ;
                }
            }

    is existing the while loop with p_ctrl->err set true (via p_ctrl->resource_lock_tx_rx.lock being BSP_LOCK_UNLOCKED)

  • In reply to rjl:

    One interesting thing: While looking through configurration.xml I noticed on the project I used as a basis for this (SSP 1.5)

    <synergyPinConfiguration>
    <pincfg active="false" name="R7FS3A77C3A01CFB.pincfg" symbol="g_bsp_pin_cfg"/>
    <pincfg active="true" name="R7FS5D97C3A01CFB.pincfg" symbol="g_bsp_pin_cfg"/>
    </synergyPinConfiguration>

    This project uses the 5D9 part and was itself an update from a very early S3A7 part project so I guess I can see that we'd have artifacts of that around.

    The updated project has this:
    <synergyPinConfiguration>
    <pincfg active="false" name="R7FS3A77C3A01CFB.pincfg" symbol="g_bsp_pin_cfg"/>
    <pincfg active="false" name="R7FS5D97C3A01CFB.pincfg" symbol="g_bsp_pin_cfg"/>
    <pincfg active="true" name="R7FS7G27G2A01CBD.pincfg" symbol="g_bsp_pin_cfg"/>
    </synergyPinConfiguration>

    BUT when I open this with the configuration tab in the IDE, it is showing the project is using the S5D9 part so I'm not entirely sure that this section actually means. Does this imply the tool is confused and some of it thinks I'm using an S5D9 part and some of it thinks I'm using an S7G2 one? If so, it'd sure make IIC fail when it tried to actually touch the chip...

    Also in the open parts of this:

      <generalSettings>
        <option key="#Board#" value="board.custom"/>
        <option key="CPU" value="S5D9"/>
        <option key="#TargetName#" value="R7FS5D97C3A01CFB"/>
        <option key="#TargetARCHITECTURE#" value="cortex-m4"/>
        <option key="#RTOS#" value="Express Logic ThreadX"/>
        <option key="#pinconfiguration#" value="R7FS7G27G2A01CBD.pincfg"/>
        <option key="#SSPVersion#" value="1.7.5"/>
        <option key="#DefaultLinkerScript#" value="s5d9.ld"/>
        <option key="#ConfigurationFragments#" value="Renesas##BSP##Board##S3_IOT_ENABLER##"/>
      </generalSettings>

    which appears contradictory to be if we have targets at one thing and pin config at another.

  • In reply to rjl:

    Confirmed: This is the problem. Appears to have used S7G2 pinouts for the S5D9 part in the conversion/translation that I did with it. I edited the xml file directly to point back to the S5D9, deleting references to the other part. Regen and rebuild and it appears to work now.
  • In reply to rjl:

    Hi rjl,

    If you moved SSP versions and destination e2studio installation fro SSP 1.7.5 did not have the compatible BSP for your board, the board setting will default to "custom user board" with S7G2 device set as default.

    Regards
  • In reply to Renesas Karol:

    That would explain it sort of. The problem there is that it didn't do it completely as most things were indicating that it was still using the S5D9.... If I hadn't diffed the XML file and go over it line by line, there's no way I would have found that.

    I don't use BSPs on custom boards.