UPDATE: PCD v4.141 Major Issue Warning

[newguy]

Just a warning to anyone using PCD, the compiler is not issuing a warning or error when it encounters an undefined data type in the argument list of a function definition. I know that this problem was present as far back as 4.124, perhaps earlier.

I bought a prewritten driver and I couldn't get some aspects of it to work. This was perplexing because I had previously purchased the 8 bit (PCH) version of the same driver and it worked perfectly. Turns out that my problem was that I had missed copying the typedef of a pBYTE (as used in the driver) over to my project. What's troubling is that the compiler didn't have any problem compiling it, even though it wasn't defined.

I last tried to find the problem late last year and I had to abandon the search to deal with other matters. I just got some spare time to return to the issue and I finally found it late Friday.

Yes, CCS has been told of the issue.

[Ttelmah]

Have you got a minimal program that shows the problem?.
If I try to declare this just about any way I can think of, the compiler does correctly complain.
Now pBYTE, is a suspicious type since it a commonly used shorthand for 'pointer to byte'. Does it still not fail if you just change one character in the name?.
I'd be very suspicious that in fact you are being caught by something slightly 'deeper', with possibly a #defined expansion resulting in the line actually being interpreted as something completely different, and hence accepted, but for the wrong actual type....
It is always a real 'annoyance', that you can't look at how CCS 'sees' the code after macro expansions etc., since it'd make finding this type of problem much easier.

Best Wishes

[newguy]

The program that exhibits this behaviour is very large, and of course contains work related proprietary material. I've packaged up a version that shows the behaviour and sent it to CCS directly - they've responded already and are examining the fault.

pBYTE isn't used or defined anywhere in the program (well it wasn't - it is now). I've also done a search on every file included by the program, including the processor.h file, and other library CCS code. Nothing even closely spelled or with a different combination of lower & uppercase letters. It's the only instance of pBYTE anywhere in the project.

I do think it's a convergence issue where IF the code is at or above a certain size and/or IF the code targets a certain processor and/or IF the #case compiler directive is used and/or IF.....

It's interesting to note that v4.141 takes "forever" to compile this program. I say "forever" because the .hex file is generated quite quickly but the IDE takes a good 60-90 seconds to pop up the compilation report window (%RAM used, %ROM used, etc) and give focus back to the IDE. When I was tracing this fault, I would compile, CCS Load would quickly detect the new .hex, I'd program the target, test, and then I'd have to wait another 30 seconds (if not more) for the IDE to return focus so that I could tweak the code again & recompile.

The driver code that I bought is the SD card FAT driver from www.brushelectronics.com. I've been using this library on various projects since (I think) approximately 2007. It has always just worked. I purchased the PCD version of it since I'm now targeting a dsPIC33FJ256GP710A. In my haste to incorporate it into my project, I missed the typedef of pBYTE. Unfortunately the compiler didn't generate an error when I compiled and that started this long road. The author of the driver suggested that I revert to 4.124 because he knew for certain that it worked with that particular release. I did revert but I still couldn't get it to run. He then asked about the hardware, pullups, etc, but the layout is exactly the same as every other working SD card project I've developed, only with a 16 bit processor now, not an 8 bit. I probably wasted 2-3 weeks trying to find the problem and things got to the point that I had to drop it.

Thankfully it only took a day to find the root cause of the problem when I finally came back to it.

That said, I must declare that the SD card drivers available from Brush Electronics are well worth the $. They work "right out of the box" and save a lot of development headaches. I wouldn't hesitate to purchase any of his drivers in future.

[Ttelmah]

I can tell you exactly what causes that long delay.
Project Options.
Output files
Call Tree file

This is enabled by default, and you are lucky if it takes as little as 60 to 90 seconds!....

Turn it off, and compile time totals will drop to about 1/5th.

I use the Brush electronics SD driver as well. It is just so much less work than trying to support all the vagaries of SD/SDHC yourself.

Best Wishes

[newguy]

[Ttelmah]

It had got to the point where I though "what the beep, is the compiler up to for so long". So I went and watched the output directory in another window. Found it had finished generating everything except this file.
Big smile when I turned the option off....
Why it takes so long to generate this I don't know.

Best Wishes

[newguy]

FYI...

"The problem you reported has been fixed and will be in the next compiler release."

[FvM]

To supplement the missing example