Five Year's Work Held Up By CCSLoad.exe - UPDATE!

[Bill Havins]

Hello to all!

I own a small company. For the last five years I have been working 16-to-18 hours a day on a series of novel PIC-based devices intended for the transportation sector. We have kept them to ourselves, waiting for the Patent Office to rule on our patent application. The early prototypes were developed with PIC16's.

We recently received word that our patent application will be granted so we have ramped up our efforts to get our products to market. We have moved from PIC16's to PIC18's. The first one uses a PIC18F2321.

In the past several days I have been trying to get PCW (version 4.071) and CCSLoad to work with our Mach-X programmer. The short version of this story is that the fuses we include in our code never make it into the PIC. The configuration bits don't show in CCSLoad. When I tried to set them manually in CCSLoad (File > Configuration/ID) the software wanted the file saved or the bits would be lost. When I tried to save the file CCSLoad went into an endless error loop, stating, "Access violation at address 006DB1F5 in module 'ccsload.exe.' Read of address 01241000."

I have tried everything to get CCSLoad to run "correctly" again. It continues to go into this error loop as soon as it sees the Mach-X programmer. I have un-installed and re-installed CCSLoad twice. I have deleted and replaced the Mach-X drivers twice. The only thing I haven't done is re-install PCW.

Before you ask, all of the documentation I can find says that the PIC18F2321 is a supported chip. But the chips that I did program before the above events don't run.

I have sent an email to CCS Support; I hope they respond.

I hate to think of trying to move five years' worth of work to another compiler (not just code); we need to move from PIC16's to PIC18's and my recent experience says CCS's products are going to cause us too much downtime. As it stands now I can't program any PICs at all!

I would appreciate your thoughts and comments.

Bill

[PCM programmer]

Come on, if your whole company is riding on one product, just buy a
new programmer and be done with it. Our company uses a Microchip
ICD2 for our low-volume products. I'm happy with it. They now have
the ICD3 which I haven't tried. The ICD2 uses MPLAB as the IDE.
All our programming is by ICSP, with the board supplying its own power.

[scottc]

Bill, since your code base was developed on the Pic16 platform, I think
it makes sense to verify that CCSLoad works with the PIC16 parts first.

If you run into issues with the pic18 parts, I would consider upgrading
to a new programmer. CCS offer the ICD-U64 which is pretty good
for in-circuit programming.

Microchip also offer a new programmer called the ICD3.

Both of these items are inexpensive.

If you intend to go mass production, then I think it makes sense to have
your chip-supplier program each chip before they populate them on the board.

Most chip vendors offer this type of service.

At a bare minimum I think it would be a good move to include a ISP
header on your board for field upgrade or service.

Scott

[Bill Havins]

PCM programmer,

I appreciate your suggestion; it is an adequate work-around.

If our company was larger, and if we had been in business longer, spending time trying to debug a compiler/IDE that is advertised as a "complete package" might be something that we could do (we might have a designated IT person). And we might have the flexibility that comes with employee numbers, continuing income streams, and the other assets of larger companies. But ours is a "start-up" and we invested in CCS's "complete package" with the hope that it would become the "backbone" of the software development parts of our embedded systems.

Now, with CCS's propensity for issuing updates filled with bugs, and their lack of regard for adequate documentation, we will have to either "patch together" an IDE/debugger/programmer system or buy a system that is generally stable and reliable, where the parts of the system work together to provide a reliable "whole".

I have just spent four more hours wrestling this stuff. I used System Restore on the Dell Precision Workstation to "undo" the problems CCSLoad caused. I then reloaded the software to see if it would "see" the configuration bits in a file - it didn't see them! It labeled the file as a "Corrupt File".

I happen to have another PC with the same processor (E8400) running XP SP3 at my house. It also has all of the CCS software on it (I work most nights). CCSLoad on that computer found the configuration bits and called the file a "Good File". The file was read from the very same USB drive so it was the same file!

I have no explanation for what is happening.

Now, if you were to charge for troubleshooting this what would your bill look like? Certainly my time is worth at least 25% of what yours is. And, whatever the price, the "cost" of CCS's careless attitude about their "complete package" is getting very high indeed.

We'll see if they respond to my earlier request for help. If I haven't heard something from them by mid-week it's time to pull the plug on their stuff and get ready to pony up the money for the parts of the Microchip/HTSoft system that we need.

More than anything I find this very frustrating. My customers always know that what they buy from me has been "run through the wringer" before they ever see it - it probably won't let them down. They always have the information that they need. And they have a troubleshooter available to them 24 hours-per-day. I was hoping CCS had a similar business model but I was wrong.

Bill

[Bill Havins]

Scott,

The Mach-X is capable of ICSP; that's all we ever do (and our boards are powered up when we program them).

I have used our setup to program PIC16's and PIC18's with only minor difficulties (there's always a "niggle" with software upgrades from CCS). As above, it's ICSP all the time.

I think I've run into a CCS bug. I'm not a Windows expert but I think the "event" (whatever it was) corrupted a System file.

Both machines in my post immediately above are running XP Professional SP3 and they have the same virus protection software. They are not "clones" but they are really, really close.

Bill

[Douglas Kennedy]

I know its frustrating at times. You may be experiencing free features of a Microsoft OS. Every PC needs a reset button because it is almost certain that every PC will need to reset a windows OS at some point. You probably spent thousands on lawyers for your patent. For commercial development some keep a pristine PC ( no web use or downloading of stuff) so as to avoid viruses etc. Put a PC to one side for this purpose. Buy a second PIC device programmer (ICD-u64) as a backup. Always archive a full CCS compiler system with your final version. Back up your PC twice as often as you think you might need to. If you run into a free Microsoft feature plan to wait months if not years for a new OS or service pack. Only switch to a new CCS version if it doesn't support your PIC. Look at the errata before choosing a new PIC chip. I still remember the hair pulling from the 18F8720 and the need to put a NOP in the code when it crossed the half way point of its program memory. This universe is as big as it is so it can contain the probability of the events you are experiencing.

[asmallri]

[scottc]

Bill,

If your files are on a USB drive. Copy them to harddisk first.
Its highly possible that your problem is related to I/O on
the drive your reading the files from.

Can you explain the sequence of events that are producing the error.
Also what version of ccsload are you using.

Thanks Scott

[ckielstra]

Just because it is not mentioned before, but v4.071 is not the best compiler release to do commercial development with. This was one of the first v4.xxx revisions that produced more or less working code but many bugs have been solved since then. I don't know about the stability of the most recent version v4.112 but I'd recommend to upgrade to at least one of the v4.09x versions.

At the CCS download site you can see a list of changes to each compiler version. Be advised that experience has learned there are way more bugs fixed than listed here.

The CCS compiler has a less 'professional' feeling than what I'm used to from other compilers, like Green Hills. But hey, this compiler is way cheaper than the competition so I guess we get what we pay for. The good things about the CCS compiler is that it generates very efficient code and is easy to use because it has abstraction functions for almost all the hardware. In a High Tech or Microchip compiler you have to fiddle with configuration bits and manually do the variable memory mapping, ugghhh.

The best reason for me sticking with the CCS compiler is this support forum.

[temtronic]

Others have already offered great suggestions...
For me, I have two 'clones' as engineering PCs(same MB/HD/OS,etc). Both do NOT have Internet access, minimal OS setup. No 'blue screens of death', run faster.etc. I have a KVM unit between the two and a peer-to-peer cable for transferring data for backup. Also have small flashdrives for local backup.
I use the Picstart Plus programmer for local burning,never had a problem with any series of chips.
This PC setup cost me less than $500. Great piece of mind and reliable.
With respect to the CCS C compiler, I've used it for almost 20 years(sigh,time flies..) and sure it has quirks but it's a tremendous value when you factor in this forum as well as the examples and drivers,etc.
If you want to 'jump ship' and go to another complier, go ahead or write your own (neither is easy !)
When Motorola wouldn't send me 10,000 pieces of the 68HC11 (I wasn't on the 'list'), I switched to PICs. Although single sourced, NEVER had a bad PIC, always in stock, easy to upgrade and once I found the CCS compiler, self taught myself C. OK, my code may not be pretty but it does work.

[Bill Havins]

Thanks to all for the thoughts. Excellent suggestions! Today I am going to stop and "inventory" where things are (i.e., software, PCs, programmers, etc.). I'll consider how to work these suggestions into our situation.

Bill

[Bill Havins]

Well, I appear to have corrected at least some of my problem. CCSLoad will now load my PIC18F2321 files and "see" them as "good". The configuration bits now show up in the CCSLoad "File > Configuration/ID" table and are correct.

It took cleaning all of the CCS software (everything!) off of my hard disk. Then I used System Restore to take Windows XP back to its status in June. I then began to re-install all of the deleted components (including Windows Updates) and, finally, the CCS software.

What a bunch of hooie!

I'll see if my boards will program tomorrow. Now I'm going to go fire up my antique Moto Guzzi and go for a long slow ride!

Thank you for all of your suggestions. I'll get a Microchip programmer ordered tomorrow "just in case".

Bill

[Bill Havins]

I received a reply from CCS this morning. The response indicated that CCSLoad.exe must be in a directory other than that of the compiler.

Soooo... I created another folder in my Programs directory and installed CCSLoad.exe there. CCSLoad read my files and described them as "Good" files; configuration bits were read correctly. Things worked well; I was able to re-program a board using the Mach-X and the board performed as expected.

Thanks CCS for geting back to me! Now, if you would please begin to document, Document, DOCUMENT so users could avoid getting pulled off into these alleys (where they get mugged and left for dead!) it would help even more.

Bill

[Wayne_]

[Mike]

Yesterday I ran into the dreaded access violation as well but I know the cause and solution. I think this is continuous cause of problems for users.

Here is what I did, I work a program to modify a few values in the EEPROM address range in hex file. However, the CRC needs to be updated and wasn't. After spending 1/2 hour I gave up looking to the method of generating a new value. So I left it not matching with the changes. I loaded the modified hex file and CCSLoad started generating many Access Violations. A new Access Violation window pops up at the rate which is similar to the ICD-U64 target voltage check under the Diagnostic tab.

After you shut down and reboot the computer and start CCSLoad again, it will either crash and continue to generate Access Violations. In essence,
once CCSLoad points to a bad file, it will continue to do so.

To fix it I had to
1) Uninstall CCSload.
2) Keep ICD-U64/ICD-U40 plugged in. If it isn't go ahead and plug it in.
I'm assuming USB and Windows XP.
3) Go to System Properties -> Device Manager -> Universal Serial Bus
controllers and delete CCS ICD-U64 entry.
4) Now unplug ICD-U64 from the USB.
5) Run Ccleaner to clear out unused Reg. Entries.
5) Reboot.
6) Install ICD-U64 drivers.
7) Install CCSload