10-22-2009 05:14 AM
Hello,
I have VI with a lot of mathematic Nodes. When I try to profile it, I allways get this error: "Memory access violation (data fetch)".
Keil uVision shows this error:
"Memory write not possible (Real-Time Agent)
Memory read not possible (Real-Time Agent)"
Without profiling the VI works on the MCB2400. And profiling also works if I try very simple examples.
bye & thanks
amin
10-23-2009 06:00 AM
Hello amin,
have you tested your VI without profiling?
Get you then an error back and is the profiling enabeld like in this example?
Do you use formula nodes or inline c notes for your mathematics?
Have you tested to implement the mathematics inline a c node?
Can you post an example to look into the code?
Are you using the evalutation or a full license?
Can you post an screenshot of the error, are there some more explanations?
I can be that your code will be written in some restrictred areas from the real time
agent so this error will happend, here some infomation about the poring of it.
10-23-2009 09:18 AM
Hello,
here I made a little example. It doesn´t make sense - it´s just to show the error.
bye & thanks
amin
10-26-2009 10:06 AM
Hello,
here are the other Informations:
Screenshot:
And I have the Full-License of LV2009 Embedded for ARM and Keil uVison 3.85.
bye
amin
10-27-2009 09:41 AM
Hello amin,
i have now tested your example on an MCB 2300 and i get the same error, but if i but an working application like the blinky example behind, the profiiling works fine. I will talk to the development why this works so.
10-28-2009 03:27 AM
Hello,
thanks for your response.
I can´t test the blinky example on the MCB2400, beacause it has a lot of hardware specific nodes.
But in some small test projects it works to profile. Just if they become a "normal" size or/and any Sub-VIs, than I get the error.
bye
amin
11-10-2009 07:24 AM
Hello Amin,
for your information, i talked to the developer and they look into profile error, but this can be take some time.
11-10-2009 12:33 PM
Hi Amin, Alex,
I noticed this issue had been open for some time, so I decided to post directly to save time.
Thanks,
Jaidev Amrite
LabVIEW Embedded PSE
Diagnosis: So apparently, this behavior has nothing to do with the profiler. The culprit is the Advanced Analysis SubVI call (Mean.vi) in BB.vi.
Mean.vi has a call library function node inside it and this CLN is configured to run in its own thread (labVIEW spawns a new thread for each call). Probably due to bad thread management on the ARM (in this case), this call causes a memory violation.
Solution:Turn off the "Run in any thread" setting on the CLN as shown in the attached screenshot - change it to "Run in UI Thread". For good measure also turn off reentrancy on Mean.vi (second screenshot)
11-13-2009 07:54 AM
I tried your Solution, but it is not possible to change the Call Library Option of the Mean.vi (it´s not possible to make a right click on the call library node).
But I also have the problem without a "call library node", so it doesn´t seem to be the solution anyway.
See Pub3.zip, there changed the mean.vi to a standard derivation (has not call library node inside), and I get the same error.
bye & thanks
amin
11-16-2009 05:22 PM
Hi amin,
You most likely cannot edit the call library node because you are looking at the clone of the VI (because it is reentrant). If you press ctrl+M to switch to edit-mode, you should be able to edit the CLN as described above.
The second issue appears to be directly related to profiling, and I'm currently looking into the issue. It is related to debugging being disabled in the VI settings of the standard deviation VI (or any other AAL VI for that matter). To work around this issue, simply make sure debugging is enabled for all of your VIs. This can be done very similar to disabling reentract execution of the VI (as described in the previous solution), just check the box that reads "Allow debugging".