Issue initializing three i2c devices on voxl-px4

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 Katzfey

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

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 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 Katzfey

@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.

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 Katzfey

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