A strange PIC problem
Jan Panteltje
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.
dagmarg...@yahoo.com
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
Martin Brown
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
> 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.
You could always low pass filter it, provided it doesn't have to change
too fast (or pulse stretch it slightly).
> 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.
Try it at 32MHz and/or with an external 64MHz xtal.
Regards,
Martin Brown
Jan Panteltje
<|||newspam|||@nezumi.demon.co.uk> wrote in
<wFrmn.92259$Ye4....@newsfe11.iad>:
>Jan Panteltje wrote:
>> 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,
>
>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.)
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 :-)
>> It seems the PIC internal output FF for pin 18 does not toggle, but just 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).
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...
Jan Panteltje
dagmarg...@yahoo.com wrote in
<b79cc9a1-6295-47ed...@x12g2000yqx.googlegroups.com>:
>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.
Yes I think it is at the edge of what PIC can do...
>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?
I even tried a 100 mS delay loop after EACH I?O related instruction...
No difference.
anthony fremont
You should be using a shadow register.
Spehro Pefhany
<pNaonSt...@yahoo.com> wrote:
>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
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"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Martin Riddle
"Jan Panteltje" <pNaonSt...@yahoo.com> wrote in message
news:hnbri1$pu0$1...@news.albasani.net...
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
Jan Panteltje
<spef...@interlogDOTyou.knowwhat> wrote in
<a54mp5h468hfss25h...@4ax.com>:
Thank you, will try that.
WTF should read modify right not work at 64 MHz?
Jan Panteltje
<marti...@verizon.net> wrote in <hnf5i0$qac$1...@news.eternal-september.org>:
What voltage are you running at?
>VCO range is 20mhz at 1.8 to 3.0v, and 64mhz for 3.0 to 5.0v
5.18V
Spehro Pefhany
<pNaonSt...@yahoo.com> wrote:
Because the above code is marginal at 20MHz at best, silly wabbit.
Jan Panteltje
<spef...@interlogDOTyou.knowwhat> wrote in
<a54mp5h468hfss25h...@4ax.com>:
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.
Jan Panteltje
<spef...@interlogDOTyou.knowwhat> wrote in
<14bnp511nfqqhkbp0...@4ax.com>:
>>>Change PORTA to LATA and see what happens.
>>
>>Thank you, will try that.
>>WTF should read modify right not work at 64 MHz?
>
>Because the above code is marginal at 20MHz at best, silly wabbit.
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.
Paul E. Schoen
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
Paul E. Schoen
"Paul E. Schoen" <pa...@pstech-inc.com> wrote in message
news:CGWmn.72788$1n5....@newsfe04.iad...
>
>
> 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.
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
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
Spehro Pefhany
<pNaonSt...@yahoo.com> wrote:
>On a sunny day (Sat, 13 Mar 2010 10:19:30 -0500) it happened Spehro Pefhany
><spef...@interlogDOTyou.knowwhat> wrote in
><14bnp511nfqqhkbp0...@4ax.com>:
>
>>>>Change PORTA to LATA and see what happens.
>>>
>>>Thank you, will try that.
>>>WTF should read modify right not work at 64 MHz?
>>
>>Because the above code is marginal at 20MHz at best, silly wabbit.
>
>Wabbit?
Silly wabbit. PICs may not be for you. ;-)
>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.
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.
>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,
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.
>as usually code ported from for example the 16F 'equivalent' would have tons of 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.
>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.
It isn't a "bug", more of a quirk. But there are usually plenty of
real errata to go around.
Jan Panteltje
<spef...@interlogDOTyou.knowwhat> wrote in
<00fop5lngqjgcuvg7...@4ax.com>:
>>I think it is not the only bug either.
>
>It isn't a "bug", more of a quirk. But there are usually plenty of
>real errata to go around.
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.
Jamie
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.
Nobody
> 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.
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.
Jan Panteltje
<nob...@nowhere.com> wrote in <pan.2010.03.18....@nowhere.com>:
The situation in other circles may have been different. The other
>6502-based micros of that era (Commodore, Apple, Sinclair)
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.
John Fields
---
Pity...
It was basically a 6800 with no hardware multiply.
JF
Fred Bartoli
IIRC the 6800 didn't have any hardware multiply.
It was the 6809.
--
Thanks,
Fred.
Michael A. Terrell
Sigh. Commodore published technical manuals for the VIC-20, C-64 and
most other computers they sold. They had schematics and data sheets on
the 6500 series ICs. Other companies published a lot of books after
reverse engineering the commodore line. i still have most of mine,
including the ones about the 1541 and other drives.
--
Lead free solder is Belgium's version of 'Hold my beer and watch this!'
Joel Koltner
news:4BA29D6C...@earthlink.net...
> Sigh. Commodore published technical manuals for the VIC-20, C-64 and
> most other computers they sold. They had schematics and data sheets on
> the 6500 series ICs.
Yep, and simple-minded assemblers/disassemblers like Supermon by Jim
Butterfield were available pretty much immediately upon their release -- since
I believe he already had them for the PETs and just needed a few quick code
changes to work on the VIC and C-64.
I think I first heard of this particular problem in some article on software
copy protection that suggested that making use of this undocumented behavior
of the 6502 might lead would-be pirates astray. In retrospect I doubt that
would stop anyone for very long -- if you knew anything about hardware design
it might occur to you that something "funny" might be happening when you
crossed a page boundary. (Granted, no Google back then to verify/communicate
such ideas almost instantaneously...)
> i still have most of mine,
> including the ones about the 1541 and other drives.
"Mapping the C-64" and "Inside Commodore DOS" were awesome... those and the
Commodore hardware reference manual were a very good starting library.
---Joel
Jamie
> John Fields a écrit :
Stop it, you guys are reminding me of my age!!!!!!!!!!!!!!!