1. Home
  2. Electronics Design
  3. A strange PIC problem

A strange PIC problem

I was writing a driver for a graphics LCD for PIC 18F14K22. That went OK: ftp://panteltje.com/pub/graphics_lcd_driver_img_1_1861.jpg

But I wrote it is asm, so it needed a lot of typing, even more so because this display CD-19-HG1286418C has a strange driver chip S6B0108 that comes from a planet where x is vertical and y horizontal, and people write from to top to bottom probably on the right side towards the left... and the display uses 2 driver chips for each half... so it took a lot of key hitting: ftp://panteltje.com/pub/key_soup_img_1853.jpg to get it to do things the European way, that I then reversed with x0, y0 at bottom left as that is easier for what I want to do.

But now about the problem. I did all this with the 8 MHz PIC internal clock, and it works perfectly. Activated the internal 4 x PLL, so to 64 MHz internal clock, results in 16MHz processor clock.

Display stopped working, only display on and display off command still worked,. Well, added the usual delay between I/O operations, but this time, even with seconds delay, no effect. Finally grabbed the scope, and looked at the PIC pins. Now this is strange:

bsf PORTA,1 ; pin 18 LCD_C_D bcf PORTA,5 ; pin 2 LCD_WR

should set pin 18, and then clear pin 2

This is what happens at 16 MHz clock. But at 64 MHz clock after the first instruction pin 18 does not go high,

|||||||||||||||||||||||||||||||||||||| porta, 1 _________||||||||||||||||||||||||||||||||||||||_____________________ pin

18 16 MHz RF

----------------------------------------------- | porta, 5 |_________________________ pin

2

^ ^ | | bsf PORTA,1 bcf PORTA,5

but start outputting 16 MHz until the second instruction, and then goes to _zero_, the second instruction operates normally and clears pin 2.

It seems the PIC internal output FF for pin 18 does not toggle, but just follows the internal clock.

I suspected a load problem and added an emitter follower because it drives a 20 cm long flat cable to the LCD. pin 18 is also the PGC (program clock) for in circuit programming, but the effect persists with pin 18 loaded with with only about 1k to ground.

I think the PIC is out of spec here, but not sure if I am allowed to use it with

64 MHz on internal oscillator. Went back to 16 MHz clock, will work with that for now, will have to get some more PICs too to see if it is only this one.... FYI.
Reply to
Jan Panteltje
Loading thread data ...

rizontal,

the left...

key hitting:

at bottom left as

6MHz processor clock.

rked,.

D_WR

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0porta, 1

=A0 =A0 =A0pin 18

=A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 porta, 5 =A0

=A0 =A0 =A0 =A0 =A0 =A0|_________________________ =A0 pin =A02

=A0 =A0 =A0 =A0 =A0^

=A0 =A0 =A0 =A0 =A0|

=A0 =A0 =A0bcf PORTA,5 =A0 =A0

o _zero_,

follows the internal clock.

s a 20 cm long flat cable to the LCD.

e effect persists with

it with 64 MHz on internal oscillator.

Could this be a read-modify-write problem? You have one r-m-w operation immediately followed by another. Is that allowed in PIC- land? Even if it is, it ain't working here. Or maybe the RMW timing is marginal & fails at 64MHz. MCUs often have bugs or caveats here.

What happens if you add a few NOPs between the two operations, or read the port into W, twiddle the bits, then MOVWF back to the port?

-- Cheers, James Arthur

Reply to
dagmargoodboat

horizontal,

left...

hitting:

bottom left as

processor clock.

What happens at 32MHz? The datasheet is ambiguous about operation at

64MHz with one part saying yes and the other saying the PLLEN is only valid for an 8MHz HFINTOSC (see page 22 OSCTUNE Reg 2-3.)

porta, 1

pin 18

porta, 5

pin 2

_zero_,

follows the internal clock.

You could always low pass filter it, provided it doesn't have to change too fast (or pulse stretch it slightly).

with 64 MHz on internal oscillator.

Try it at 32MHz and/or with an external 64MHz xtal.

Regards, Martin Brown

Reply to
Martin Brown

On a sunny day (Fri, 12 Mar 2010 13:51:31 +0000) it happened Martin Brown wrote in :

Exactly, I tried all clock speeds, and it only works at 16 MHz or lower. I think this PIC is not able to do I/O that fast in a reliable way :-)

follows the internal clock.

Yes, well, I like simple circuits, adding all sort of stuff to compensate for hardware errors in a processor is not nice.

What I *can* do is dynamically change clock speed, that is change to 16 MHz (PLL off) when doing I/O to the LCD, and to 64 MHz when doing math, but then I also have to switch baudrate, as it goes up and down a factor 4 then too, just tried that, seems possible. Dunno what it does to the processing of the code, have to try that :-) Also I need the 64 MHz for fast ADC...

Reply to
Jan Panteltje

On a sunny day (Fri, 12 Mar 2010 05:16:00 -0800 (PST)) it happened snipped-for-privacy@yahoo.com wrote in :

Yes I think it is at the edge of what PIC can do...

I even tried a 100 mS delay loop after EACH I?O related instruction... No difference.

Reply to
Jan Panteltje

You should be using a shadow register.

Reply to
anthony fremont

horizontal,

left...

hitting:

bottom left as

processor clock.

Umm... why in the world would you do a Read-Modify-Write instruction on a PIC PORT when you are trying to toggle at high speed?

Change PORTA to LATA and see what happens.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

What voltage are you running at? VCO range is 20mhz at 1.8 to 3.0v, and 64mhz for 3.0 to 5.0v

Cheers

Reply to
Martin Riddle

On a sunny day (Fri, 12 Mar 2010 23:14:59 -0500) it happened Spehro Pefhany wrote in :

horizontal,

left...

hitting:

bottom left as

processor clock.

Thank you, will try that. WTF should read modify right not work at 64 MHz?

Reply to
Jan Panteltje

On a sunny day (Fri, 12 Mar 2010 23:50:01 -0500) it happened "Martin Riddle" wrote in : What voltage are you running at?

5.18V
Reply to
Jan Panteltje

horizontal,

left...

hitting:

bottom left as

processor clock.

worked,.

Because the above code is marginal at 20MHz at best, silly wabbit.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

On a sunny day (Fri, 12 Mar 2010 23:14:59 -0500) it happened Spehro Pefhany wrote in :

Thank you, will try that. ?WTF should read modify right not work at 64 MHz?

OK, I did not expect it to help, but your suggestion worked first time. Running 64 MHz now.

Reply to
Jan Panteltje

On a sunny day (Sat, 13 Mar 2010 10:19:30 -0500) it happened Spehro Pefhany wrote in :

Wabbit? Where in the specs from Microflip is it stated that you cannot use bcf and bsf on a port at > 20MHz" I will tell you: NOWHERE.

So they just took a chip mask that just worked at 16 MHz, and added a PLL for 4 x clock, and left the rest as it. They probably noted not even an I/O port worked reliably at 64 MHz, so they added LATA LATB LATC to flip those flipflops directly, but kept it quiet and out of the datasheet so not to chase people away, as usually code ported from for example the 16F 'equivalent' would have tons of those instructions.

So, I could give the chip back with the statement 'money back please'. Maybe the same idiot worked on it that did the PIC-KID 3?

Well I am used to work around bugs, it is 1:29 at night there and my stuff works. I'd rather concentrate on my code then on Micro-chip bugs.

I think it is not the only bug either.

Reply to
Jan Panteltje

I would suggest posting this on the Microchip Forum as well as submitting a product defect ticket. They are usually fairly responsive to tickets, but lately it seems that they are more lax, and those who respond have a narrow focus and limited attention span, so you need to get right to the point and explain the problem in as few words as possible.

It seems reasonable that a BSF instruction might have a problem for an IO pin, compared to a standard memory register, because it must (in one cycle) read, modify, and write the modified byte to the port. This will certainly take longer than an internal file register. I am surprised that the code does not automatically use the LAT register, but there may be compatibility issues. The 12F and 16F chips do not have the LAT registers, but they also probably do not have a 64MHz option.

Thanks for keeping us informed of anomalies such as this. It may prove valuable information for future projects.

Paul

Reply to
Paul E. Schoen

Interesting trivia: From the datasheet in PORTA:

"Reading the PORTA register reads the status of the pins, whereas writing to it, will write to the PORT latch."

It does not say this about the B or C ports. But you are using Port A, as I recall...

Hmmmmm

Paul

Reply to
Paul E. Schoen

But the problem is that a bitwise operation must first read something, and in the case of BTSF PORTA,n it probably reads the actual port, while BTSF LATA,n reads the memory in LATA, which is a solid digital value. PORTA itself is essentially analog, and the internal logic takes a sample which may not be a good logic level.

Paul

Reply to
Paul E. Schoen

Silly wabbit. PICs may not be for you. ;-)

on a port at > 20MHz"

Because you "can", but it's just not really a very useful thing to do. Which you see when you work through the setup time/hold time for the Q-states to do a RMW.

The LATx registers have been in every PIC18C/18F from the beginning. It works around a deficiency in the PIC16 architecture, which dates back to the 1970s or thereabouts.

those instructions.

Writing solid code takes a little more effort with the 16F, for example by using a shadow register, which is a common technique.

works.

It isn't a "bug", more of a quirk. But there are usually plenty of real errata to go around.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

On a sunny day (Sat, 13 Mar 2010 21:08:07 -0500) it happened Spehro Pefhany wrote in :

Na, it is a bug. The PIC outputs 16 MHz clock when doing a bsf PORTA,X, and then when an other bsf instruction happens to port a, it *clears* output bit x.

The 16 MHz clock should not be there, there is no 4 MHz clock when running without the PLL.

This is my first PIC 18 experience, so I did read the data sheet first, and found this on page 80, the data sheet is really funny: EXAMPLE 8-1: INITIALIZING PORTA CLRF PORTA ; Initialize PORTA by ; clearing output ; data latches CLRF LATA ; Alternate method

Reply to
Jan Panteltje

without the PLL.

found this on page 80,

and no as 2 different pieces of code,

the first method, PORTA.

steering wheel,

turns.

mph, so you need to use your hands.

electrical system drops

SYSTEM. I wouldn't worry too much about it. If you ever had worked on the 6502 processors, I have a pile of old books that talk about the Jump indirect (Vectoring address) that clearly states, you can store the vector address anywhere how ever, it does not work if you do a page boundary overlap.. You get an incorrect address and no, the assembler or assemblers I've used, never flagged this as an error nor does any books I've ever referenced state this.

I can only assume that it was intended by design to happen and maybe some where along the line, it didn't or, got screwed up later down the road. Years ago, I wrote my own custom 6502 assembler and one of the things I did, was to have it test for the page boundary error for a jmp index instruction.! If it was to take place, I inserted a NOP instruction.

Reply to
Jamie

Am There is a bug in the 6502. When the indirect address crosses a page boundary the 6502 does not add the carry to calculate the address of the high byte. i.e. JMP (&19FF) will use the contents of &19FF and &1900 for the JMP address.

formatting link

The fact that almost every computer programmer of my generation in the UK owned a copy of that book probably accounts for it having been common knowledge.

The situation in other circles may have been different. The other

6502-based micros of that era (Commodore, Apple, Sinclair) weren't so accomodating of technical users, and typically didn't come with an assembler or a circuit diagram as standard.
Reply to
Nobody

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.