Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
Collapse
Brand Logo

ModalAI Forum

  1. ModalAI Support Forum
  2. VOXL Compute & Autopilot
  3. VOXL 2
  4. Issue initializing three i2c devices on voxl-px4

Issue initializing three i2c devices on voxl-px4

Scheduled Pinned Locked Moved VOXL 2
7 Posts 2 Posters 786 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    Riccardo
    wrote on last edited by
    #1

    Hi,
    I'm working on a voxl2 with sdk 1.4.1 and I need to handle three i2c devices in voxl-px4. The devices are the following:

    • ina231 on bus 2 with device id 0x44
    • vl53l1x on bus 4 with device id 0x29
    • a second distance sensor on bus 4 with device id 0x77

    Each of the device is handled by a px4 module, initialized in voxl-px4-start. Until I start only two i2c devices everything works fine however the third one always fails at this line "_i2c_fd = _config_i2c_bus(get_device_bus(), get_device_address(), _frequency);" of i2c.cpp.
    Note that the order of initialization matters, for example if I initialize the devices in the order 0x44, 0x29, 0x77 the device 0x77 will fail. If the order is 0x29, 0x77, 0x44 would be the 0x44 device to fail.

    This is how the three modules are initialized in the voxl-px4-start script
    qshell vl53l1x start -X -b 4 -R 0 #range finder facing forward
    qshell finder_i2c start -X -b 4 -M 0 #custom module that handles the rangefinder facing downwards
    if [ "$POWER_MANAGER" == "VOXLPM" ]; then
    # APM power monitor
    qshell voxlpm start -X -b 2
    fi

    In this case the voxlpm fails to initialize with the following error log
    INFO [qshell] Send cmd: 'voxlpm start -X -b 2'
    INFO [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
    INFO [muorb] SLPI: qshell gotten: voxlpm start -X -b 2
    INFO [muorb] SLPI: arg0 = 'voxlpm'
    INFO [muorb] SLPI: arg1 = 'start'
    INFO [muorb] SLPI: arg2 = '-X'
    INFO [muorb] SLPI: arg3 = '-b'
    INFO [muorb] SLPI: arg4 = '2'
    INFO [muorb] SLPI: *** I2C Device ID 0xd24411 13779985
    INFO [muorb] SLPI: Initializing VOXLPM on channel 0
    INFO [muorb] SLPI: Set up I2C bus mutex for bus 2
    ERROR [muorb] SLPI: i2c init failed
    INFO [muorb] SLPI: PX4_qshell: no instance started (no device on bus?)
    ERROR [muorb] SLPI: Failed to execute command: voxlpm start -X -b 2
    INFO [qshell] cmd returned with: -1
    INFO [qshell] qshell return value timestamp: 356875512, local time: 356879115
    ERROR [qshell] Command failed

    Eric KatzfeyE 1 Reply Last reply
    0
    • R Riccardo

      Hi,
      I'm working on a voxl2 with sdk 1.4.1 and I need to handle three i2c devices in voxl-px4. The devices are the following:

      • ina231 on bus 2 with device id 0x44
      • vl53l1x on bus 4 with device id 0x29
      • a second distance sensor on bus 4 with device id 0x77

      Each of the device is handled by a px4 module, initialized in voxl-px4-start. Until I start only two i2c devices everything works fine however the third one always fails at this line "_i2c_fd = _config_i2c_bus(get_device_bus(), get_device_address(), _frequency);" of i2c.cpp.
      Note that the order of initialization matters, for example if I initialize the devices in the order 0x44, 0x29, 0x77 the device 0x77 will fail. If the order is 0x29, 0x77, 0x44 would be the 0x44 device to fail.

      This is how the three modules are initialized in the voxl-px4-start script
      qshell vl53l1x start -X -b 4 -R 0 #range finder facing forward
      qshell finder_i2c start -X -b 4 -M 0 #custom module that handles the rangefinder facing downwards
      if [ "$POWER_MANAGER" == "VOXLPM" ]; then
      # APM power monitor
      qshell voxlpm start -X -b 2
      fi

      In this case the voxlpm fails to initialize with the following error log
      INFO [qshell] Send cmd: 'voxlpm start -X -b 2'
      INFO [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
      INFO [muorb] SLPI: qshell gotten: voxlpm start -X -b 2
      INFO [muorb] SLPI: arg0 = 'voxlpm'
      INFO [muorb] SLPI: arg1 = 'start'
      INFO [muorb] SLPI: arg2 = '-X'
      INFO [muorb] SLPI: arg3 = '-b'
      INFO [muorb] SLPI: arg4 = '2'
      INFO [muorb] SLPI: *** I2C Device ID 0xd24411 13779985
      INFO [muorb] SLPI: Initializing VOXLPM on channel 0
      INFO [muorb] SLPI: Set up I2C bus mutex for bus 2
      ERROR [muorb] SLPI: i2c init failed
      INFO [muorb] SLPI: PX4_qshell: no instance started (no device on bus?)
      ERROR [muorb] SLPI: Failed to execute command: voxlpm start -X -b 2
      INFO [qshell] cmd returned with: -1
      INFO [qshell] qshell return value timestamp: 356875512, local time: 356879115
      ERROR [qshell] Command failed

      Eric KatzfeyE Offline
      Eric KatzfeyE Offline
      Eric Katzfey
      ModalAI Team
      wrote on last edited by
      #2

      @Riccardo Make sure that the 2 devices sharing bus 4 have the same i2c frequency.

      1 Reply Last reply
      0
      • R Offline
        R Offline
        Riccardo
        wrote on last edited by Riccardo
        #3

        Hi thank you for the reply. They already do have the same frequency.
        I'm trying to understand what's happening inside the _config_i2c_bus function i2c.cpp, however it's a callback set during the initialization of px4 I'm guessing by this function in I2C.hpp

        static void configure_callbacks(_config_i2c_bus_func_t config_func,
        					_set_i2c_address_func_t addr_func,
        					_i2c_transfer_func_t transfer_func)
        	{
        		_config_i2c_bus = config_func;
        		_set_i2c_address = addr_func;
        		_i2c_transfer = transfer_func;
        	}
        

        which is called by px4muorb_orb_initialize in uORBProtobufChannel.cpp. However px4 doesn't directly called it and the definition of the function:

        int px4muorb_orb_initialize(fc_func_ptrs *func_ptrs, int32_t clock_offset_us) __EXPORT;
        

        makes me think that it's called by an external service but can't find which one. Can you help me understand what happens during the px4 initialization and what's calling px4muorb_orb_initialize?

        Eric KatzfeyE 1 Reply Last reply
        0
        • R Riccardo

          Hi thank you for the reply. They already do have the same frequency.
          I'm trying to understand what's happening inside the _config_i2c_bus function i2c.cpp, however it's a callback set during the initialization of px4 I'm guessing by this function in I2C.hpp

          static void configure_callbacks(_config_i2c_bus_func_t config_func,
          					_set_i2c_address_func_t addr_func,
          					_i2c_transfer_func_t transfer_func)
          	{
          		_config_i2c_bus = config_func;
          		_set_i2c_address = addr_func;
          		_i2c_transfer = transfer_func;
          	}
          

          which is called by px4muorb_orb_initialize in uORBProtobufChannel.cpp. However px4 doesn't directly called it and the definition of the function:

          int px4muorb_orb_initialize(fc_func_ptrs *func_ptrs, int32_t clock_offset_us) __EXPORT;
          

          makes me think that it's called by an external service but can't find which one. Can you help me understand what happens during the px4 initialization and what's calling px4muorb_orb_initialize?

          Eric KatzfeyE Offline
          Eric KatzfeyE Offline
          Eric Katzfey
          ModalAI Team
          wrote on last edited by
          #4

          @Riccardo This is all the interface to the underlying Qualcomm proprietary code. That code will call px4muorb_orb_initialize on startup and provide the function pointers. The i2c config function will use the proprietary Qualcomm i2c interfaces to setup the port.

          Eric KatzfeyE 1 Reply Last reply
          0
          • Eric KatzfeyE Eric Katzfey

            @Riccardo This is all the interface to the underlying Qualcomm proprietary code. That code will call px4muorb_orb_initialize on startup and provide the function pointers. The i2c config function will use the proprietary Qualcomm i2c interfaces to setup the port.

            Eric KatzfeyE Offline
            Eric KatzfeyE Offline
            Eric Katzfey
            ModalAI Team
            wrote on last edited by
            #5

            @Eric-Katzfey There are a number of reasons that _config_i2c_bus can fail. One is that there is a hardcoded limit of 8 devices. There are other i2c devices being initialized. There is the barometer, and potentially a magnetometer, and status LED. But that still should be under the 8 limit. Can you provide the entire log of the startup messages? There is another tool that would provide more information called "mini-dm" but that tool is only available in the Qualcomm Hexagon SDK. You would need to setup a developer account at Qualcomm and download that SDK (unfortunately a difficult procedure) to get access to that tool. That would capture the actual failure message produced by the _config_i2c_bus function call.

            1 Reply Last reply
            0
            • R Offline
              R Offline
              Riccardo
              wrote on last edited by
              #6

              That was the reason. In the voxl-px4-start script 9 i2c deviced were initialized. Removing few of them that we are not using was enough to make it work. The interesting part is that even if the device is not connected and the initialization of the module fails, it still counts for the limit of 8 devices.

              Thank you.

              Eric KatzfeyE 1 Reply Last reply
              0
              • R Riccardo

                That was the reason. In the voxl-px4-start script 9 i2c deviced were initialized. Removing few of them that we are not using was enough to make it work. The interesting part is that even if the device is not connected and the initialization of the module fails, it still counts for the limit of 8 devices.

                Thank you.

                Eric KatzfeyE Offline
                Eric KatzfeyE Offline
                Eric Katzfey
                ModalAI Team
                wrote on last edited by
                #7

                @Riccardo Okay, thanks for the confirmation. I'll look into increasing that limit to 16 or so.

                1 Reply Last reply
                0

                Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                With your input, this post could be even better 💗

                Register Login
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                ModalAI
                Categories Recent Tags ModalAI.com Docs
                © 2026 ModalAI® · Accelerating autonomy for smaller, smarter, safer drones · Powered by NodeBB
                • Login

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Users
                • Groups