The TI E2E™ design support forums will undergo maintenance from July 11 to July 13. If you need design support during this time, open a new support request with our customer support center.

  • State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 49 subscribers
  • Views 1290 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

DAC8742H: DAC8742H

DAC8742H: HART modem FIFO does not clear characters.

Ken Nadler
Intellectual 640 points
Part Number: DAC8742H
Other Parts Discussed in Thread: TMS570LS0432, DAC8740H

I am trying to implement HART communications using the TI DAC8742H chip in SPI mode. Host processor is a Hercules TMS570LS0432.

First off I have observed that the DAC8742h.pdf document has an error. Address for MODEM_STATUS Register is documented as 0x20 and the FIFO_STATUS Register address is 0x24, however, I have observed that they are the opposite. Actual behavior is address for MODEM_STATUS Register is 0x24 and the FIFO_STATUS Register address is 0x20.

After system boot I send a single character through TeraTerm, for example a ‘1’ (hex 0x31). My device receives an IRQ. I read the MODEM_STATUS Register and FIFO_M2D Register; the DAC8742 reports that it received 0x31. So far, so good. From TeraTerm I send a ‘2’ (hex 0x32); I get an IRQ . I read the MODEM_STATUS Register and FIFO_M2D Register; the DAC8742 reports that it received 0x31. Not good. It should be 0x32. In fact no matter what character I type the modem reports that I got a 0x31. The DAC8740H.pdf states that the buffer will be cleared when I do a SPI read command. It does not.

I reboot, send a single character 'a' (hex 0x61). My device receives an IRQ. I read the MODEM_STATUS Register and FIFO_M2D Register; the DAC8742 reports that it received 0x61. Again, good. From TeraTerm I send a ‘b’ (hex 0x62); I get an IRQ . I read the MODEM_STATUS Register and FIFO_M2D Register; the DAC8742 reports that it received 0x61. Not good. It should be 0x62. In fact no matter what character I type the modem reports that I got a 0x61.

Any advice would be appreciated.

        ken

  • 0
    TI__Guru 53693 points
    Hi Ken,

    My colleague Garrett will need to get back to you on this after the holiday, you should have a response on monday.

    Thanks,
    Paul
  • 0
    TI__Expert 5820 points
    Hi Ken,

    How did you come to the conclusion that the FIFO_M2D and MODEM_STATUS registers have switched addresses? After reset FIFO_M2D is 0x0200 and MODEM_STATUS ix 0x0000. When I read these after reset they are correct.

    I have a few questions regarding your test:

    1. When you send a character with TeraTerm how is the HART signal being modulated for DAC8742H to demodulate? Can you provide the waveform being demodulated?
    2. What is the value of the MODEM_IRQ_MASK register? This will determine what triggers an IRQ.
    3. If you reset the device and send 0x62 before sending 0x61 does the device receive 0x62?

    Thanks,
    Garrett
  • 0 in reply to Garrett Satterfield
    Intellectual 640 points

    Garrett:

    Thank you for your reply. I'm getting different symptoms today than I was last week. I don't recall making a change but I must have. Today I get a parity error and the receive character is always 0x00:

    First, here's how I'm configuring:

    I send the RESET:

    TxBuffer = 0x07 0x00 0x01

    I send the CONTROL_REG:

    TxBuffer = 0x02 0x00 0x4c

    I send the MODEM_IRQ_MASK:

    TxBuffer = 0x21 0x7f 0x3f

    I send the MODEM_CONTROL:

    TxBuffer = 0x22 0x00 0x48

    I send the FIFO_LEVEL_SET:

    TxBuffer = 0x25 0x00 0x11

    Lastly I send the PAFF_JABBER:

    TxBuffer = 0x27 0x00 0x02

    Now the process is idle waiting for the IRQ line to go high...

    From TeraTerm, set to 1200 baud, 8 bit, odd parity, 1 stop bit, no flow control, I send an 'a'.

    IRQ line goes high and I get an interrupt. I wake up my character processing task...

    In the character processing task I request the status, using 0x24 for status reg address:

    TxBuffer = 0xa4 0x00 0x00

    I check the receive buffer:

    RxBuffer = 0xa0 0xc4 0x84

    I request FIFO_M2D using 0x20 for the M2D FIFO reg:

    TxBuffer = 0xa0 0x00 0x00

    I check the receive buffer:

    RxBuffer = 0xa4 0x02 0x00

    One thing I just noticed is that when I do a read request of either the status or FIFO register the first byte of the receive buffer is the opposite of what I am requesting, for example if I send TxBuffer[0] = 0xa4 RxBuffer[0] will be 0xa0, etc. It appears that the RxBuffer reflects the previous read request.

    I hope this sheds light on the issue.

    Thanks!

            ken

  • 0 in reply to Ken Nadler
    Intellectual 640 points
    OK, here's an update. Whatever command I clock in the reply to the previous command is clocked out. That's why it appeared that MODEM_STATUS_REG and FIFO_M2D addresses appeared to be backward. So, what do I need to do to get the proper reply for the MODEM_STATUS_REG and FIFO_M2D read requests?
  • 0 in reply to Ken Nadler
    TI__Mastermind 46290 points
    Ken,

    Page 25 of the datasheet illustrates the SPI frame structure. D23 indicates write frames versus read frames. A '1' in D23 initiates a read when followed by the appropriate address. The following frame from the read command will contain the requested data.
  • 0 in reply to Kevin Duke
    Intellectual 640 points

    Your answer is not very useful.

    After issuing a FIFO_M2D Register (Offset = 24h) command I need to clock in another frame? By this do you mean to clock in 6 bytes for the FIFO_M2D Register read? If I do that I clock in 0xa4 0x00 0x00 0x00 0x00 0x00 it clocks out 0x00 0x00 0x00 0xa4 0x00 0x00 0x00.

    Or do you mean I need to send a follow up command? What command? Any command?

    I tried issuing a second FIFO_M2D read:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x18 0x21. I typed an 'a' (0x62) into TeraTerm. Where's the 'a'?

    I typed a 'b' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x18 0x62. OK, this is better...

    I typed a 'c' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x18 0x63. OK.

    I typed a 'c' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x18 0x63. OK.

    I typed a 'd' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x18 0x64. OK.

    I typed a 'e' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x19 0x65. OK but parity bit?

    I typed a 'f' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x19 0x26. NOT OK.

    I typed a 'g' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x19 0xe6. NOT OK.

    I typed a 'h' into TeraTerm and I get:

    First read command: 0xa4 0x00 0x00 and I get back 0x00 0x00 0x00. Second time I request 0xa4 0x00 0x00 and I get back 0xa4 0x19 0x70. NOT OK.

    OK, now what?

  • 0 in reply to Ken Nadler
    TI__Expert 5820 points
    Hi Ken,

    The SPI read operation requires 48 SCLK cycles. The first 24 are the read command followed by the address and 'don't care' bits. In the next 24 SCLK cycles, the requested data will be clocked out of SDO with the lower 16-bits containing the register data. This could be why you receive zeros on your first read if you are reading SDO when the address is being clocked in SDI. SDO always clocks out the previously written SDI data or the register data if a read command was issued.

    The correct values are in the FIFO some of the time when you read back. I am wondering if there is an issue with the input HART signal.

    -Can you provide a scope capture of the input signal at MOD_IN/MOD_INF when you read the incorrect value? Are you using the internal filter?
    -Do the specific characters that show errors above always produce the same error when transmitted?

    Thanks,
    Garrett
  • 0 in reply to Garrett Satterfield
    Intellectual 640 points

    We are using the internal filter.

    OK, so the proper way to read the character from the FIFO is to transmit 6 bytes, the command byte, 0xa4, two don't care bytes and three more don't care bytes for a total of 6?

    Nope.

    If I send 0xa4 0x00 0x00 0x00 0x00 0x00 the bytes clocked back are 0xa0 0xc0 0x24 0xa4 0x00 0x00.

    Next character... I send 0xa4 0x00 0x00 0x00 0x00IR4 HART screenshots.docx 0x00 the bytes clocked back are 0xa0 0xc0 0x24 0xa4 0x00 0x00.

    Third character... 0xa4 0x00 0x00 0x00 0x00 0x00 the bytes clocked back are 0xa0 0xc0 0x84 0xa4 0x00 0x00.

    From that point the IRQ line never goes high again.

    If I clock in six bytes for the FIFO_M2D read command the chip stops raising the IRQ line. If I reset and restart sometimes I get three characters through before the chip stops raising the IRQ and sometimes it's only one character.

    if I send a three byte FIFO_M2D command (0xa4 0x00 0x00) followed by a second three byte FIFO_M2D command (0xa4 0x00 0x00) I will get the character about 50% of the time and the other 50% of the time it is garbage.

  • 0 in reply to Ken Nadler
    Intellectual 640 points

    IR4 HART screenshots, bad char.docxHere's a screenshot where I typed a '9' in TeraTerm and received 0xce.

  • 0 in reply to Ken Nadler
    Intellectual 640 points
    OK. It appears that the problem is resolved.
    1. I received a MACTek RS-232-to-HART modem this afternoon. It behaves much better than the Endress+Hauser. No more garbage characters.
    2. When I read the FIFO_M2D register I send three bytes: 0xa4 0x00 0x00, the SPI bus clocks in 0x00 0x00 0x00; I follow up by sending another SPI message with three bytes: 0x00 0x00 0x00 the SPI bus clocks in 0xa4 0x19 0x33 where the 0x33 is the character I sent from TeraTerm.

    I hope this info spares the next guy the pain I went through.
  • 0 in reply to Ken Nadler
    TI__Expert 5820 points
    Hi Ken,

    I am glad you resolved the issue. Let us know if you need more support.

    Thanks,
    Garrett