LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with using SystemExec for programming hsc08 MCU via USBDM

Solved!
Go to solution

Hi,

 

I am issuing fairly simple commands to the Win10 CMD line using SystemExec. I can run the "program", "trim", and "verify" commands from CMD & everything works fine. When I run these same commands from LabVIEW I am getting an error 103 which is: PROGRAMMING_RC_ERROR_FAILED_VERIFY = 103 basically a verification error. USBDM error descriptions can be seen here:

 

http://usbdm.sourceforge.net/USBDM_V4.12/USBDM_JB16/html/_u_s_b_d_m___error_messages_8h.html#a5ee8b9...

 

I am hoping someone can tell me whether or not I am sending these commands correctly from LabVIEW. I am issuing "echo %errorlevel%" after each main command to see the return code of the actual command I sent, and not just that the initial command was "sent" correctly. (I hope that made sense).

 

All file paths are correct, so at this poiint I don't know if it's me in LabVIEW having the issue, or if it is possibly an issue with the MCU? I am able to program & verify successfully every time from either CMD, or by using an hsc08 programmer application (that would not be user friendly for production like my LabVIEW application).

 

As these are very simple VIs, I have included screenshots in this post, including one of the CMD line commands showing RC of 0.

 

Thanks very much for any light anyone might be able to shed.

 

Also, you can ignore the "concatenate strings" with no output in the first picture. That was from an earlier version of that VI, and I just haven't removed it yet.

 

George

 

1_Program.PNG2_Trim.PNG3_Verify.PNGWin10CMD.PNG

Probes_1.PNGProbes_2.PNG

0 Kudos
Message 1 of 3
(686 Views)

I am wondering if you may have to escape the %ErrorLevel%

 

 

0 Kudos
Message 2 of 3
(651 Views)
Solution
Accepted by topic author LvTech

So after much investigation I figured out the problem. The way I'm using SystemExec is fine, and the commands were correct. For each MCU, I was verifying the flashing after running LabVIEW application by using either CMD, or an application provided by the chip maker. The verification failed every time. The verification did however pass IF I flashed the chip from the same application.

 

What I found was that there was 2 bytes written to a specific block of memory that was used in the verify step. Since my LabVIEW application was powering off the UUT after flashing, when I powered the unit back up, the 2 bytes were now different! So the verification failed every time if done after a power cycle with either LabVIEW, Windows CMD, or the chip's application. It passed when programming & verifying with the manufacturer's app because I was not power cycling the UUT in between 1 process and the other.

 

Hopefully my experience may help someone else down the road if in a similar situation. As I'm still fairly young in my LabVIEW career, my 1st thought when I run into something such as this is "oh I must be doing something wrong in LabVIEW". Hopefully as I learn more in time I'll gain the experience / confidence to know whether that is the case or not.

 

Thanks!

 

George

Message 3 of 3
(613 Views)