Mity CPU Platforms » ARM9 Based QNX Platforms

Rob,

The two utilities are convenient for easy command-line or script-based access to the I2C for simple control functions. The utilities are very simple-minded and don't try to deal with interrupts or offer flexibility with respect to clock speeds. When their operating conditions are met though, they are easy to use. It probably would have been better to make the commands use the driver instead of going direct to the hardware.

For general-purpose use, it is probably better to use the QNX driver. For testing and experimenting, the utilities can be handy.

It looks like neither I2C driver is started by default.
We are trying to use I2C0
There is an error generated if we include the line:

   omapl138_psc_enable (PSC_MODULE_I2C0);

Mark,

I2C0 is not something that needs to be turned on. It is used internally in the startup code to read configuration information on the L138 module, so if you are booting into QNX, then i2c0 has been used.

QNX provided i2c drivers but I am not sure how to use them. We have supplied two commands (i2c_get and i2c_set) to help with manually accessing device registers via i2c. If you just need occasional access or just to make changes at initialization, the commands may be sufficient. If you need to transfer lots of data, then you probably want something else.

The source to the utilities is available at src/utils/i/i2c_get and src/utils/i/i2c_set.

Hope this helps.

John

IFor what it is worth, it should be noted that the i2c accesses in the startup code and in the i2c_get utility are done without interrupts. The i2c resource manager is probably using interrupts. It is possible that something needs to be set to enable the i2c interrupts. Although, this probably would not explain the absence of activity that you are observing on the lines.

An engineer from QNX hooked a scope to I2C0 lines on their EVM board and sent the sendrecv command. They were able to get a signal on the lines, proving that their driver works with the utilities. They said this indicated that the BSP was causing the issue.

Can you try to get the sample program that the qnx engineer used?

Thanks.

I am attaching a test program that was used on a board to read the factory config information using i2c0.

The output of the i2c_get program is:

# i2c_get -i 0 0x50 8 6  
i2c0: 0x50: 0x8:        00  50  c2  bf  89  2a
# 

This reads 6 bytes from offset 8 from the device at address 0x50. These 6 bytes are the mac address for the device.

# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
        inet 127.0.0.1 netmask 0xff000000
emac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:50:c2:bf:89:2a
        media: Ethernet none (100baseTX full-duplex)
        status: active
        inet 10.0.25.167 netmask 0xffff0000 broadcast 10.0.255.255
# 

The output from the test program is:

I2C driver demonstration program
ret = 0, address: 0x50, offset: 0x8
Data:    00 50 c2 bf 89 2a 

Sometimes, when switching between the i2c_get and the test program, the test program would get an I/O error. I don't know for sure but I suspect the i2c_get program did not properly clean things up. Running the test program again would then start working.

I think this program demonstrates that the i2c-dm6446 driver is working ok on the indio board, at least for one device.

Now the question becomes, what is different between the device you are trying to talk to and the on-module memory device that I was using.

You should be able to run this program on your board.

Interesting. We were using Qnx's demo which uses DCMD_I2C_RECV rather than DCMD_I2C_SENDRECV so that was part of the solution.
It is also calling open with O_RDWR rather than O_RDONLY - not sure if that is a problem.
Also the call to DCMD_I2C_SET_BUS_SPEED seems to mess the works up, and we’ll need to look further at that, but I’m ok with default speeds for now.
Finally, the Qnx demo was setting dev_data.header.stop to 0 rather than 1. I'll look at these differences individually when I get a chance.

Thanks,

mark

Mark,

I probably should have used O_RDWR instead of O_RDONLY. I am surprised it worked with just O_RDONLY.

The SENDRECV is important, at least for my device. I am reading a device register and the protocol is that I need to send the offset to the device and then read the number of bytes I am interested in.

I did not try it without the stop.

I made up my own program so I guess I was not influenced by the qnx sample.

Can you run this program on your board and see activity?

I have also learned that the memory device I was accessing actually responds to a set of addresses (0x50,0x51...). It is important to make sure that your device has a unique address.

John

Yes, it works (thanks):

   # ./i2c-test_g
   I2C driver demonstration program
   ret = 0, address: 0x50, offset: 0x8
   Data:   00 50 c2 bf 8e 09
   #

I did not notice that i2c_get sends the offset - my bad.
I know that there are a bunch of addresses, and was actually testing with 0x38, so we were trying the same thing in that regard.