Command line for ICD interface - factory programming

[robleso7473]

Hello once again,

I thought my yearly CCS forum visit was satisfied last month but here I am again!

So, I am close to launching my first product and I'm still working out the factory testing details. One thing I've not settled on is how I will program my MCU. On the bench I just fire up CCS info compiler and run the ICD interface app to program my targets, BUT in the factory I want to integrate the programming operation into some python or even command line interface. The plan is to use the ICD-U64 as the programmer connected to my production target MCU.

The big question: can I run ICD Interface from within Python or command line?

Why I want to do it this way:
I want to simplify the interface for the factory worker where they don't have to crack open ICD Interface app separately and have them accidentally click on some button that will mess up the entire programming operation.

Any thoughts and/or ideas?

Thanks much,
O

[robleso7473]

Maybe I'm going to answer my own question but is ccsloader the command line version of the GUI ccsload? Was not easy to find this information if that's the case.
O.

[temtronic]

from their website...ccsload..
Command Line Options

OS Support - Powerful Controls through Windows or Linux
Operational Settings - Specified at the Execution Level
Easy Set-up - Perform Tasks like Save, Set Target VDD, and more...
Presets - Operational or Control Settings
Batch Files - Simplify Routine or Repetitive Programming

so you 'should' be able to .

In the MSDOS days, you'd create 'batch' file which had the executable file(exe) with options, make an icon, save on desktop. DBL click to run the program.

I'm a dinosaur but I suspect someone can show that this IS possible ?

[robleso7473]

Thanks temtronic.

[leach67]

[Jansen]

I'm developing a production app that will call out to ccsloader.exe. Here's a batch file that will connect to a LoadnGo at least. It will likely work with the U64. Eventually, I plan to work with the Prime8, but I don't have one available to develop with at the moment.

It currently does several things. You can REM out the different sections to test one at a time. I may need to use the connection test first then the write file to target for better control

[temtronic]

I don't use any of those but....perhaps....

VERBOSE , at least in the dinodays, meant that when you sent a command to a device, the response was returned in a phrase as opposed to a number.
IE when 'commanding' a modem to change a register, it usually responds '0' but if 'verbose' was enabled 'OK cr lf' is returned.

Hopefully somewhere in the 'documentation' you have, it explains this ?

[Ttelmah]

In IBM Unix C, there use to be an include file, for 'VERBOSE', so that if this
was #defined, the output messages were displayed, while if not these were
suppressed. Adding it to the command line in the compile. #defined it.
That include (very slightly altered, but basically the same), is available in
GitHub at:
[url]
https://gist.github.com/AndrewGuenther/9257752
[/url]
Many of the standard utilities in the OS, had an option that if VERBOSE
was included in the command line, they gave more detailed messages.
It is one of those things that a few parts still support, but little now does.

[Jansen]

[temtronic]

hmm..re: Enables additional error information when using the command line CCSLOAD.

.. if there's no errors , no messages are sent , and of course no additional ones if VERBOSE was enabled....

One test... make it 'error' somehow, see what's reported, then enable VERBOSE, run again and see what NEW information is reported.

[Jansen]

Been doing that with no difference in output.
You folks are focused on a passing observation I made in my original post. Does anyone have a response to my actual questions?

[Ttelmah]

I think the reason we were not replying, was that nobody was sure what
the question was?.
You were referring to ICD.

CCSload, handles ICSP, _not_ ICD.
ICD, requires a debugger program, that interfaces to the ICD core uploaded
when ICD is specified. You need a complete program to interface with this
core, and the core itself to be loaded.
So you would have to have PCW on the system, with It's licensing data.
This can be loaded with a file specified, but nothing else, so any debugging
would require the user to use this. The program would have to be recompiled
with the debug option selected, and reloaded with the core attached.

Now the only command line system available that might be able to do this
is MPLAB IPECMDBoost, which was a utility that MicroChip has which allows
command line control of the MPLAB-X environment, but given you won't
know what actually wants to be done by the IDE, the code for this will
be hell. In fact this specifically says that 'Running IDE with this is not
supported', so 'no'.

However though talking about an ICD unit, you seem to only be wanting
to use ICSP. If so, CCSLoad will handle this fine, and can be driven by
the command line.

[temtronic]

One problem I have, being a dinosaur', is that 'Jansen' asked something in 'Robs' post which threw me for awhile. In my mind ,I see a PC--> programmer--> product with PIC but he talks about THREE different 'programmers'. That,to me ,says that THREE different PC programs have to be created to talk to them, so overall, seems very 'time consuming' compared to using just one programmer, known to work. Of course I don't know the time it takes to do the actual task, connect target, press button,wait,done, disconnect, next..... or quantity of targets(10,10, 10,000 )? I looked up 'Prime8' and can see it would be 'complicated' to code a PC program to use the app to control the programmer.At the very least a LOT of time would be spent 'working out the bugs'.

It might have been better to start a new post,with better detail of what is required to avoid confusion.

[Jansen]

Now that I have a Prime8 to develop with I found a few things:

1. The SLOT parameter does not seem to work. Using SLOT=ALL is the only option that at least begins to work.
2. When the CLI appears to not actually do the command, the returned errorlevel is 4. When it does appear to do something, the returned errorlevel is 65284 which is 0xff04. Is the ff byte supposed to be the slot bit mask? Note that 4 is likely the operation failed indication.
3. Using MODE=ERASE_ON_ERROR seems to cause errors for the Prime8. Perhaps because I also have MODE=BULK_ERASE on the same command line.?? But using both MODE options with the LoadNGo does not seem to cause issues.
4. The ERASE command returns immediately and does not seem to do anything, but returns no indication execpt errorlevel=0, which is Success.
5. The VERIFY=BLANK command in the GUI requires only one slot selected, however for the CLI only SLOT=ALL appears to do anything, but even with zero targets connected to the Prime8 the CLI reports Chip 100% Erased.
6. When programming appears to actually run, it always reports Failed slots:1,2,3,4,5,6,7,8. However, when I program using the GUI app with the same hardware setup, it shows 4 of the 8 target boards passed programming. (Yes, I don't have 8 good targets at the moment. )

Has anyone else successfully used the CLI command with the Prime8?
Any suggestions would be appreciated.

Also, before using the batch file, I close the GUI app to prevent conflicts, but I have to power cycle the Prime8, too. Does that seem right?

[Jansen]