View previous topic :: View next topic |
Author |
Message |
Bill Havins
Joined: 20 Nov 2006 Posts: 14 Location: Texas
|
Five Year's Work Held Up By CCSLoad.exe - UPDATE! |
Posted: Sat Sep 18, 2010 2:23 pm |
|
|
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
Last edited by Bill Havins on Mon Sep 20, 2010 8:47 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Sep 18, 2010 3:04 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Sat Sep 18, 2010 7:06 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Bill Havins
Joined: 20 Nov 2006 Posts: 14 Location: Texas
|
|
Posted: Sat Sep 18, 2010 7:38 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Bill Havins
Joined: 20 Nov 2006 Posts: 14 Location: Texas
|
|
Posted: Sat Sep 18, 2010 7:48 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Sat Sep 18, 2010 11:25 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: Five Year's Work Held Up By CCSLoad.exe - Time To Switch |
Posted: Sun Sep 19, 2010 12:08 am |
|
|
Bill Havins wrote: |
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 also suggest moving to a different programmer. I have used several of Microchips from PICKits, to ICD2, to RealIce. I would not recommend ICD2 for a new purchase as it is slower than an ICD3 and no longer supports all products. I am very happy with the RealIce.
The grass is always greener on the other side of the fence. I have used Microchips and CCS compilers for several years now. I have on going end customer support challenges today with the Microchip C30 compiler because Microchip periodically change the syntax of their linker scripts. This means that after selling drivers I often get support calls, months after selling the driver, as customer use the driver with the next incremental version of the compiler - a real pain and a money loser.
Moving between different PIC families using Microchip compilers is also a non trivial exercise as they lack consistency between product families. To be fair I have given up on the CCS PCD compiler after wasting lots of time trying to port working code to this compiler due to bugs in the compiler. I bought PCD over a year ago to support a specific application and after a year, was not able to get a stable version good enough to complete the task and, as a result, I have not renewed maintenance on this compiler.
If you are developing for the PIC18 family then I believe the CCS PCH compiler is a good solution and will enable you to get code to market fast than the C18 compiler. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
scottc
Joined: 16 Aug 2010 Posts: 95
|
|
Posted: Sun Sep 19, 2010 1:11 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Sun Sep 19, 2010 2:59 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Sun Sep 19, 2010 5:46 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Bill Havins
Joined: 20 Nov 2006 Posts: 14 Location: Texas
|
|
Posted: Sun Sep 19, 2010 8:17 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Bill Havins
Joined: 20 Nov 2006 Posts: 14 Location: Texas
|
|
Posted: Sun Sep 19, 2010 2:37 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Bill Havins
Joined: 20 Nov 2006 Posts: 14 Location: Texas
|
|
Posted: Mon Sep 20, 2010 9:06 am |
|
|
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
Last edited by Bill Havins on Mon Sep 20, 2010 10:26 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
Wayne_
Joined: 10 Oct 2007 Posts: 681
|
|
Posted: Mon Sep 20, 2010 9:28 am |
|
|
Bill Havins wrote: | 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.
Bill |
Well that might explain it then, I have always had issues with the CCS programmer, ccsload as well as the old one. Mainly when switching between using the IDE to program a chip and using ccsload standalone!
Thank you for sharing this with us ![Smile](images/smiles/icon_smile.gif) |
|
![](templates/subSilver/images/spacer.gif) |
Mike
Joined: 16 Jul 2009 Posts: 4
|
CCSLoad Access Violation |
Posted: Fri Dec 10, 2010 10:14 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|