This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Remote programming LM4F120 Launchpad

Dear All,

I have my CCS installed on my office PC and the Launchpad (LM4F120) is connected to another PC located in my LAB on the same Ethernet. 

I want to use my office PC to program and Debug as well, the remotely connected Launchpad. 

How would that be possible.

Creating a bin fall on my office PC and then sharing the bin file with the LAB PC and using a programmer on the Lab PC is not a suitable option for me.

I was thinking to use a virtual comport shared on my Office PC but then CCS can not recognize as a Stellaris com-port because what I understand the CCS looks for a comport that has some identity to make sure the launchpad is connected to the local PC.??

Thank you all.

Regards

Sahil

  • How about RDP or VNC ?

    This kind of embedded development quite often involves power cycling or resetting the target. Not sure how you achieve this remotely ...

  • Hello f.m.

    Or OpenOCD with telnet for PC and gdb for Linux.

    Regards

    Amit

  • Sahil said:

    I want to use my office PC to program and Debug ... the remotely connected Launchpad. 

    May I raise one, "Lone wolf" objection to this (remote control) desire?

    Our small tech group has been at this (enjoying some success) for 2 decades - we most always find comfort & benefit from being in close (yet safe) contact w/the hardware.  It's useful to monitor the board current drawn from a proper, current-limited lab supply - quickly/efficiently/fully reset and/or power cycle that MCU board (another mentioned) - or connect/disconnect a sequence of auxilliary test boards - which "plug into" your base MCU board. (we use such pre-built, known good, auxilliary test boards so that constant/chronic, "reinvention of the signal wheel" is avoided - i.e. "amateur-hour")

    While it may be possible to achieve some of the above remotely - our findings do not generally support remote control of a "DUT" as complex & (likely) interconnected as an MCU board...  And - as always - time spent in mastering & making that remote control truly robust - subtracts from your more central (MCU) mission...

    Minus any strong gain - which you've not presented - risk/reward/effort seems "not" to justify this remote idea...

  • The lab pc has a very limited resources and is not for the purpose of installing the tools chain required for development. So therefore, I have installed my tools chain on my office PC and want to debug from office to my launchpad connected to the lab pc.

    VNC should not work as I will compile my code on my office PC via CCS and the debugger of the CCS looks for a launchpad connected to the local COM. 

    I dont know if that is possible to configure CCS to use a certain remote COM port for debuging via VNC etc??

  • If I explain alternatively, the idea is to VNC my office PC (which has CCS installed) from my lab PC to use the resources of my Office PC for codding and debuging while the launchpad is physically connected to the lab PC.

  • Remote debugging is not a "standard use case" in bare-metal embedded development, so I would be surprised if it worked flawless in any of the available IDEs.

    Other options are a portable development system (say, notebook), or having the target (i.e. the launchpad) at your host system (i.e. the office PC). The launchpad only requires a +5V supply via USB, so there is no need for a lab (at least in the initial stages).

  • f. m. said:
    only requires +5V (via USB), so there is no need for a lab (at least in the initial stages).

    Second that - and my small group finds the "lab" a, "less than warm/especially inviting - place."  Charred component bodies litter the lab floor - when they've not entombed themselves w/in lab benches, nearby structures.  (walls, even high ceiling) 

    Our lab sees greatest use when pneumatics, hydraulics and electronics intersect - and/or when motor or system noise becomes disruptive - or the risk of injury (to personnel or equipment) rises.

    Hard to match the convenience of an USB powered board - yet a lab-supply, (current limited) provides solid protection while providing critical, automatic board data.  (current demanded, voltage sensitivity, analog signal source etc.)  Compact lab supply fits nicely - normal desk-work space...