MPLAB 5.00 and the HiTech C V7.83 behaves for me exactly as you describe below. It seems clear that MPLAB cannot decode some of the debug information provided by the linker. I've gotten an acknowledgement of this problem from HiTech, but so far HiTech and MicroChip seem to be simply pointing fingers at each other. It would be real pleasant if MicroChip would wake up and understand that they are in the chip business so supporting foreign compiler makers is in their best interest. I use a PicMaster. It is a little clumsy since the debug info is not perfectly understood, but I've gotten used to how it works. You can still zero in on non-working code pretty easily. Breakpoints are put in the correct place. I haven't seen the problem where the hex code is not produced correctly. I have seen a perhaps related problem. Occasionally after making my project (11 modules plus linking some libraries), MPLAB freezes. In Win95 I have to use ctrl-alt-del to get to the task manager to kill MPLAB. Then I must delete some (unknown which) intermediate files. I simply delete all of them - .objs, hex. microchi. -- all the intermediate files. I then restart MPLAB (no need to reboot), change one line in a module (insert a blank line for instance), re-make and everything works. "Make" is a euphemism here, as MPLAB always compiles every module. I've always considered this freezing to be a MPLAB bug, but I suppose it could be the HiTech linker making something that MPLAB doesn't understand. This usually happens after I've been editing in a DOS window. In any case, MPLAB should produce an error message rather than freezing. So even if HiTech has a problem, Microchip has one also. The same thing goes for the debug info. If MPLAB can't decode the info that HiTech supplies, it should say so. While we are on the subject of MPLAB, why do you suppose that MPLAB breaks _after_ the line with the breakpoint? Other debuggers I've used always broke (break?) before the breakpoint. Do you suppose there is some technical reason? Or maybe the first version of MPLAB did it wrong and its been like that ever since. I'll add one more comment. Someone who is unfamiliar with the HiTech compiler might read this and decide to use the Microchip one. Be very careful here. I tried to port my application to the Microchip environment and spent _way_ too much time trying to make it work. I finally tried the HiTech compiler and it was _easy_. Sure, there are a few problems, but on the whole it works GREAT. I have found NO problems that will prevent me from continuing. Regards, Jim Ham At 09:33 AM 3/25/99 -0800, you wrote: >I have seen similar problems with this version of Hi-Tech C. I have a large >program that exhibits the same symptoms which can be fix be removing a couple of >comment lines at the beginning of one of the modules, NO CODE WAS CHANGED!. > >In addition I have noticed another issue with this version of the compiler when >used with MPLAB. With previous versions, single stepping through a program >generally caused the MPLAB to step through one C statement at a time, which >generally corresponded with the execution of several assembly instructions. Now >single stepping seems to cause execution of a single assembly instruction, with >the further problem of confusion by MPLAB of which C source line corresponds to >the assembly instruction being executed. This results in each single step >causing the display to jump between source file windows to unrelated C-source >statements. This occurs in both MPLAB 3.4 and 4.0, both of which worked >corrected with previous versions of the compiler. Has anyone else experienced >this same problem with version 7.83 and MPLAB? > >Roy Souther wrote: >> .... >> >> New information. >> I have a structure that I can not use if it is the first structure, when I >> declare another sturct first then the one I want to use works, I just can >> not use the first structure that I declare. Also I have an unsigned char >> variable that I can not use called curValue, and if I rename it any thing >> like curVxxxalue works fine. What is up with that. I am working on removing >> the code that I am not allowed to show to people and I will send the striped >> down version of the code, probably a main and a few variables just to see if >> anyone else gets this problem when they compile it. I will send in about 2 >> hours. Thanks. >> >> >From e-mail: More: Hi-Tech 7.83 and 17c756 bug? >> I found the problem and don't know how to fix it. I have three struct's in >> the code. One of them, if I rem it out it will compile properly and run >> great. If I add the line back in the compiler says that it compiles ok but I >> don't get a memory detail and the chip does not run. >> >> >From e-mail: Hi-Tech 7.83 and 17c756 bug? >> I am using the HT-Soft 7.83 C compiler and the PIC17c756 chips. The code >> compiles ok, I think. The problem I am having is with large files, it does >> not return any memory usage data. I use the same command line on a small app >> and it will return the data but not on large files, why is that? >> >>... > > Jim Ham, Porcine Associates (650)326-2669 fax(650)326-1071 "http://www.porcine.com"