AFE882H1: FIFO_U2H_WR

Aarti,

I think that your sequence is correct. You should be sending the RTS and then checking the CTS to see that the HART bus is clear.

The transmit sequence that you mention is also correct. You want to place the preamble bytes onto the U2H FIFO to send the 0xFF bytes and then send the data until it is transferred. Note that the parity byte should be correct for the data that you want to send (for both 0xFF and 0x00, the parity byte is 0x010). I would note that the data in the SPI register is written MSB first, and then sent on the MOD_OUT through HART as LSB first (preceded by a start bit, with a parity bit and stop bit following it).

The data transmission is correct. For the preamble, the transmission is 0x15 0x01 0xFF (with an added 0x84 if you are using the CRC check). During this transmission, the /CS should be low for the duration of the frame. If you are sending 0x00, then the transmission would be 0x15 0x01 0x00 (with a 0x77 CRC byte). 

I would note that the HART preamble is typically 5 bytes minimum with 20 bytes maximum. Also, If you're only sending 10 bytes of data, You might not need the IRQ. The FIFO buffer longer than the data and there's no chance of overflowing the buffer. Of course, most transactions are going to be much longer and the IRQ can be used to keep track of when to read the device and determine what remains in the FIFO buffers. Table 7-9 shows how the IRQ can be used with the MODEM_STATUS in that context.

If you're having issues with the transmission, I would definitely use an oscilloscope or logic analyzer to check the transmission see that that the device is responding correctly. You can post back with scope shots of the data

Joseph Wu

Thanks Joseph for the reply.

I am unclear with one thing here that for every byte and parity data I need to write to the FIFO but I have 2 ways to write to FIFO I am confused with which one is correct ?
like if I want to send 10 bytes of data the FIFO pointer will not increment on its own or it will increment 

Way 1:
0x15 - Parity - (Data - 0x01)
0x15 - Parity - (Data - 0x02)
0x15 - Parity - (Data - 0x03)
0x15 - Parity - (Data - 0x04)
0x15 - Parity - (Data - 0x05)
0x15 - Parity - (Data - 0x06)
0x15 - Parity - (Data - 0x07)
0x15 - Parity - (Data - 0x08)
0x15 - Parity - (Data - 0x09)
0x15 - Parity - (Data - 0x10)

or its like 

Way  2:
0x15 - Parity - (Data - 0x01) - Parity - (Data - 0x02) - Parity - (Data - 0x03) - Parity - (Data - 0x04) - Parity - (Data - 0x05) - Parity - (Data - 0x06) - Parity - (Data - 0x07) - Parity - (Data - 0x08) - Parity - (Data - 0x09) - Parity - (Data - 0x10 )

out of both this sequence which one is correct above one or below one ??

Cheers,
Aarti

Aarti,

The first sequence is the correct one:

0x15 - Parity - (Data - 0x01)
0x15 - Parity - (Data - 0x02)
0x15 - Parity - (Data - 0x03)
0x15 - Parity - (Data - 0x04)
0x15 - Parity - (Data - 0x05)
0x15 - Parity - (Data - 0x06)
0x15 - Parity - (Data - 0x07)
0x15 - Parity - (Data - 0x08)
0x15 - Parity - (Data - 0x09)
0x15 - Parity - (Data - 0x10)

Putting data onto the FIFO is a write to the SPI register and subsequent writes still need to start by putting data into the correct register. Each transaction starts with a 0x15.

Joseph Wu

So currently my application I want to send 255 bytes a complete HART frame 

so for that I am filling the FIFO with 32 levels (5 preamble bytes) and rest 27 levels for Data 

and then waiting for the IRQ of level flag where I am setting the threshold of U2H_LEVEL_SET to 3 which means once the FIFO has only 6 levels remaining the IRQ will come which indicates the Micro to write more data bytes in FIFO 

on generation of this IRQ I am filling the 26 levels of data again and this repeats until all 255 bytes data + 5 bytes preamble is sent 

Is this approach correct ?

Also i see in the data sheet it is said to write only 1 additional byte of preamble why are to asking to send 5 minimum bytes of preamble, I know for HART data frame it is required to send 5 bytes as preamble but data sheet does not say so 


Thanks in advance,
Aarti 

Joesph,

Are you telling to write 1 byte in FIFO after the FIFO_U2H_LEVEL_FLAG is set to 1 and sets the IRQ
basically I was trying to fill all remaining levels in the FIFO as I already know when I receive interrupt my FIFO has 6 levels 

so I was filling THE FIFO and writing 27 remaining levels asap I get the interrupt 

Aarti,

After you get the level flag, should just be able to write to the FIFO until you get the FIFO full interrupt. That would include just writing the remaining levels into the FIFO. Is that not working? 

Joseph Wu

No I have not yet checked if it is working or not 

But I have set the U2H Threshold to 3 which  means once my FIFO level is 6 I will get interrupted for level flag 

ASAP I get interrupt I check the size is less than the number of bytes I want to sent if yes 
I will call w

and send the data 0x15 Parity(0x01) and Data (0xFF) as shown below 
TOTAL fifo levels (32) - 6 levels already present in FIFO (6) which is 32-6 = 26 times in a for loop 

Thanks,
Aarti

Aarti,

One thing that I noticed is that you've written the parity bit as always 1, but that value (for the second byte) should be calculated for odd parity. The bit isn't an enable but rather the parity bit itself.

There is one thing that I'm checking on for the sequence. It's an problem with the transmission of data across SPI when the HART is active. I'm working with one of the digital designers to track it down. It may affect your data writes to the FIFO register, so give me a little time to review the sequence.

Joseph Wu

Sure,

Also I was trying to Write to the Config register simply disabling the CRC byte in AFE882H1 
0x02(write to config register) 0x00 0x26 (16 bit data) 0x24(CRC)



Also while reading back we are trying to read the config register 
0x82 (read to config register)

2 bytes of NOP to get the value of config register but it is coming as 0 




Note : we are using SPI in mode 1 (pol 0 phase 1)
also the FSDO is set to 0 


Thanks,
Aarti 

Aarti,

For the readback, the SDO must be enabled. This is the DSDO=0 in the CONFIG register. If DSDO=1 (which is the default), SDO is Hi-Z. I think you would write 0x00 0x24 instead of 0x00 0x26 as the data.

Also, the readback is done with two complete frames. The write is 0x82 0x00 0x00 to send the command and the readback is loaded into the output shift register and clocked out with a NOP of 0x00 0x00 0x00.

Joseph Wu

Hi Joseph,

Thank you now I am able to read back the data 
I was missing out the 0x82 and then 2 0's after that for a complete frame 

but is there any update on 
There is one thing that I'm checking on for the sequence. It's an problem with the transmission of data across SPI when the HART is active. I'm working with one of the digital designers to track it down. It may affect your data writes to the FIFO register, so give me a little time to review the sequence.


Thanks,
Aarti

Aarti,

We just identified a problem writing to the SPI while the HART FSK is being sent out from the U2H_FIFO. It was noticed when using the duplex mode of the device when using SPI to write to the U2H_FIFO. It was noticed in the following E2E thread for the AFE881H1 which has a very similar digital section to the AFE882H1.

e2e.ti.com/.../afe881h1evm-issue-with-hart-data-transmission

Most of this text is taken from the other post, but as the device transmits the HART FSK, the device fetches data from the FIFO. The data fetch occurs for every byte that is transmit at a period of about 9.2ms (11 bit times total). For each data fetch there is an internal reset pulse (~1us) that clears the read request from the FIFO. Unfortunately, if this clear is coincident with an SPI write, then it also clears the SPI transmission as well. We've checked this in the Verilog code, and verified this mechanism through a simulation of the digital section of the device.

The best way to determine the timing of this fetch is to use the IRQ. The IRQ can be set to check when the FIFO is empty, full or at some user-programmed level. The IRQ is indicates in each of the previous cases when the device has completed a HART byte transmission and started a fetch of the U2H_FIFO to transmit the next HART FSK data. At the IRQ indication the device will transmit the next HART FSK byte. Through 9ms (a little less than 10 bit times), the SPI should be free to receive data. You would do this writing to the U2H_FIFO.

For writing to the FIFO, data depends on a correct write in a specific sequence and you can't double write. For most other actions, If you are not writing to the FIFO, then another way to counter this problem would be to write the SPI data twice whenever the device is transmitting HART.

Let me know if you have any questions.

Joseph Wu

Hi Joseph,

Referring above reply of yours, I am using the first approach where I fill the FIFO with 32 bytes and the set the RTS in this case if my total transmission bytes are 32 or less than that I should never see a byte miss on HART OUT right 

but here in my case i am sending more than 32 bytes and I have to sync SPI write and HART fetch from U2H FIFO so they are never at the same time, I am following the below steps can you please correct if my understanding is right 

Set the U2H_LEVEL_SET to 3 in FIFO_CFG Register
Enabled the FIFO_U2H_FULL_FLAG, FIFO_U2H_LEVEL_FLAG in  MODEM_STATUS_MASK Register
I have preloaded the FIFO_U2H with data
Set the RTS bit to 1 in MODEM_CFG Register
As the CTS is asserted the device starts fetching the data from FIFO and sends it over MOD_OUT pin 

Expectations is to receive the IRQ when FIFO level is 6 as the threshold level was set to 3
on reception of this interrupt I Fill the FIFO until the FIFO is full( get indication on IRQ of FIFO full).

Now the above suggestion says to sync the SPI write with FIFO HART transmission.
As per my understanding once in every 9.2 ms the device fetches the data from FIFO, and on the IRQ reception the device is expected to be fetching the data from the FIFO, so once after receiving the interrupt I have to wait for ~0.2 ms and send a SPI write is that correct ?

Thanks,
Aarti

Arent this statements contradicting 

1. The IRQ is indicates in each of the previous cases when the device has completed a HART byte transmission and started a fetch of the U2H_FIFO to transmit the next HART FSK data.
2. At the IRQ indication the device will transmit the next HART FSK byte.

First point states as per my understanding When the micro receives IRQ from device the device is busy fetching data from FIFo and micro should wait for few ms to send data to device

Where as from second i understand is device has already fetched data from FIFo and is busy in transmitting the HART FSK so device is free to receive SPi write

Which is true from both

Can you please clarify the same 

Thanks,

Aarti

Hi Joseph,

Can you please answer my query asked above also can you share the timing diagram for clear understanding this case.

Thank you in advance,

Aarti

Aarti,

Sorry, Monday is a holiday in the US.

Yes, I think that your sequence works. However, I think that the U2H_LEVEL_SET is a < comparison and not a <= comparison. So, setting the level to 3, I think you need to go below that level to trigger it. Instead of triggering at 6, I think it triggers at 5.

For your question on the IRQ, the IRQ indicates the time when device fetches the data from the FIFO and places it on the MOD_OUT as the HART FSK. This occurs immediately. When this is indicated, you would wait a couple of microseconds and the microcontroller has about 9ms to send the SPI communication to the device uninterrupted.

I'll draw a timing diagram tomorrow when I get into the office.

Joseph Wu

Sure Thanks, that would help

I have 1 more doubt which is 
In my current steps:
first i set the FIFO to full level 
I get the interrupt of FIFO full where only 1 time I set the RTS to 0 after the CTS
device is expecting to send the data on MOD_OUT which device does internally by fetching the FIFO and sending the data out to MOD_OUT 
Now as in my application I want to send more than 32 byes 
on receiving the LEVEL IRQ I start to write the FIFO again but here RTS is already set once which means modulator is on already and sending the HART FSK
so asap I fill the FIFO will it will start sending the data on MOD_OUT will there be FIFO full any time here as I am not getting FIFO full 2nd time 

also secondly do I need to cleat the FIFO once I send 1 complete frame for the 2nd time if I want to send do I need to send sw reset to clear HART FIFO and all ?

Regards,
Aarti

Hi Joseph,
We are not using the IRQ mechanism,
Firstly in the application we write the DAC register every 10ms 
Also every 10ms after writing to DAC we read the FIFO status register to check if there is anything in the FIFO_H2U to read 
Consider FIFO_H2U is not empty in this case we read the FIFO _H2U and then process it and write the data to FIFO_U2H to transmit the HART FSK

We fill FIFO with 32 bytes and assert RTS, which should make the device transmit FSK by fetching data from FIFO_U2H
but also to note here every 10ms data is written to DAC and also a read request to read FIFO_STATUS register 
While data being sent from FIFO_U2H
I see missing data bytes 

FF - 5 bytes
78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86
87 data byte is missing in the analyzer capture 

How can we make sure the data do no miss in this application as we are not using IRQ.

Thanks,
Aarti

Hi Aarti, 

Joe is out of office this week. He may chime in earlier if he has time, but please expect a delayed response. 

Best,

Katlynne Jones

Aarti,

Sorry, I've been out of the office for more than a week, and I'm just getting caught up on work.

Without using the IRQ to indicate when the FIFO fetch occurs, it would be difficult to determine when the proper time to send data to write to the HART transmit FIFO. If the IRQ is not an option, can you use the 10ms timer to send data to the device? This would include the DAC write, and the HART transmit. If you wait every 10ms to send a single HART byte to the FIFO, then you would have a gap of about 833us between HART bytes, but you'd know when each transmission occurs.

Joseph Wu

Hi Joseph,

So the update is we tried this approach of using the 10ms timer to send data to the device.
consider the data bytes to send are 34
writing data to DAC register then writing to FIFO 1 data byte at a time, after filling FIFO to 16 bytes assert RTS, and then in parallel(AFE sending data to outside world) our FW send rest bytes(which is 18 - 1 byte in 10ms following writing to DAC register) left in total message bytes to send.
and it works also.

but when sending 2 bytes data in 10ms timer is not working 
10ms cycle, in that writing data to DAC register then writing to FIFO 2 data byte at a time, after filling FIFO to 16 bytes assert RTS(as per my understanding until RTS is assert there should not be any problem as there is no fetch and write at the same time which may cause miss of data bytes) so after RTS is asserted AFE might start sending data to outside world and our FW send rest bytes(which is 18 - 2 byte in 10ms following writing to DAC register) left in total message bytes to send.
this is not working....

I feel this can be because of a device fetching data from FIFO and writing 2 bytes in FIFO is causing some miss in bytes which is causing issue..
Can you please comment on the above what can be the issue here

Thanks in advance.
Regards,
Aarti

Aarti,

In my original suggestion, I had suggested sending SPI communication in 10ms increments so that the device would get the FSK byte and then transmit it completely before entering the next byte. In this way, you'd only use one element of the FIFO, so that you would have no collision between the fetch of the FIFO data and any other SPI communication.

I'm not sure I understand either of your sequences (the 1 data at a time and the 2 data at a time). Part of the problem is that I don't know the timing relation between when you send the SPI command and when the data is transmitted by the HART FSK.

Can you describe these communication schemes? It might help to show a basic diagram of the communication timing.

Joseph Wu