EK-TM4C123GXL: GUI Composer V2 standalone pausing target

Steven Mitchell said:

After a couple of minutes, the counter in the GUI stops and the LED on the target has stopped.

Do you see this same behavior when previewing/running the GUI Composer app directly from the Cloud, or is it only when running the standalone app?

Steven Mitchell said:

A (this year) new Windows 10 i7 Desktop will run for hours no problem.

So the same standalone app works without issue on a newer desktop but not on some of the older ones?

Which communication protocol are you using with GUI Composer?

AartiG said:

Do you see this same behavior when previewing/running the GUI Composer app directly from the Cloud, or is it only when running the standalone app?

Yes, I tried both the standalone App and the online version with the laptop and they run for less than 2 minutes.

AartiG said:

So the same standalone app works without issue on a newer desktop but not on some of the older ones?

Yes, the desktop is fine online or standalone.

AartiG said:

Which communication protocol are you using with GUI Composer?

XDS and the GC project is Application (not Dashboard). The target code was written with CCS 7.2 offline.

thanks

Steven Mitchell said:

Yes, the desktop is fine online or standalone.

It is certainly odd that the same GUI Composer app and target app work differently depending on the PC. I assume the target app by itself keeps running fine (ie the LED on target board continues to blink) as long the GC app is not connected to it, correct? And the LED stops blinking a couple of mins after GC connects to it?

I will consult with a few others to check if they have other ideas about this. 

Yes, that is correct.

It was a surprise. It was when we installed on the customer's laptop, for a demo, that we found we needed Wi-fi for the standalone app to start up and that the target could be paused.

After the drama with the customer's laptop, I created a (new) minimal GC project for testing before writing to you. It has two labels and a button and accesses two global variables: (uint32_t)app_state.blink_count and (bool) app_state.restart which are bound to: ti_widget_label1.label and ti_widget_button.bindable_trigger (GC app below)

The target code can do more than flash the led - it is a complete app - I've described the problem as 'pause' because the GUI does not cause the target to reset and when first connected it hooks into the target while it is running. It is as if there is an accidental JTAG breakpoint, and disconnecting the GUI releases the breakpoint.

The target app on its own is working fine.  It is GC on the old laptops that cause it to pause, the older the laptop the shorter the time to when it pauses. This happens with a launchpad or with my own board.

minimal (2).zip

Steven,

A colleague put together a simple LED blink example to test this. Both he and I have let the standalone app run on a TM4C123GXL Launchpad for over 10 mins without problems. Could you try running the app found at the link below and see if you can reproduce the issue on those same laptops?

https://dev.ti.com/gallery/info/11101/TIVA_123_BlinkTestProgram/

If you can then it is most likely something with either the PCs or maybe software that is installed on those PCs that is somehow interfering.

This app will first flash the program so it might also help provide some indication as to whether the issue at your end could be a firmware issue of some sort.

 

Thank you for the test app.

Unfortunately, it behaves the same as my app on the oldest laptop - the best it managed was 179 seconds. (The newer laptop has been OK for a couple of hours so far. With my app and its full GUI it only faulted a couple of times over about 5 hours, so it is probably fine.)

I tried the online version first - 23 seconds.

Then extracted the standalone zip file into my GC runtime folder - 20 seconds.

I've tried re-installing the GC runtime, using the installer version of the BlinkTestProgram, rebooting the laptop... it is so strange because it actually works but only for a minute or so.

I did notice, on the occasions it stopped while I was watching it, that the blinkCounter on the PC would pause eg 7 while the target would continue to blink the LED another couple of times before stopping, then the PC blinkCounter would jump to 11 and stay there.  Clicking the toggle switch clears the counter on the PC but does not start the LED. Clicking it again sets the counter to 1 but does not start the LED. 'Click to Disconnect' starts the LED. 'Click to Connect to Hardware' and the counter continues from the current value from the target.

There are some error messages in the GC.log file, this is exactly the same as the GC.log on the desktop which works fine, so may not be of value? I've attached it anyway.

Steven,

This is certainly quite strange. I'm not sure how else to debug what could be triggering this in the older laptops. 

One last thing suggested by the team here is to gather the debug server logs for the Cloud Agent. I can't promise that it will provide the insight we need, but worth a try. To capture the log, you would need to uncomment lines #4 and 5 in ticloudagent.bat file which should be located in USER_HOME/TICloudAgent/ directory. Then use the online version of GUI Composer at dev.ti.com to run the GUI. Let the program run until the point where it stops. Make sure to disable logging once the data is collected as the log file can grow quite significantly. Zip up and attach the log file here.

 

Thanks for your help, I've captured a log file.

The LED on the board stopped blinking when the log file was at about 39,000 lines,

after about five seconds the log file started increasing again even though the LED was not blinking.

I then clicked the 'disconnect' button and attached the log file here.

my.log

Steven,

Aarti is out for a while. I will get this log to someone to see if we can figure out what is going on.

Regards,
John

From the log it looks like we are just loosing connection to the ICDI debug probe on the board. It is an older probe that is built onto that board. It is quite likely that the same thing would be seen running from within CCS.

One thought would be to connect an external XDS110 to it. That would be a bit of a pain on the TM4C123 LaunchPad as it does not have a 10pin JTAG header. Did you happen to add one to your board?

John

Hi Steven,

Have you tried to Wire Shark analyze IP packets to see what happens when counter in GUI stops?

Perhaps the out of range WiFi issue can be watchdog routine of target that trips a while loop of wait frames so the IP stack of target is not being trashed in the time when laptop GUI is out of range from target.

Steven,

Do you have a header on your board that we could connect an external debug probe to?

John

Hi John

Yes, I do have a header, but I don't have an XDS100 debugger at the moment. I was using the launchpad debug as a quick way to add JTAG to the prototype run, where we can send out firmware updates and finetune operating parameters with the GUI on a few trial machines.  I've cut the JTAG portion from a launchpad and added it to my board with a sealed USB to bring the connection out of the case. My intention is to use the built-in USB in the final version, implementing the bootloader and USB protocol to the GUI is new territory for me, so I was drawn to the ease of the launchpad/JTAG+GUI.

The target pausing/disconnecting was originally observed with my board, but since then all the tests and logs have been done on stock launchpads.

I can order an XDS100 and give it a go.

Regards

Steve

Steve

I will send you a friend request and private message

John

Just a note for others following this thread. We are going to give it a try with a standalone XDS110 to see if that helps. I am concerned that the Stellaris ICDI debug probe is causing the issue. By trying out the XDS110 we can eliminate that. Just waiting for it to arrive.

Regards,
John

Best of luck on that, meantime have you considered the UART option of RTOS to connect with cloud widgets? We have not tested it but noticed it was a new option RTOS 2-16-01-14 package.

The UART monitor module enables target communication with a client GUI Composer application.

The XDS110 arrived and works perfectly. It ran overnight without a problem.
Changing the project properties back to the 'Stellaris in-circuit debug interface' and using the debug portion of a launchpad as the JTAG probe, the original problem remains - the target code pauses after about a minute or two.
For this test I used my target board which has two JTAG connectors - one for the launchpad and the other for the XDS110.
thanks
Steve

Thanks, I'll have a look at the new RTOS. Ideally I would like a solution that can also re-flash the target.
regards
Steve

The TM4C1294 ROM boot loader can re-flash the target via USB0 without ICDI, JTAG or any other added hardware. Long as the flash is blank or just erased on the next POR the embedded boot loader runs, sends out requests to LM Flash or other DFU program of choice for bin file update.

BTW even with ROMBL it is recommended to install JTAG header to ease the transition and allow easy debugging of target via CCS.