VI that runs a Statechart won't run on ARM target if debug is enabled.

[pkovitz]

Using LabVIEW 2009 with ARM Microcontrollers module and Statechart module, when I configure a project for the Luminary EK-LM3S8962 ARM and build it for the ARM target, the project builds and downloads, but the project immediately halts. If I disable debugging, the project runs, but then I can't use VI front panel objects for debugging. If I replace the statechart module Run Statechart with a more standard LabVIEW state machine construct, I don't have this issue. Is there some module I am supposed to add to the project build specification to make the system work properly in debug mode with statecharts? If so, I can't find the documentation for it. Any help would be appreciated.

[MeghanK]

The feature to debug a Statechart is currently not available for embedded hardware. It is recommended to debug the Statechart by executing it on a Windows platform, and then moving it to the Embedded target. Regardless, I was hoping to get more information from you in case this is something that we can improve upon. When you say the LabVIEW project halts, does it halt as soon as you run the VI, or once it hits the Statechart function? Can you provide more details? Also, what debugging method are you using? If you could provide this information, and attach your LabVIEW project so that we can reproduce the issue onsite, we can look into this further.

Thanks!

[pkovitz]

I am running ULINK2 debugger. The project halts right away. I had to make a new project to test this. I used the MCB2300 board. If the VI ran until the Run Statechart function, then the display would show two lines of text. As it is, the display remains blank. The new project is attached. If you check Enable Debugging in the build spec, you will observe the behavior I describe.

[pkovitz]

This time, with the project attached.

[Stephen_S.]

Hi pkovitz,

Thanks for posting your project. I will include this information in a corrective action request for R&D so that they can investigate the issue further. I appreciate your help in the constant effort to make LabVIEW a better product.

Regards,

Stephen S.