m8G reading DDC available bytes registers returns 0xFF while no data ready [closed]

0 votes

Hello all,
I'm trying to implement data polling via DDC interface. The easiest way for me to find out whether new data ready to read is reading 'available bytes' registers 0xFD and 0xFE. In Receiver description document stated  :

The currently available number of bytes in the message stream can be read at addresses 0xFD and 0xFE.  

By reading this registers I received 0xFF and 0xFF values, so available length is told to be 65kB that sounds suspicious.

Returning to document one can find:

 If there is no data awaiting transmission from the receiver, then this register will deliver the value 0xff, which cannot be the first byte of a valid message

Reading register with address 0xff I received first byte 0xff. So no data ready to readout.

So my question is why both registers 0xFD and 0xFE not equal 0 in case when no data ready. The second one is whether I can treat 0xffff value of available length as "no data"?



Reading 2 bytes from register 0xFD



closed with the note: Problem solved
by ValeiIe asked Mar 12
by ValeiIe closed Mar 22
0 votes
I think you are not reading the FD and FE registers correctly. They should indicate zero.  

The persistent FF data fill chars are only when you continue to read the FF register and the internal buffer is empty.

You can end up at address FF by not issuing a read with explicit register address if you start consecutive reads with register address lower than FF and you do not initialize to the correct register (FD or FE).

Note that separately you have to enable messages to I2C then you have to initiate the channel by setting FF read address then reading data even though there may not be any messages ready yet.  It may take up to a second to get data since messages are not created until the next nav computation cycle  (assuming the default periodicity of 1 Hz).  If you do not read every one second or so, then the channel is shut down and no more messages are created until you init the channel again with an explicit read from data register FF.

The concept is that if you start reading register FF and read FF data, you just keep reading data until you find a non-FF byte which can be $ as the first character of an NMEA messags or B5 62 as the first two characters of a UBX message. Note that UBX binary messages may contain valid data bytes of FF between header and checksum so you cannot just discard FFs within the body of a UBX message.

And make sure that your clock is within the maximum allowed of 400 kbps AND that your MCU interface obeys clock stretching.
by grampy answered Mar 13
by ValeiIe selected Mar 21
Best answer
Thank you.  But still not enough clear for me.
1) "The persistent FF data fill chars are only when you continue to read the FF register and the internal buffer is empty." - So if no data ready to read, reading from  0xff register will result in 0xff values? Yes, confirm.
2)  " You can end up at address FF by not issuing a read with explicit register address if you start with address FD or lower." - could you explain into more details?
3) If I disable all messages for DDC interface and than read 0xfd and 0xfe registers, will I receive 0x00 and 0x00?  

I prepared firmware that reads only this registers periodically. The logic analyzer shows:
I2C,Setup Write to ['132' (0x84)] + ACK
I2C,'253' (0xFD) + ACK
I2C,Setup Read to ['133' (0x85)] + ACK
I2C,'255' (0xFF) + NAK

I2C,Setup Write to ['132' (0x84)] + ACK
I2C,'254' (0xFE) + ACK
I2C,Setup Read to ['133' (0x85)] + ACK
I2C,'255' (0xFF) + NAK
Any errors here?
0 votes
See  also

Re your questions in the comment
1) yes. Correct.
2)if you set to read register 00, then just read bytes repeatedly, the receiver will provide contents of register 01, then 02, etc until FF.  All register contents from 00 to FC are undefined.
3) yes. See link above.

I don't know your code so I can't answer.  You may need a scope to capture exactly  what your host is sending and receiving on the DDC bus.
Compare bit-for-bit  exactly what you send with the examples in the Protocol Specification document.
by grampy answered Mar 13
by grampy edited Mar 13
Thank you, grampy! I tried to read 2 bytes starting from 0xFD and  received the same 0xff 0xff. I have updated the initial question with logic analyzer's cap .  I think the problem is not in ddc communication, but in wrong configuration of the module.
Can this module behavior  be caused by wrong setup? Is it possible to return to factory settings by running the command?
Ensure D_SEL is high, otherwise, the two pairs of pins for UART and DDC become 4-wire SPI slave. Removing all supply voltages should restore the system to factory defaults unless you have connected external flash, in which case ypu must connect through UART and use command CFG-CFG to return to defaults.
Verify also that your MCU interface is operating at 1.8V to match ZOE-M8G levels.
Thank you, grampy.
I fixed the problem. The cause was in high level I2C API. Write and read sequences was divided  by stop condition. I updated the code according to scheme in  "5.4 RandomReadAccess" of "Display Data Channel (DDC) Serial Communication Bus" and now I get 0x0000 when reading 2 bytes from 0xFD address.