multiple devices and threads on the same I2C bus

In one place in the SSP 1.2.0 Beta 1 documentation, it notes that I can’t have two instances of I2C open for the same bus (multiple devices on the same hardware bus, multiple threads).  The code for the touchscreen driver does an p_api->open prior to its while(1) loop so it assumes that it’s open all the time. 

so, which is incorrect?

If I need to open every time I want to access the bus then the touchscreen driver is wrong.  If I can open in each thread, but the read/write takes care of not stomping each other (which would be the preferable thing), then the documentation is probably worded incorrectly.


what is the correct sequence to access the bus from each thread?



  • It depends on if your are using the HAL driver or the Framework driver.
    The bus is supported by the framework driver. You can leave the framework open for each device and just do your read, write, and write-read calls at any time from each thread. The framework will handle the mutual exclusion to the bus. In addition, you can lock the bus so that all bus transfers will be only for the thread that dose the lock until the bus is unlocked.

    SSP 1.2 production release will add a new API call to the hal driver to allow you to change the slave address to access multiple devices without needing to use the framework drivers.

  • In reply to garyj:

    oh, that would be seriously useful.... Thanx for the info, this helps a great deal.
  • In reply to garyj:

    OK, I haven't got this set up correctly yet obviously....

    On the one thread (a GUIX thread) I've got this stack:

    On another thread (using the same bus but different peripheral:


    whichever thread runs second, the open fails with an IN_USE marker


    Second thread is doing:     RetVal = g_sf_i2c_device0.p_api->open (g_sf_i2c_device0.p_ctrl, g_sf_i2c_device0.p_cfg);

    touchsreen thread is doing:     ssp_err_g_sf_touch_panel_i2c0 = g_sf_touch_panel_i2c0.p_api->open (g_sf_touch_panel_i2c0.p_ctrl,

  • In reply to rjl:


    Unfortunately I2C HAL driver cannot be used on the same channel as I2C Framework. This is because Framework manages I2C slaves automatically and is only aware of other I2C Framework Device instances. Touch Panel I2C Framework uses HAL driver only so it will cause a conflict in the communication (because in this framework the touch panel is opened permanently, not just during the I2C transaction, like I2C Framework would do). You may be able to use another instance of I2C driver to set some peripheral up (by closing touch fwk, performing I2C comms and then re-opening the framework), but it won't be possible to alternate between it and touch panel i2c framework.

    Eventually, the I2C Framework will be implemented under the Touch Panel Framework, however this won't be done in 1.2.0 release.


  • In reply to Renesas Karol:

    Are there any update about this issue?
  • In reply to Angler84:

    Hello Angler84,

    in the current SSP version (1.3.3) there is no I2C framework under the Touch Panel Famework. I also looked through the SSP Release Notes, since version 1.2.0 up to the current one, and I didn't find any information regarding this issue, so I assume it is still present.

    Synergy Gallery >  Synergy Software Package > Release Archive

    As a workaround please follow the solution suggested by  in the earlier post (close the Touch Panel Famework, perform I2C communication, re-open the Touch Panel Famework). Alternatively you can also consider using in your application another I2C channel or the I2C SCI Driver.

    Best regards,

  • In reply to anper:

    Hello All,

    What do you guys mean by instance of I2C driver ?

    I tried adding a RIIC master driver on the same thread , that has the touch panel framework,however i got a error saying that i had multiple definition of the interruption vectors.

    I would like to know how do i add another instance of I2C driver.


  • In reply to Phillipe:

    Hi Phillipe,

    In the below picture there are two instances of I2C driver:

    Yes, interrupts must be enabled only once, but each instance generates code that tries to bind ISRs. This code might be however suppresed per instance. To do this please define SSP_SUPPRESS_ISR_g_i2c1 macro in Project > Properties > C/C++ Build > Settings > Cross ARM C Compiler > Preprocessor:


  • In reply to rjl:

    did you got it working I am also facing the same issue, please update if solved.
  • In reply to amar:

    Hi amar,

    Which issue are you facing? Which SSP version are you using?

  • In reply to adboc:

    same 2ed device when opening it says error in use and ssp 1.3.0
  • In reply to amar:

    Hi amar,

    Please take a look at an example application for DK-S3A7:
    It handles two I2C devices: a led bar and an ambient light sensor.