Problems with the PIC18F25K22

[Aresby]

I'm using Swordfish to program an Amicus18 board (via a PicKit2). All good.

I've now swapped out the PIC18F25K20 for the 'wide-voltage' version, 18F25K22.

After updating the PicKit2 definition file it all appears to write to the PIC chip just fine - and a verification of the burned code supports this. I can burn the chip using PicKit2 directly, or via Swordfish.

However, whether I run the new chip on 3.3v or 5v nothing happens. (Aside: my understanding is that this new chip would run from a wide voltage supply, 1.8v to 5.5v, but 5v is OK if I have to switch permanently to that).

I've resorted to just compiling the simple flashing LED SW sample program but it does nothing until I touch the chip pins (just by handling the board) at which point the LED lights up - and stays lit up, no flashing.

So at this point I can't seem to use this chip - although SW fully supports it, I believe.

I've scoured both this forum and the myAmicus one on details of what needs to be initialised differently to the original chip but have drawn a blank. I understand that internally the chips are a bit different but I would have expected the code to run if SW compiles it OK!

Any ideas anyone? Please?

[Jerry Messina]

The 25K22 should work fine at either 3V3 or 5V. It's not 5V tolerant at 3V3, though.

For the K22 and the SE compiler, make sure you have the updated SetAllDigital() routines from http://www.sfcompiler.co.uk/wiki/pmwiki ... tDigitalIO

Also, double check the CONFIG and osc setup. The 18F25K22.bas device include file has different defaults than the K20 does... there's no default osc setup for the K22.

[Aresby]

Thanks for at least giving me (now a master detective) a vital clue in this 18F25K22 whodunnit detective saga.

I compared the two "include" files and found a number of CONFIG differences. (I recommend the free Notepad++ for this).

Finally, I found a post on this very forum that I took en-masse (I'll look at the individual settings tomorrow) and it all sprang into life.

Here's the code I used (some of these settings are already in the 18F25k22 include of course:

Code: Select all

Device = 18F25K22 
Clock =  64 

Config 
   FOSC = HSHP ,'HS oscillator (high power > 16 MHz) 
   PLLCFG = On ,'Oscillator used directly 
   PRICLKEN = Off ,'Primary clock can be disabled by software 
   FCMEN = Off ,'Fail-Safe Clock Monitor disabled 
   IESO = Off ,'Oscillator Switchover mode disabled 
   PWRTEN = Off ,'Power up timer disabled 
   BOREN = Off ,'Brown-out Reset disabled in hardware and software 
   BORV = 285 ,'VBOR set to 2.85 V nominal 
   WDTEN = Off ,'Watch dog timer is always disabled. SWDTEN has no effect. 
   WDTPS = 256 ,'1:256 
   PBADEN = Off ,'PORTB<5:0> pins are configured as digital I/O on Reset 
   HFOFST = Off ,'HFINTOSC output and ready status are delayed by the oscillator stable status 
   MCLRE = EXTMCLR ,'MCLR pin enabled, RE3 input pin disabled 
   STVREN = On ,'Stack full/underflow will cause Reset 
   LVP = On ,'Single-Supply ICSP enabled if MCLRE is also 1 
   XINST = Off ,'Instruction set extension and Indexed Addressing mode disabled (Legacy mode) 
   Debug = Off'Disabled 

Once point to note is that instead of putting CLOCK 16 (as I did with the 18F25K20) you MUST now put CLOCK 64 otherwise it all runs too fast (in this example my LED was blinking 2-3 times a second instead of once per second, which is how I found out.

When I've figured out the essential missing pieces from the CONFIG (why did David do this?) I may just put them back in the 18F25K22 include file unless you can tell me why they should not be!

And it all runs at 3.3 just fine.

However, if I now put 5v on the input pins (to read an analog or digital value) will the chip burn out? Is that what you mean by "tolerant"?

[Jerry Messina]

However, if I now put 5v on the input pins (to read an analog or digital value) will the chip burn out? Is that what you mean by "tolerant"?

At the risk of starting a religious war, yes, that's what I meant.

This can vary from chip to chip (and pin to pin), but in general if you look at the 'Absolute Maximum Ratings' section in the electrical characteristics, you'll find most pins spec'd something like:

Voltage on any pin with respect to VSS (except VDD, and MCLR) ...... -0.3V to (VDD + 0.3V)

That is, the pin voltage can't exceed whatever you're using for VDD except by a diode drop. That's because of the input ESD clamp diodes on the pin.

According to some if you limit the current into the pin by using a resistor that's good enough. Microchip themselves have app notes showing exactly this. Trouble is, if you read some of the OTHER app notes they produce (like TB3013) you find out why this perhaps isn't such a good idea.

But hey, I'm flexible. My stock response these days is "It's your chip, do whatever you want with it".

[RKP]

Aresby,

I believe you found the problem when you got it to run with the code in your second post. Try adding this to your original code

Code: Select all

Config 
   FOSC = HSMP

It should make it work??

It appears there is no default Config "FOSC" setting in the 18K25K22.bas file.

According to the data sheet this PIC defaults to 0101 = EC oscillator (high power, >16 MHz). The PIC is looking for a clock source not a crystal, which why it did not run.
If adding the above works you can add this setting to the 18F25K22.bas file under the default section if you like.

RKP

[Aresby]

Thanks for the replies.

Regarding the 5v issue, I have (inadvertently) applied 5v to an input pin of an 18F25K20 with no ill effects (yet). I did read about the max voltage wrt the supplied Vdd but as you say Microchip themselves even do this. But as I'm cautious I'll keep to the specified limits. My chip it might be but they all cost money!

And that's the main reason I'm swapping to an 18F25K22; not only will it run at 5v (which is what all my peripherals seem to prefer) I can program it on the Amicus board and it will continue to run without code changes once I put it out into the wild interfaced to 5v stuff. I've modified the Amicus board with a jumper so I can use 3.3 or 5v.

There are other advantages that I'm discovering (mainly by reading the 18F25k22 include file) such as 2 USARTs et al. Not sure how I'll take advantage of all these improvement but it's nice to have. I'm surprised that Microchip haven't dropped the 18F25K20 as the K22 seems to be everything the K20 is and more (the 5v tolerance being its main selling point to me).

@RKP: Regarding the (missing) FOSC entry, that's what Jerry hinted at and what I suspect was the sole missing entry. I will certainly add it back to the include file if I decide I will always run with a crystal (highly likely).

However, this has once again highlighted to me that programming a PIC chip (even with Swordfish) is NOT the same as the high level programming I do during the day when all such things are unheard of (and taken care of). We're much closer to the hardware with PICs (which is the whole point, I suppose).

I will take some time to read the docs on fuses etc (the Proton compiler documentation has some interesting stuff on this).

Thanks again, guys.

[Aresby]

Flushed with my recent wiki article on using Dropbox with Swordfish, I'm very seriously considering another article called something like "Clock settings for the PIC18F25K22 using Swordfish and the Amicus18 board". OK, it's a working title.

Basically, as an absolute (but keen) PIC beginner I'm thinking what I would have liked to have seen as an article to get me going.

Having taken general advice about reading the PIC Datasheet (all 576 pages of it) I've read the bit about clocking this chip, re-read it, cogitated, experimented, hit a few brick walls, and said some rude words before finally getting the Eureka moment (or two).

Reading about terms such as FOSC, OSCCON and special function registers is all very well but they need to be put into some kind of context.

I believe I've now "cracked" the very basics of clocking this chip from either the external 16MHz crystal on the Amicus board as well as using the internal high speed oscillator (at varying speeds). I've also managed to switch between the two as the test program was running, that is, under program control. More importantly, I've cracked the key to reading the Datasheet so FOSC<3:0> is now meaningful to me!

If only I had known what I now know a week ago! As I mentioned to Jerry, I am one of the sad people who really do RTFM because that is where the knowledge resides - but sometimes a nudge in the right direction (or a beginners' article) can work wonders too.

David/Jerry/anyone? Worth doing? Perhaps it really would help other beginners treading this path...

[Jerry Messina]

As you found out, setting up the osc on some of these newer chips can be a real task.

I suppose it shouldn't be a real surprise since it takes up 20 pages or so in the datasheet, but it is really tricky to figure out where everything is in Mchip's explanations.

I always have to sit there with the block diagram of the osc module and the various registers and try to follow the bits through, so any help/addtl info would go a long way to getting someone up to speed, I'm sure.

[Senacharim]

Congrats on getting started!

Do please remember this forum when you need help/advice--some of us check here at least 5 days a week.

[Aresby]

Thanks for the welcome, Senarcharim.

I've made a start on the "Absolute Beginners' Guide to understanding Clocking Using Swordfish with the Amicus18 board and 18F25K22 PIC" (I'm still working on that title).

I was distracted, however, by building a XINO basic board last night to contain said 18F25K22 chip. I had to modify it to contain a PicKit2 programming socket. But it worked so that's something else to tell other potential 18F25K22 users about.

Breakout boards or shields (of the Arduino type) are expensive and can easily make the cost of a simple project outweigh its benefits.

Up till now I've used PICAXE 08M2 boards (cheap, simple, with a protoyping area on board) but now I'm in the big boys' class I shall have to be more inventive to keep costs down!

My brother gets his PCB boards made in China at excellent cost. Low initial volumes too. There are several places where bespoke boards can be sourced but sometimes you have to wait until a large PCB sheet is filled with designs from other customers before they start work.

Anyway, hopefully I'll have that beginners' article about clocking within a week or so. If I don't do whilst still at the beginner stage myself it will assume too much knowledge.

[blackcattech]

I must admit I was thinking that something along the same lines would be a great benefit to many PIC users as a reference.

I've documented in the forum just last week my struggle at getting the timer 1 oscillator running on the 18F14K22. The datasheet was no help as nowhere did it say you needed to disable pullups before using the oscillator.

To be honest, the more recent Microchip datasheets are very poor IMO - they have just tagged on the new features without any explanation as to how they interact with what is already on there. They really are due for a re-write from the ground up, either that or Microchip create a general reference to each module then the datasheet only needs to detail the variations on a specific chip.

Didn't Microchip start a Wiki at one point? I can't find it on their website now but surely that would be a good place to post snippets like this, just simple 'how to use peripheral x'.

[Aresby]

I've finally put together this, as yet, unverified article.

Anyone care to verify it for technical accuracy, typos, bits that confuse rather than clarify?

http://www.sfcompiler.co.uk/wiki/pmwiki ... hSwordfish

I'm happy to take all constructive feedback!

[Senacharim]

Inaccuracies I noted:

Swordfish's 18F25K22 device file does not set the primary oscillator for you; it is expected that you, the developer, will configure the chip to use either an external or internal oscillator. Without this, you can program the chip but the chip will not start running as no clock is pushing it along. It will just sit there, immobile, doing nothing. You’ve put the car in gear but haven’t started the engine.

Every PIC I've ever worked with has within it an internal ~31kHz oscillator which it defaults to. This is the same one the internal Timer registers are clocked from by default. In the event of external osc failure, it also defaults to this.

You can test this--write a program which toggles the on/off of an LED every, say, 1 millisecond. Then, ground out the external oscillator (I use thru-hole, so touching the pins with one's finger does it for me...) and watch the blink speed of the LED slow way down, but not actually stop.

When written down, the 8 bits in a byte are represented like this:

Bit No: 7 6 5 4 3 2 1 0

Example value: 0 1 0 0 1 0 1 1

Perhaps one should also note the difference between Big Endian and Little Endian bit arrangements... or not. Not sure for a beginner article.

[David Barker]

Many thanks for the contribution to the WIKI - it's nice to see someone learning and sharing with others...

[Senacharim]

While I'm thinking on it...
There was something else--getting the PLL to work is finicky. It must be done just right, and if it doesn't go then you'll be left with your default just clock, rather than your desired 4x clock.

When using PLL, the SCS<1:0> bits (System Clock Select) in the OSCCON must both be set to zero.

I bring this up because it threw me off of using PLL for a long long time--worth noting, as it might save somebody many sleepless nights of heartache trying to figure out why their PLL isn't working.