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.

DAC8742H: The case of the Missing Interrupt signal...

Part Number: DAC8742H

I'm using the dev board connected to an 8 bit processor via SPI.  I'm able to inject a ten byte HART string of the following bytes:   0xFF 0xFF 0xFF 0xFF 0xFF 0x02 0x80 0x00 0x00 0x82.  The Rx FIFO buffer Level is set to 1, and I made sure the interrupt is enabled for FIFO_M2D_LEVEL in the IQR MASK register.  I have a logic analyzer probe on all the SPI lines including the IQR output & Chip Select plus a channel shows me the incoming HART signal.  I've set up the appropriate registers to trigger an alarm/interrupt to fire for Carrier Detect and for every new byte that arrives via HART.  (FIFO receive level = 1) 

As predicted, the DAC8742 generates an IQR signal with every new Carrier Detection burst.  So, no problem there.  I expect to see subsequent interrupt pulses with every FIFO LEVEL alarm trigger which is after every new byte that arrives via HART, and most of the time that's exactly what happens.  However, on (too) many occasions I don't get an interrupt on the first byte following the Carrier Detection.  Conversely, I always get each interrupt pulse for the remaining nine bytes that arrive.  It's as if it's not detecting the first byte of the ten bytes that arrive at the HART input.  

Also, the same thing happens if I disable the CD interrupt.  It'll still fail to generate an IQR pulse upon the first byte, but will always generate the pulse on the remaining nine bytes.  

Sometimes, for no apparent reason, I get all ten IQR pulses - one for each byte as expected.  

What happened to the missing interrupt pulse?

Hints?  Clues? 

Btw, the datasheet...it could be better.  

  • Hi,

    How often is it missing the first byte vs. capturing the entire transaction?

    Are you using the DAC8742HEVM or a different board to interact with the DAC? Is the HART signal generated from the DAC8742H or is it generated from any external source?

    Can you plot CD and the HART signal (and UART if available) on an oscilloscope and share the capture? Include cases that are both passing and failing please. 

    Is your logic analyzer a Saleae? If it is, share your logic file as well.

    Thanks,
    Lucas

  • How often is it missing the first byte vs. capturing the entire transaction?

    More times than successful.

    Are you using the DAC8742HEVM or a different board to interact with the DAC?

    We're using our own board as an initial dev platform that's connected to the header pins of 'EVM' board.  I have another board that handles the analog portion of the 4-20 mA loop where a HART modem is attached.  External 5V power supply power 'EVM' board, my processor board, & part of loop circuit.  Separate, isolated 24V power supply for the loop.  

     Is the HART signal generated from the DAC8742H or is it generated from any external source?

    External source provided by a HART modem connected to a PC. On 'EVM' board BPF_EN & REF_EN both set to 5V.  Internal oscillator.  I tried using the 2200 pF & 2700 pF caps - no difference. 

    Can you plot CD and the HART signal (and UART if available) on an oscilloscope and share the capture?

    O'scope?  Not really.  (Using SPI.)

    Is your logic analyzer a Saleae?

    Yes!  I tried uploading the Saleae file here.  It didn't work.  Images will have to work for now unless there's another way to attach the analyzer file.

    First image shows a CD interrupt followed by an interrupt after rx of first byte.  

       

    2nd image shows the CD interrupt, no byte rx, followed by the second byte arrival.  

  • Hi,

    Just to confirm, you are using your own board to send the HART signal to the DAC8742HEVM?

    What is your jumper configuration for J9, J10, J11, J12, and J16? Feel free to send a picture of your board too.

    In your second screenshot, does the second interrupt contain the second data byte?

    What is the status of your IF_SEL pin?

    I will reach out to one of the designers as well.

    Thanks,
    Lucas

  • Just to confirm, you are using your own board to send the HART signal to the DAC8742HEVM?

    No. PC app -> HART Modem connected across 250 Ohm resistor within the loop.  

    What is your jumper configuration for J9, J10, J11, J12, and J16?

    JP9:  2&3

    JP10:  2&3

    JP11: 1&2

    JP12: NC

    JP16: 5&6

    In your second screenshot, does the second interrupt contain the second data byte?

    Sure.  There's five preamble bytes all of them are 0xFF.  1st or 2nd one sent?  Dunno.  Here's the thing...  I tried polling the status register upon receiving the CD interrupt.  That is, upon detecting the CD I continuously poll the status register just to see what's there - if there's any indication of a byte being present - nothing.  I did the same thing with the FIFO register.  Continuous polling upon detection of CD to see if the byte is somehow there but the interrupt just didn't get generated.  Nothing.  It's as if the DAC8742 never saw the first byte even though it detects the carrier signal.  

    What is the status of your IF_SEL pin?

    IF_SEL is set for SPI.  I'm assuming this works because I'm using SPI to write to the various registers, make changes, and read back from them to verify.  So, my low level Read & Write SPI commands seem to be working just fine.  

  • Hi,

    Your jumper configuration looks good for the internal filtering. IF_SEL is correct as well.

    Can you try increasing the size of your HART signal?

    Is your IRQ_LEVEL in your CONTROL register set to 0? If it is, try setting it to 1 and see if there is any change.

    Instead of sending the 5 preamble bytes, can you send unique ones, to double check that the first byte is always skipped? (ie 0xFF, 0xFE, 0xFD...). Are you reading the buffer at the first indication of CD? At that point, there should be no useable data in the buffer. 

    Also, can you try changing the FIFO receive level to 10 instead of 1? We can see if longer communication works properly and if it is an issue with the level being 1.

    The designer is out of office until Friday as well, so I may have to wait until then to get his input.

    Thanks,
    Lucas

  • Can you try increasing the size of your HART signal?

    Increased the loop resistor value which increased the HART signal voltage reaching the DAC8742EVM.  No change. 

    Is your IRQ_LEVEL...

    I tried both settings many days ago.  Don't remember exact result other than one setting worked (created a pulse) and the other didn't work.  I preferred the pulse so I stuck with that setting and moved on. 

    Instead of sending the 5 preamble bytes, can you send unique ones...

    No.  I'm using a HART Master type PC program with fixed 0xFF bytes.  I could roll my own program, but time is a consideration.

    Are you reading the buffer at the first indication of CD? At that point, there should be no useable data in the buffer. 

    Right.  Yes, tried reading both the status and the fifo registers just after the CD.  No byte(s) in buffer indication.  That's what I meant when I wrote this from above post:

    "I tried polling the status register upon receiving the CD interrupt.  That is, upon detecting the CD I continuously poll the status register just to see what's there - if there's any indication of a byte being present - nothing.  I did the same thing with the FIFO register.  Continuous polling upon detection of CD to see if the byte is somehow there but the interrupt just didn't get generated.  Nothing.  It's as if the DAC8742 never saw the first byte even though it detects the carrier signal."  

    Also, can you try changing the FIFO receive level to 10 instead of 1?

    I'll get to that when I have more time.  However, it's not how I want to ultimately manage comm with this part.  

  • Hi,

    I'd be interested in seeing if changing the FIFO receive level to 10 causes anything to behave differently.

    Our digital designer will be back on Friday, so more information will come then.

    We are also in the process of acquiring an EVM to perform our own tests.

    Thanks,
    Lucas

  • Hi,

    The designer responded. His message is below:

    "Based on the waveforms I am seeing it appears to me that there is not enough time for the carrier before the first START bit is sent.  This would cause the first character to be ignored.  I believe the data sheet states that 2.5 bit times of carrier at 1200Hz needs to be transmitted before the CD is asserted.  If this is not the case then the first character can be lost.  If the amount of time cannot be controlled before the first START bit then a sacrificial preamble character should be sent.

    It appears the device is working correctly."

    Let me know if this resolves your issue.

    Thanks,
    Lucas

  • So, if I understand correctly, there needs to be 2.5 bit times worth of 1200 Hz carrier signal on the input before the part will consider looking for a start bit(?) and subsequently read the first byte into the FIFO.  Here's another trace to look at where I'm not using the CD interrupt.  That is, the Rx FIFO Level is set to one where I expect to receive an interrupt.  You mean that there needs to be 2.5 bits worth (timing-wise) of 1200 Hz carrier at the beginning of that HART signal prior to the HART 'start bit' signal?  

  • Hi,

    I believe that is the case, but I will clarify with the designer to make sure.

    Thanks,
    Lucas

  • Hi,

    The spec mentioned is Tdeton, which has a max of 6 Bit-Times in the datasheet, but should typically be done in at least 2.5 Bit-Times. This is the time from carrier on receive path to CD rising edge.

    Thanks,
    Lucas