CCS used in MPLAB and REAL ICE ?

[soonc]

Has anyone used the MicroChip REAL ICE with MPLAB and does it allow CCS
generated code to be debugged ?

I've been told that the REAL ICE does manage to switch PIC24 oscillators in debug mode.

[Ttelmah]

You can use CCS with any debugger that runs in MPLAB.

Now MPLAB has two completely different 'meanings'. The 'older' MPLAB (up to 8.92), and then MPLAB-X. This latter version, is unfortunately _very_ poor indeed. It is a pain to use, very difficult to get working, and generally unreliable. The older MPLAX 8.92, is quite a reasonable environment, but is no longer being updated for newer chips.

There are two fundamentally different ways you can work with either environment. You can add the plug-in for CCS support (on the later MPLAB, you have to follow quite a careful 'sequence' to get this to work properly), and then work completely in MPLAB, just using CCS as the compiler. Alternatively you can just compile outside, and load the .cof file. On the older MPLAB, this is easy, and works well, giving you the CCS 'environment' when typing etc., but then debugging in MPLAB. On the later MPLAB, this approach is not so easy, so you have to take more time and actually setup MPLAB to use CCS as the compiler. If you have to go this way, be prepared for just how bad the MPLAB-X environment is.
How Microchip are not losing sales at a huge rate to other chip alternatives, given just how poor their current environment is, I'll never understand....

I don't think I have ever managed to fully debug something successfully in MPLAB-X. I have just occasionally used the older MPLAB, quite well, but in general I have to repeat the comments from others, that it's far better to just use something like a serial port, or a pin as a digital 'pip' marker, and debug using real code in the real board.

I recently spent a few days getting a bulk MSD device working on the PIC. Given that the problems were all timing related, and of course any delay to stop and use a debugger would affect this, I don't think I could have debugged it yet, using a debugger. Instead I used a fast logic analyser, with the ability to watch USB transactions, added a fast single byte output using the hardware SPI, to flag 'where' in the code the chip was, without pausing (remember you just have to load the output register, and the hardware then sends the byte without costing any time), so I could synchronise what was happening on the USB, versus what the PIC was doing. After a very short while it became plain that the problems were being caused by the delays in re-loading the data buffer using the supplied CCS 'single buffer' drivers. Wrote ping pong drivers for endpoint1, and immediately fixed the problem.
If I'd been using a debugger, I would still be stuck....

[soonc]