Problems writing to block memory from host

[jcooley2000]

Hi all,

I am working with a sbRIO 9639 and followed what I believed to be the recommended procedure to write to block memory from the host via (see attached host block diagram and FPGA implementation). However the running the aforementioned code does not actually change the memory and what is accessed instead is the just the previous values (which are persistent). 

On the other hand I am able to write to block memory directly from the FPGA vi (one by one) and obtain the results I would expect if I then run from the host after writing the correct values. In fact I can now see these values from the host using the read/write protocol. 

Does anyone have any idea about the cause of this problem? I have followed the implementation to write and read from memory in the examples but have not found any success. 

[Intaris]

Run the fpga bitfile ONE time before the for loop not 25 times.

[jcooley2000]

That did not work either unfortunately. From what I have heard, it sounds like the problem is from trying to pass the data from the Windows UI rather than the microprocessor UI. I had thought/hoped that wasn't necessary since this project is not too complicated but that might well be the case. 

[Oligarlicky]

I don't understand why you have a "run" after your for loop. You just ran it back in the for loop. Did you mean that to run after your first itteration of your while loop? Also, consider setting the "wait until done" to true in the For loop. You might want to post your false case from the FPGA.

More conceptually though, I would consider a new design—use a FIFO to transfer those points to the FPGA.

[Intaris]

After opening the reference to the bitfile you need to run it once without waiting for it to finish.

Then you can write to the FP controls and expect to be able to read something.

You may need to enable IO power or something similar before the FPGA will run properly depending on how your code is set up.  But then it should work OK.

One other tip: Pit the reference input and output into a shift register instead of simply wiring through the loop.

PS On he other hand, you DO have a loop somewhere on your FPGA, right?  At the moment your FPGA code does nothing else than write a single value to block ram and then ends.  Every time you re-start the FPGA code, the contents of the BRAM may or may not be retained.  Normally you would have the entire code in a loop so that it runs indefinitely.

[jcooley2000]

Thanks for the responses. I do have two separate loops (see attached). The lower one is just a substitute for the real digital signals that that will be sampled later. I also included the load into memory method released by NI from which I based my UI. It is for a cRIO but I thought that it would still be applicable to my case. I will try implementing your suggestions and see what happens. 

[Intaris]

Is your Boolean Read (switch between read and write mode) really outside of a loop?  If this is the case you realise it'll be read most likely before you can ever write to it, right?  The whole thing needs to be in a loop (which I dont see in your picture).

[jcooley2000]

Yes it is outside a loop but shouldn't you be able to write one value at a time without have the program poll constantly? Again I took the suggestion from NI released code (attached) where the write/read case and only the read case has a loop. Would there be a reason theirs would function differently?

[Intaris · Accepted solution]

I can't possibly comment on NIs code because I don't know who wrote it, why and for what purpose.

You can write to the control whenever you want, but if you don't actually read it again (polling) then you're never going to see the newer values.

While polling should be avoided on Host programs, it's kind of unavoidable and normal on FPGA.

Put the entire program inside another loop and try again.

[jcooley2000]

You're right of course. It was a combination of polling constantly and using a microprocessor vi to write to memory. Thanks for all your help. In case anyone is wondering the other code I was following from NI was from their documentation on continuous arbitrary waveform generation.