AFE881H1: Hart Modem

John,

I had to discuss this with one of the digital designers, and he says that a long delay between the break and the write might create a gap error. His test bench was run with just 1-2 bit times between the break command and the data characters.

I'll see if I can get more clarity on this, and get specific timing information.

Joseph Wu

John,

One other thing that I did want to make sure of is that the UART write is set up correctly. Noting Figure 7-31, the bits are sent with LSb first.

I would also recommend starting with a read of a register first, just to make sure you have the UART communication working. Again, I'll check for more information on the timing.

Joseph Wu

I have verified exactly that waveform on my scope, so I am confident about the LSB.

The only difference is the gap of time between the UART Break and the UART Break Write.

Would you be able to verify that my data sent to the 2 registers is correct?

John,

I think that your transmission is correct. The address is just shifted over one bit, with a single zero pad. Just to make sure, can you send a scope shot of the transmission?

Joseph Wu

I am confused when you say that the address is shifted over one bit. My understanding is that it needs to be shifted left 1 bit because the Read/Write bit is the LSB.

John,

That's basically what I meant. Give me some time to look over this transmission. What is this transmission? Is this the UBM or the MODEM_CFG write?

Joseph Wu

Here is my sequence:

1.       Send a low signal (Break) for 11 bit periods (1.18ms).

2.       The signal then goes high for 1.16ms while re-configuring the processor Tx pin for Uart operation. The baud rate is set for 9600.

3.       Send 3 bytes for register UBM (0x2C, 0x00, 0x01).

4.       Send 3 bytes for register MODEM_CFG (0x1C, 0x00, 0x08). 

John,

One thing I missed is that you should keep the HART transmit amplitude as the default. In that case, the transmit would be MODEM_CFG (0x1C, 0x00, 0x48). It's not the source of the problem, but I would keep the default amplitude.

Have you tried reading back the MODEM_CFG to see that the device received the write? I haven't had a chance to look over the scope photo in detail yet.

Joseph Wu

I would rather not get into adding functionality to read the values back just to see if the write worked unless I have to. I am looking for action on the CD signal line as my confirmation.

I want to first make sure that the timing is correct. If the timing is wrong, the read will not work either. I am hoping to write the register values once during initialization and be done. It feel like it would be too intrusive to switch between normal Hart mode and register access mode when our device is up and running.

John,

I'm still checking on this. Looking at the UART communication, it looks like the commands are sent correctly. The only thing that looks different is the time between the UART break and the write. 

Are you using the EVM? How do you have the jumpers set up and how are you applying the HART signal?

Joseph Wu

John,

Actually I think there is a mistake in the translation. The communication shouldn't need the address bit shifted because the UART write appears as the MSB which should naturally be a zero. In that case, the starting write should be UBM (0x16, 0x00, 0x01). I think the address byte is shouldn't be shifted (Red is where I think the bit is in error).

For the following write, it should be the same non-shifted address. The write would be MODEM_CFG (0x0E, 0x00, 0x08).

Joseph Wu

I have eliminated the delay between the Break command and the first write command. I have also moved the Read/Write bit to the MSB.

Still no action on the CD signal.

Eval board settings:

+5v connected to PVDD and IOVDD

Shunt (J1) jumper removed

Both J3 jumpers removed

REF EN (J7) jumper removed

UARTIN (J8) jumper inserted

FILT SEL (J19,20) jumpers set to internal

POL SEL (J13) jumper set to GND

Resistor Load (J14) jumper removed

Capacitive Load (J17) jumper removed

I made 1 more correction. The write bit should be sent after the 7 register value bits. But, it did not correct my issue.

 Do you have a scope trace from your end that you could provide?

John,

Unfortunately, I can't provide a scope trace because the EVM that I have works based on the SPI interface. I don't have a controller to use the UBM mode on this device.

I've taken a look at your transmission including parity and it looks ok to me. 

I also did a quick test on the EVM using the SPI interface. Once the HART enable bit is set, it should be able to detect the HART sinusoid and set the CD pin high as part of the detection. The only other bit I needed to set was to enable the SDO on the SPI interface.

I didn't use a HART master (the only one I have is currently being used) so I just used a function generator running at 1.2kHz, at an amplitude of 500mVpp as part of the test.

Can you send me a photo of your setup? I'll read through your setup based on your previous post, but I'd also like to see the board and how you have it connected. 

Joseph Wu

Here is a picture of my setup.

I have also attempted to issue a read command for register 0x16, but I am not seeing any response on UART OUT.

Here is the scope trace for the read:

John,

Again, the communication looks correct. Here's the bit stream going in from your image.

There are a couple of things that I want to check. Can you please set the /CS pin to high and the SCLK pin to low? I need to see if this is a requirement for UBM, but I did find this as a note from one of the digital designers.

What voltage are PVDD and IOVDD set to? I just wanted to check on the value.

Last, when did you receive this EVM. This looks like an older EVM design. The older EVM shouldn't affect the communication, but there is an updated version and I can go through the changes once we get communication working. I sent an email to the EVM team to check the status of the new version because I thought it was release several months ago. 

Joseph Wu

John,

Just to be sure, let's follow Figure 7-27 for the minimum functionality for UBM. Set RTS and /CS to the IOVDD level, and ground SDI and SCLK.

Joseph Wu 

John,

And also to be sure, this read is after the LSB is set so that the REG_MODE is set to 1 so that UBM is enabled?

Joseph Wu

Ok. I will make those hardware connections.

PVDD and IOVDD are both at 5.0 volts. We purchased 2 EVM boards only about 3 weeks ago.

The read function that I am trying is before the write function. Do I need to enable REG_MODE before I can read from register 0x16?

I will try writing first.

I have made the electrical changes:

RTS and /CS (and RESET) to IOVDD.

SDI and SCLK to GND.

I modified my code so that I am writing to register 0x16 first, and then reading it back.

Still no response.

Here is my scope trace:

Do you have a design engineer that could take a look at this? We are waiting to order new circuit boards with this modem chip on it. But, we cannot do that until we get this EVM up and running. Thanks.

John,

I have already asked one of the design engineers about this, and he didn't have any other input about using UART break mode. I'm going to try to set this up using a UART controller and see if I can get the communication working.

Joseph Wu

John,

I asked the digital engineer to run a quick simulation on the UART transaction to access the 0x16 register and this is the result of the simulation:

The thing that I didn't notice before was the insertion of the UART break before each transaction. In this exchange, it starts with the write to 0x16 register and then the two bytes of data (0x00 and then 0x01). Then there is another UART break that followed by the read of the 0x16 register. This UART break before the read of the register is the one that wasn't in your transaction.

So in this image the transaction is: Break, 0x16, 0x00, 0x01, Break, 0x96

After that, the device responds with its own UART break followed by a read of the status byte and then the two bytes of data. 

I wasn't able to get the UART host running today. I'm using a terminal program and MSP430 launchpad to set up a back-channel UART through the USB. I'm having problem sending the UART break.

If this communication works, let me know and I'll talk you through the connection of the HART input/output. I'm a little concerned that you have an older version of the EVM and the HART output isn't really tolerant of high voltages. The newer EVM has a series resistance and a diode to protect that node. In my testing haven't seen this as an issue, but there was a problem when Fieldcomm ran one of our boards through the HART registration tests and I altered the boards to 

Joseph Wu

Ok. I added the additional break. But, still no response on UART OUT.

I have tried with both of our EVM boards.

By the way, I used bit-banging to create the waveform because my Renesas RX230 processor cannot switch from I/O mode to UART mode fast enough.

You may need to do the same with the MSP430.

Test

John,

Your waveform does match up with the simulation. Here's your scope shot just above the digital simulation that was run by the digital designer.

Just to make sure, I mentioned connecting /CS high and SCLK low in a previous post. Did you set those pins? That guidance comes from figure 7-27.

Regardless, I'm hoping that we get the UART host working soon. I'll let you know of our progress on that when I make it into the office this morning.

Joseph Wu 

Yes, I have /CS high and SCLK low.

John,

We were able to get the UART host working but haven't had any success with the UBM communication. It took a while getting the hardware working but we now have two different systems able to send commands. We started with a bit-banged version of the sequence and that didn't respond through UBM, but we also have another setup based on a similar EVM and device which we should also be able to test in the morning.

Unfortunately, the digital designer had gone home by the time we got things working. We'll enlist his help getting the communications working then.

There was one last thing, powering the EVM from an external supply, I did notice a potential problem in the startup. After you power up the EVM, verify that the internal reference voltage is exactly 1.25V or that the voltage output is exactly 300mV. In my setup, the device seems to have powered up into some error condition and UART communication may be compromised because the internal timer might be off. If you are not using the internal reference, but the output is off by several millivolts, this may still be indicative of a startup error.

Joseph Wu

Hi John,

I believe we have a call setup for tomorrow, but if you happen to see this before the call, we would like to cover a few items:

1. Joe's last comment brings up a very important point.  At startup, the device enables a "alarm/power-on reset" reference voltage, which is nominially 1.25V, but not a precise reference voltage at all.  Usually the output is 1.25V±10mV.  If you measure the REFIO pin and see that your reference is not 1.25V±~1mV, then your device is in an alarm state or, more likely, a reset state.

2. Can you measure the RESET pin on header J9 or the RESET pin itself (pin 6)? As you are powering externally and the USB2ANY is not present, the RESET_IN net is probably floating.  You likely need to short that to external 3.3V or the IOVDD voltage.

3. I high recommend you do a simple readback command on the scope to confirm that you are communicating with the AFE881H1.  Issuing a BREAK+0x96 will return a non-zero value.

John,

In addition to Paul's comments, I didn't have a chance to write this up at the end of the day on Friday, but we were able to get the MSP430 launchpad communicating with the EVM. Here's a picture of the setup.

I think we had some initial timing errors in the break and that caused some extra debug earlier. The power supply is connected on J18 and the ground is connected to J4. Power is connected to PVDD through the jumpers at J3.

Using the MSP430 launchpad, the UART_IN comes in to the board through pin 30 of J10. We connected the MSP430 ground through J9, and we pulled up the RESET from the PVDD at J13. We use the J12 to connect to the logic analyzer.

Here is the logic analyzer output:

In out tests, we think that the break from UART in can be variable, as long as it is greater than the 11 bit times. At this point, we've tested this on this EVM and another EVM that is in this device family (with a similar digital section). We've also tested this with using a different EVM for another device which has a FT4232H for a controller.

I'm not sure why your setup isn't working, but it's something that we can discuss later. For now, look over this post and let me know if you have any questions.

Joseph Wu

It looks like I have figured it out. I was bringing my UART IN signal through the UART CONN instead of J10.

What other connections do I need to make through J10 besides the UART IN? I thought this connector was only used for USB2ANY purposes.

John,

We didn't use J10 for any other purpose. Pin 30 of J10 was only used for the UARTIN on the AFE881H1. We used J9 and J12 mostly to observe the signals with the logic analyzer.

Joseph Wu

I had it working for a while but, now it has stopped again.

Here is my trace of writing and reading back 0x16. The readback is 0x00 instead of 0x01. I do not understand why.

One thing that I have figured out is that I need to either do a read first or write the register (0x16) twice in-a-row, then the value of 1 (for UBM mode) sticks every time. 

John,

One thing that the digital designer mentioned is that the device will always respond to a UBM read, but if the UBM bit isn't set, then the device will respond as if the register is 0x0000. In the case where you were reading the 0x0000, it's possible that the UBM bit was not properly set. 

Have you tried reading from another non-zero content register? Note that the status byte preceding the register data should always come up.

When you write the register the one time it may not have latched. Is that possible based on the UART timing? 

Joseph Wu

Here is a list of different sequences that I have been working with:

1. Read Register 0x16 - If I read register 0x16 right after a power-up (UBM is disabled by default, right?), there is no response.

2. Write and then Read Register 0x16 - If I write a value of 0x0001 to register 0x16 right after power-up, and then read back from 0x16, there is a response but, the value read back is 0x0000.

3. Write Register 0x16 twice and then Read Register 0x16 - If I write register 0x16 twice right after power-up, and then read back from 0x16, there is a response and the value read back is 0x0001. Doesn't this mean that I am setting the UMB bit properly (correct timing) in sequence #2? How is it possible that the UBM is not getting set (latched) after a single write to this register?

John,

I'm checking with the digital designer on the details of startup and what UBM functionality should be available. I've also asked about the double write. We didn't see that behavior in our tests, so it's not something that we've considered. 

On another note, Paul had responded to one of the posts here. He's the one that got the UART working with the FT4232H using Labview. Unfortunately, he's out of town for a couple of days, and the code that we ran is currently unaccessible on is computer. I might be able to find another work-around but it would take some time.

Joseph Wu

John,

I checked with the digital designer and he says the device should respond to a read at a startup, but at first the device will respond as if the data is 0x0000. It does not respond with real data until 0x0001 is written into the 0x16 register.

One thing that the designer pointed out was that there is a wait time after the start of the device. There is a /ALARM pin (open-drain, so there should be a pullup) and the communication should start after the /ALARM is high. I don't know if you monitor the line, but it would be something to check on. There should be a delay after the device is powered on. I think the delay would be dependent on the nature of the ramping voltage, but I think that it would be about 200us after power has settled on the board.

Joseph Wu

John,

I did take a look at our setup again, and I've basically verified the things that the digital designer said. When I start up the board and then immediately try a read (in this case, the 0x16 register), I get a 0x0000 back for the read value. 

In another test I power up the board, and then write the 0x16 register to 0x01 and read it back. I get the 0x01 with the read.

I didn't have any issues with needing a double write, and got the expected value. Have you been able to read back the device correctly? It might be useful to verify the read with any other register that should be giving a non-zero response. Reading the CONFIG register at 0x02 might help identify when you're in the UBM mode or not. Let me know if there are any tests that I might be able to help run.

Joseph Wu