FPGA Write control coerces to error cluster when wired

[JohnS31]

Hello,  

I am trying to send pulses to an sbRIO 9627 using Labview 2017 for I2C communication.  The FPGA level code sends pulses correctly on both the SDA and SCL lines (verified on an oscilloscope).  The problem occurred when I tried to send the pulse commands from a Host VI and attempted to send out the data stream via a U8 array and into a Read/Write control.  The SDA output was intermittently correct at best although the SCLK pulses appeared fine.  In examining the code, the write terminal (labeled 'Data to send' in the pictures attached) appears as a U8 array when unwired, but then tries to coerce the input array to an error cluster when it is wired. 

I did find some old posts about this, but they seem to have discussed cluster inputs and it was deemed to be a 'cosmetic' issue only with no loss of functionality.  This does not execute properly.  Does anyone have any ideas as to the cause?  The arrays in both the host and FPGA code are sized the same and are all set to the same display format to the best of my knowledge (binary, 8 character field width, padded with zeroes to the left - in case it matters).   Any suggestions as to the cause or a workaround would be helpful.  I cannot post the code as it contains some proprietary information.

Thank you in advance.

[nanocyte]

I'll let someone else evaluate the cooerce bug. Seems cosmetic but important. Some of these bugs take way too long to fix.

Regarding the I2C issues, there is likely a bug in your FPGA logic right? Maybe in indexing? You'll want to evaluate what pattern you expect vs what you're actually getting to try and guess where the logic is going wrong.

Have you considered trying existing I2C example? That seems like it would easier for us to help you with because the code is available. 

This was one of the first hits when I searched for an example:

http://sine.ni.com/nips/cds/view/p/lang/en/nid/210637

[JohnS31]

Thank you for your response and suggestions.  There is always a possibility there is an issue with the code that I'm not seeing.  However, I wired all inputs on the host through to the write control using a flat sequence structure to ensure it was receiving the new data at each iteration so there shouldn't (maybe?) be any index issues there.  It also seems to be pretty straightforward into the FPGA side, whereby the array is passed into a single subvi, sequenced in a for loop, parsed for bits and then sent to the channels.  This being said - refer to earlier statement.   

We had investigated the example you pointed out and decided to reinvent the wheel due to some communication requirements that vary from the standard I2C protocols.  We will look again at these and see if we can figure out a solution.  I'll post when and if I find an answer.  Thanks again for your help.

[nanocyte]

I had another idea. If we wanted to convince ourselves that the transfer to the FPGA is OK. We could disable out most of your FPGA code and write a control into the index and an indicator on the output. You should be able to flip through each element in the array and see if it correctly shows up in "element". 

[JohnS31]

Apologies on the delay - I updated Labview yesterday afternoon and wasn't able to implement this until this morning.  I had been doing something similar, but only passing the last value in the FOR loop back up to the host to monitor.  I am now using your idea to check out any of the elements - simple but effective - it works well.  

At this point the code seems to work (data pulses are verified on a scope at least) and no longer has the 'coercion to error cluster' issue. I most likely zeroed in on the coercion problem as a cause incorrectly, since the most glaring problem was that the Run method was placed before writing variables. (Rookie mistake there - it's been awhile since I have played with FPGA). 

The coercion issue may have been related to one of the changes in the FPGA code.  The array was wired to a subvi in a case structure that was diagram disabled since it was not being used.  The array was also wired to an indicator in the same case (not diagram disabled).  I deleted the indicator along with the subvi in the unused case.  The coercion dot on the terminal is still there, but it is forcing variable array to a fixed size now, which I think is OK.  Unfortunately I am behind schedule so haven't tried to repeat the error, but if I can come back to investigate this, I will post the results here.

Thanks again for your insights and if you have anything else to add, I would be happy to hear it.