Can't program >640 instructions to PIC18F47K40 w/ ICD-U64

[temtronic]

Have to ask , why did you choose a 'new' PIC for your product? Does it have something 'special' you actually need? I ask, cause I found out 2 decades ago, it's better to use an 'old reliable' than the newest chip 'they' are promoting. Just look at Ecoboost engine failures, aluminum pickup boxes, etc. There's a great reason I still use 'old' PICs in DIPs IN sockets, though I have migrated to 18F46K22 series in recnet years.

As for the compiler not doing things quite right, please remember ther's a LOT of new PICs to 'figure' out,shoot they go more fuses than instructions, which leads me to 'when in trouble..use assembler', it ain't that tough to learn !

Jay

[NAR]

Just to give credit when credit is due, I actually called CCS support staff over the phone and they had a new CCSLoader firmware file emailed to me which solved programming issue the same exact day.

After few days of thinking the problem could be from new PCB as it uses an RC circuit for MCLR pin. But after tracing everything and checking all routes, decided to give CCS a call. Would have never thought it would be from the Loader. Silly me, i tried to upload a bigger test program from the start to tests all pins and that failed to load. Only after two days that i loaded a single LED code which loaded fine then we started to think the compiler/loader could be the issue.

Even after it was loading ok for any size program, some issues still showed up, another chat with CCS and they sent a new database file for this chip. Then they said they are releasing a new compiler/loader after the weekend and hope this resolves the rest of the issues.

I am fairly new to this so still learning how to read the .lst file to make sure everything is being put in the right place. (any link to read up and learn this?)

maybe one of the gurus here can write a stress-test code which tests every single register, load, read and verify. if its even useful.

[NAR]

@temtronic. Design needs 5 hardware EUSART with flows. Actually i have the entire functions already implemented but using 3 pcs 18F26K22 for 5 HW RS232, Bluetooth, I2C EEPROM, two SPI devices and three CCP pins needed. I am just prototyping if i can do the same with single 66K40. i am sure probably the code can be written with no need for HW RS232 support with a single chip that does not have 5 HW EUSART (but with more experienced programmer )

[mob1182]

Same here. I don't have the experience you and other top posters have as this is not my main focus at work. But I enjoy learning it and nobody else is here that can do this anymore. We were using a pic18f4685 for a project (don't ask me why, weren't even using CAN) and different customers were always requesting units with different interfaces for sending commands. Usually GPIB($$$) or RS232. Now they want to add a USB option and maybe RS485, and possibly all in one unit. So needed more UARTS and PIC18's are the only chips I've programmed before so wanted to stay with the same family, also easier to port. I also didn't realize how much "newer" these chips were until I started having these issues. And of course all this needs done in like 6-8 weeks lol.

One customer even wanted an I2C option! Off board! But hey customer gets what they want. Also trying to make a one size fits all solution for easier build.

I do feel a little silly using a 64pin pic but only utilizing half the pins. I thought about using hardware switching with gp pins to trigger interrupts and things like that with a 40pin and 2 uarts instead. Guess I'm trying to keep the BOM as small as possible, and board space too. I hope my design is not too "silly"

[Ttelmah]

If you do need to go to I2C off board, then use the P82B96. Have the other device supply it's power to the I2C. Some instrumentation units used the interface like this, and operate it at higher voltages (12v typically). It actually works remarkably well!.

On the chip here, it is interesting to find quite a few posts with memory initialisation issues on the 47K40, on the Microchip forums. I have a nasty suspicion there may be some as yet undocumented erratum 'yet to come' on this chip...

[newguy]

If you get some slower periods at work I'd recommend buying the PCD compiler and one of the CCS dsPIC evaluation boards and then start to get familiar with the higher end PICs. There's a lot to be said for sticking with what you know but honestly your project could be accomplished with a 16 bit PIC (pretty sure there are some dsPICs with 4 or more UARTs and some PIC24s as well). If you start playing with DMA in conjunction with UART (particularly transmit), then you'll see an order of magnitude (or two) jump in performance compared to an 18-series 8 bit PIC.

[asmboy]

of course - having
looked at the 24F family it became clear
that one also needs to fall in love with

** no ability to use a socket-ed part.
** few parts that operate above 3v
** ICP and attendant circuit issues<<<
** buying the highest cost version of CCS

[newguy]

Yes, but pros and cons need to be considered to see if the migration is worth it. I migrated to the 16 bit parts about 5 years ago for high end/high performance applications. I still use the 18-series for low cost/low performance. ...The right tool for the job, right?

[asmboy]

The other factor -so often overlooked is
how much does my design count on pic internal
peripheral support?

a BIGGIE !! since i depend on
* high speed parallel external ADCs of 16 bits (or more)
* high purity - high accuracy signal generators like the AD9833
* precision synchronous phase detectors
* scads of '573 or '595 latch expanders.
* external SRAM data store of 32K to 128K

The ONLY thing i generally need in the pic is a fast clock,
enough timers, lots of prog memory and enough eeprom
for system configuration and "last error" memory.
Hence the 18F46k22 and 18f47K40 are my goto devices.

[jeremiah]

We moved to the PIC24s about 10 years ago (give or take...getting old now...memory fading).

I've had a slightly different experience to asmboy's. We found plenty of socketable versions (most of the chips that have a 28 pin variant will have some sort of DIP based package) and both the Input Capture Port and the ICSP programming port have worked pretty flawlessly for us.

We like them because we can get extremely low power (100's nA to 1's uA average current draw) in an extremely small package (28 pin DFN/QFN typically). We don't really have the option of getting more space or more battery in most of our applications.

We tend to stay in the PIC24F/PIC24FJ series though. HJ, EP, and dsPICs are much higher performance and generally overkill (and out of spec) for our needs.

It's also nice that a lot of the ones we use tend to be really cheap priced (unless we used a cutting edge one for a particular application).

[mob1182]

@Ttelmah - I'll definitely look into the P82B96

@newguy - Yes good idea, I will push for this. It will be valuable to learn.

@Everyone else - Compiler update 5.067 came out today and a firmware update for the programmer. It appears to be programming fine now.
Thanks CCS!