DAC8742H: Issues reading from the Rx FIFOs over SPI when using the DAC8742H in HART mode

Hi Jonathan,

Can they capture an SPI frame with an oscilloscope to confirm the timing and edge relationship is correct?

start of SPI frame is captured and attached.  D0 is ChipSelect;  D1 is SCLK (bit banged, so not perfect);  D2 is SDI (MOSI);  D3 is SDO (MISO).  SCLK frequency is ~500kHz.

I transition MOSI data following rising edge of SCLK and sample MISO data on falling edge of SCLK.

Bill,

I'm sorry I didn't get a chance to look at this earlier, but I didn't see anything wrong with the basic SPI. For this device, the data is setup on the rising edges of SCLK and clocked in and out of the device on the falling edges. Other than that, your SPI is running at 500kHz, which is a bit slow to really have problems with any other timing.

I'll review this again tomorrow and see if I can come up with something to check.

Joseph Wu

Any update?  I've not been able to resolve myself.   

I have confirmed that when I send HART commands, the SPI echo of the register writes matches, confirming my SPI receive path is operating properly. Also, the field HART device is responding to my command as expected, giving further confidence that my SPI write procedures are working properly.

I have interfaced to the EVM board for this device and a custom integration. Same results are observed on both.  Also, I have been able to get UART mode working properly on both the EVM and custom integration platforms.  Unfortunately, I need SPI operation and it just doesn't work.

Can you confirm that my simple test procedure above is valid?  That is, sending a MODEM_STATUS read request followed by multiple FIFO_M2D read requests?  Also, is it expected that the FIFO_LEVEL be reported as 0 when the FULL_FLAG is set?

While I'm asking questions, is the FIFO_LEVEL reported in response to a FIFO_M2D read request indicate the level before or after accounting for the data value being reported (i.e., when reading from a full fifo, is the reported fifo level 15 or 16/0)?

Bill,

Sorry, there's been a lot going on, so I'm a bit behind on all the support lately. I did discuss this one with design but I haven't had a chance to really look over their response. I'll get back to you tomorrow.

Joseph Wu

Bill,

I ran a quick test with the EVM, setting up the device in SPI mode. For the HART write, I set up an array with 16 bytes to send to the device:

0F 1F 2F 3F 4F 5F 6F 7F 8F 9F AF BF CF DF EF FF

I then generate this write. Then I start another write of a single byte of 01 so that I'm sure to fill the buffer.

When I start the the read, I receive 040F, indicating the full buffer. The next subsequent reads go through the elements of the buffer.

A4F01F A4E02F A4D03F A4C04F A4B05F A4A06F A4907F A4808F A4709F A460AF A450BF A440CF A430DF A420EF A1010

At the end I get A4020F as the buffer becomes empty. Subsequent reads return the last element of the buffer, so this read doesn't change. The last two reads look like they've been swapped, so I'll need to look into that and see if this is an artifact in the GUI or if there's something else going on.

Regardless, the full buffer is indicated by the FULL_FLAG, and that the FIFO level is at 0. I would note that I do have some significant time from this full reading to the next set of 16 reads as I read through the buffer. When I checked with design, he had run a quick simulation that indicated that the FULL_FLAG also showed the FIFO level at 0 and then subsequent reads decrementing the FIFO level output. He had run through a set of four reads of FIFO_M2D.

Joseph Wu

Clearly I have a fundamental problem as I can't even replicate your experiment.  I presume that you are using the modem in FIFO loop-back mode.

Is it possible to send me the complete set of SPI transmission frames and corresponding read frames, including all configuration messages?  Please send the full frame info (i.e., 3-bytes), not just the data byte.  I will implement that exact sequence as a test.

Thanks.

Hi Joseph,

With the help of your listing, I finally resolved the problem, although it took a while to replicate your results. One key element to the loopback test is that the loop back occurs only after RTS is enabled, and appears to get clocked at HART rates (i.e., one byte per ~9.2msec). In hindsight, that's reasonable, but certainly not documented in the datasheet.

The key to resolving my issue is the observation that you are using the NOP function (0x00 00 00) to clock out the result of each and every FIFO read request (0xA4 FF FF). While this is OK, it is clearly not documented as required in the datasheet ... In fact, quite the opposite. The 2nd paragraph of Section 7.4.5.2 includes the statement "SDO will always provide information from the previous frame, if the previous frame was a read then the output data will be the requested data." This statement is clearly wrong, the NOP command must be used to get the results of the read command.

I'm absolutely stunned that no one has run into this problem before. Please have an errata released for the datasheet.

-Bill