A strange PIC problem

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View


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.





Re: A strange PIC problem


Quoted text here. Click to load it
 A0% A0% A0% A0% A0% A0% A0% A0% A0% A0%porta, 1
Quoted text here. Click to load it
A0% porta, 5 A0%
Quoted text here. Click to load it
 A0% A0% A0% A0% A0%^
Quoted text here. Click to load it
 A0% A0% A0% A0% A0%|
Quoted text here. Click to load it

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

Re: A strange PIC problem


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

Quoted text here. Click to load it

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


Quoted text here. Click to load it

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

Re: A strange PIC problem



You should be using a shadow register.

Re: A strange PIC problem


Quoted text here. Click to load it
horizontal,
Quoted text here. Click to load it
left...
Quoted text here. Click to load it
hitting:
Quoted text here. Click to load it
bottom left as
Quoted text here. Click to load it
processor clock.
Quoted text here. Click to load it

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.)
Quoted text here. Click to load it
porta, 1
Quoted text here. Click to load it
pin 18
Quoted text here. Click to load it
porta, 5  
Quoted text here. Click to load it
pin  2
Quoted text here. Click to load it
_zero_,
Quoted text here. Click to load it
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).

Quoted text here. Click to load it
with 64 MHz on internal oscillator.
Quoted text here. Click to load it

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

Regards,
Martin Brown

Re: A strange PIC problem


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

Quoted text here. Click to load it

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 :-)


Quoted text here. Click to load it
follows the internal clock.
Quoted text here. Click to load it


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...

Re: A strange PIC problem


On Thu, 11 Mar 2010 22:40:54 GMT, the renowned Jan Panteltje

Quoted text here. Click to load it
horizontal,
Quoted text here. Click to load it
left...
Quoted text here. Click to load it
hitting:
Quoted text here. Click to load it
bottom left as
Quoted text here. Click to load it
processor clock.
Quoted text here. Click to load it

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"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: A strange PIC problem


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

Quoted text here. Click to load it
horizontal,
Quoted text here. Click to load it
left...
Quoted text here. Click to load it
hitting:
Quoted text here. Click to load it
bottom left as
Quoted text here. Click to load it
processor clock.
Quoted text here. Click to load it

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

Re: A strange PIC problem


On Sat, 13 Mar 2010 13:15:15 GMT, the renowned Jan Panteltje

Quoted text here. Click to load it
horizontal,
Quoted text here. Click to load it
left...
Quoted text here. Click to load it
hitting:
Quoted text here. Click to load it
bottom left as
Quoted text here. Click to load it
processor clock.
Quoted text here. Click to load it
worked,.
Quoted text here. Click to load it

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"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: A strange PIC problem


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

Quoted text here. Click to load it

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.



Re: A strange PIC problem



Quoted text here. Click to load it

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


Re: A strange PIC problem



Quoted text here. Click to load it

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


Re: A strange PIC problem



Quoted text here. Click to load it

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


Re: A strange PIC problem


On Sun, 14 Mar 2010 00:31:05 GMT, the renowned Jan Panteltje

Quoted text here. Click to load it

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

Quoted text here. Click to load it
on a port at > 20MHz"
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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.  

Quoted text here. Click to load it
works.
Quoted text here. Click to load it

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"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: A strange PIC problem


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

Quoted text here. Click to load it

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  <--------------------------------
            ; to clear output
            ; data latches
MOVLW 030h  ; Value used to
            ; initialize data
            ; direction
MOVWF TRISA ; Set RA<5:4> as output


So I thought 'Funny that they write this as one piece of code in an example, and
no as 2 different pieces of code,
almost like you need BOTH', but gave it no further thought.
The alternative method LATA would require me to rewrite some code, so I used the
first method, PORTA.

Now suppose you see this in the manual of your new car:
To indicate change of direction use the direction indicator lever on the
steering wheel,
Alternate method is to stick your left hand out of the window for a left turn,
and ask you passenger to stick the right hand out of the window for the right
turns.
One would think: I use the lever.
But then, when driving it, you find out that the lever does not work above 50
mph, so you need to use your hands.
A VERY close examination of the service manual shows the power level of the
electrical system drops
so much above 50 mph that the indicator light electronics no longer works.
Now that would give some commotion...
Makes you wonder if TOYOTA USES PIC MICRO CONTROLLERS IN THEIR SPEED CONTROL
SYSTEM.

Re: A strange PIC problem



Quoted text here. Click to load it
without the PLL.
Quoted text here. Click to load it
found this on page 80,
Quoted text here. Click to load it
and no as 2 different pieces of code,
Quoted text here. Click to load it
the first method, PORTA.
Quoted text here. Click to load it
steering wheel,
Quoted text here. Click to load it
turns.
Quoted text here. Click to load it
mph, so you need to use your hands.
Quoted text here. Click to load it
electrical system drops
Quoted text here. Click to load it
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.





Re: A strange PIC problem



Quoted text here. Click to load it

Amongst those of use who grew up with the 6502 (particularly with the BBC
Micro), that issue was common knowledge. As for a reference, the BBC Micro
Advanced User Guide, section 5.6, page 37, says:

  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.

http://www.bbcdocs.com/filebase/essentials/BBC%20Microcomputer%20Advanced%20User%20Guide.pdf

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.


Re: A strange PIC problem


On a sunny day (Thu, 18 Mar 2010 12:57:15 +0000) it happened Nobody

The situation in other circles may have been different. The other
Quoted text here. Click to load it

Sinclair Z80, ZX81, and Spectrum were Z80 basesd and had not that bug :-
Z80 has no bugs as far as I know, and I coded a lot for it.
It has many 'hidden' instructions though.
Wrote a disassembler for it:
 http://panteltje.com/panteltje/z80/index.html

I never used the 6502 myself.




Re: A strange PIC problem


On Thu, 18 Mar 2010 13:55:40 GMT, Jan Panteltje

Quoted text here. Click to load it

---
Pity...

It was basically a 6800 with no hardware multiply.

JF

Re: A strange PIC problem


John Fields a écrit :
Quoted text here. Click to load it


IIRC the 6800 didn't have any hardware multiply.
It was the 6809.


--
Thanks,
Fred.

Site Timeline