I am having a problem with the I2C driver for a Freescale p1022tw board. There is a command on U-Boot's console to read from an I2C device:
i2c md chip address[.0, .1, .2] [# of objects]
When I read 4 bytes from a device with id 0x60, at address 0x0, I get:
tw=>i2c md 60 0 4
0000: 45 45 45 45 EEEE
These values that it returned are wrong. I can get the right values if I read one byte at the time:
tw=>i2c md 60 0 1
0000: 45 E
tw=>i2c md 60 1 1
0001: 45 E
tw=>i2c md 60 2 1
0002: 46 F
tw=>i2c md 60 3 1
0003: 00 .
I should have gotten 45 45 46 00 or EEF0 in the first command. In multiple readings for this device, it is returning always just the first byte value. If I try to get 6 bytes starting at address 0x2, this is the output:
tw=>i2c md 60 2 6
0002: 46 46 46 46 46 46 FFFFFF
This problem does not happen on other devices on the bus. For instance, in the device with id 0x4F, the right values are printed:
tw=>i2c md 4F 0.2 6
0000: 18 00 f6 48 00 00 ...H..
The address in the previous command has a ".2" because the chip uses 2 bytes for addresses. The first device only uses 1, so there's no need to put a ".1" (I already tested that).
I went through the implementation of the Freescale driver for the I2C communication, but I didn't change anything on it and it works for other devices. My coworker also says that the very same code works on his board. Have anybody had a similar issue or has any theory about why this is happening?
Thanks in advance.
I met such a situation. I had driver, read and write functions, and it worked not for all i2c devices. I found that was caused the not working device had different operating format for a number of operation. Unfortunately this happens, there a kind of not standard protocols. When you open the doc for the problem device and compare it to working and/or to the driver implementation you most likely will see a difference.
Related
I am a hardware guy with little embedded systems experience, so my question may be trivial.
I need to put an Ethernet switch in "test mode 1" which is an Ethernet compliance test mode you can put the chip in for characterizing signals on a scope. at the bottom is the datasheet page that shows this register and how to put it in test mode 1.
I am using u-boot i2c commands to do this.
chip Slave address = 0x5F
Port 1 address (to be written to) = 0x1112.2 (16 bit address needs the .2, correct me if i am wrong)
I send the following command to the switch:
#i2c mw 0x05F 0x1112.2 0x01 10
Then I read it back:
#i2c md 0x05F 0x1112.2 10
1112: 01 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 ............0...
The command that I am writing is only writing to the first bit. I cant for the life of me figure out how to write to any other bit at that address other than the first one. What would my u-boot i2c command look like if I wanted to set bits [15:13] to [0 0 1]?
I'm trying to locate h264 frames in the mp4 container of a segmented file(styp). For the segmentation I'm currently using MP4Box dash. I used MP4Box parser and I noticed that in each keyframe(IDR) the size of the sample is different than the size of the same frame in the original file. I calculated the difference and it's always 37 bytes for the same file in other segments.
What do these bytes represent? They only appear in the segmented mp4 file types before each keyframe. I tested with other files and the number of these bytes vary slightly(other file was 39 bytes) and are not the same data(they share some byte patterns though). Is this something from the mp4 standard or H264 or even MP4Box? I don't have a clue.
00 00 00 19 67 ... - H.264 SPS NAL 0x19 (25) + 4 = 29 bytes size
00 00 00 04 68 ... - H.264 PPS NAL 0x04 (4) + 4 = 8 bytes size
In sum this gives 29 + 8 = 37 bytes of SPS/PPS. Usually for mp4 (avc1 samples) SPS/PPS are not present inband (mdat box) and stored out-of-band in avcC box. But that is not strict rule afaik and SPS/PPS can be both inband and out-of-band or out-of-band only as for avc3 samples.
For my assembler, I want to encode the operation mov eax, [addr]. In 64 bits this would only possible using a SIB byte, as the mod r/m combination 00 101 was changed to indicate rip-relative addressing. The problem I find is that, in 32 bits, encoding this instruction using a SIB byte doesn't work. For example I have:
8B 84 25 1C FE 43 00
(mov) (10 000 100) (00 100 101) (address)
but disassemblers don't seem to accept it, I get:
mov eax,DWORD PTR [ebp+eiz*1+0x43fe1c] (defuse.ca)
mov eax, ss:off_43FE1C[ebp] (ida)
and when the instruction is executed it generates an exception. I know that there is the shorter encoding in 32 bits, but don't understand what's wrong with the longer one.
I have those 3 Events in a Midi file:
00 FF 51 03 0E 15 C3 86 A6
20 FF 51 03 15 20 A5 83
5C FF 51 03 0E 15 C3
But what is, in this case, important is, that FF 51 stands for a Tempo Change and the 03 for the number of following Byte-Pairs describing the tempo. As it is "3 Byte Pairs" in Each Event Why are there 5 Byte Pairs describing the first Event, 4 describing the second, and 3 describing the third? (I hope the image helps)
How does the encoding program know, when a new Event starts? The File can be played without any Problems.
All three events have three data bytes.
The delta times between the events are encoded as variable-length quantities, so you have to continue to read bytes until the most significant bit is clear. The three times before each event are 00, 86 A6 20, and 83 5C, resulting in the decoded delta times of 0, 109344, and 476.
I have a CyberGlove connected to Matlab via serial port. I am trying to write a command requesting a data sample, and then reading the sample back.
I have successfully connected the glove with the following code:
s = serial('/dev/ttyS0')
set(s,'BaudRate',115200)
fopen(s)
I can then write/read to get the sensor information either in binary or ascii.
In binary I am doing:
fwrite(s,'G')
fread(s)
fread always times out and then spits out a column vector of seemingly random length (1-100+) containing meaningless integers.
With ASCII, the commands are:
fprintf(s,'g')
fscanf(s)
This gives an empty string as the read-out value. I know that the glove is getting and at least somewhat processing the commands, though, because if I give it an invalid command, I get back the error message e?.
Here's the part that really confuses me, though: I accidentally discovered a way to get a correct reading from the glove.
fread(s) (which times out and gives the seemingly random output)
fprintf(s,'g')
fscanf(s)
I then get the string output 'g 1 76 93 113 89 42 20 77 98 106 117 81 62 23 52 60 34 68 57 254 92 26', which is correct.
My questions are:
(1) Why does that last part produce a correct response?
(2) How can I get a reading from the binary command? This is what I actually want to acquire.
Figured out the problem:
The timeout was occurring because it wasn't getting back as many bytes as it expected, and it was expecting the incorrect number. By default, get(s, 'InputBufferSize') returned 512, while the actual data was 24 bytes. Before calling fopen(s), I just ran set(s, 'InputBufferSize', 24); and got the correct 24 8-bit integers from the binary read/write that I was expecting, without a timeout.