LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

Profile error: Memory access violation (data fetch)

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

0 Kudos
Message 1 of 12
(9,323 Views)

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.

best regards
Alexander
0 Kudos
Message 2 of 12
(9,301 Views)

Hello,

 

here I made a little example. It doesn´t make sense - it´s just to show the error.

 

bye & thanks

 

amin

0 Kudos
Message 3 of 12
(9,296 Views)

Hello,

 

here are the other Informations:

 

Screenshot:

error-lv.JPG

 

And I have the Full-License of LV2009 Embedded for ARM and Keil uVison 3.85.

 

bye

 

amin

0 Kudos
Message 4 of 12
(9,272 Views)

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.

best regards
Alexander
Message 5 of 12
(9,259 Views)

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 

0 Kudos
Message 6 of 12
(9,245 Views)

Hello Amin,

 

for your information, i talked to the developer and they look into profile error, but this can be take some time.

best regards
Alexander
0 Kudos
Message 7 of 12
(9,163 Views)

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)

 

CLN UI thread.png

 

 

 

Execution Prop.png 

Senior Product Manager
National Instruments
0 Kudos
Message 8 of 12
(9,156 Views)

Hello Jaidev,

 

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

0 Kudos
Message 9 of 12
(9,122 Views)

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".  

0 Kudos
Message 10 of 12
(9,100 Views)