PICkit3 18F45K22 LCD problem

[howard123]

Hi.
I am using Flowcode V5.4.0.0 (later 5.5) together with PICkit3 on a 18F45K22 device. I am getting unexpected results from the LCD lines on port B in that they are erratic and strangely behave as inputs for a portion of the pulse. The character LCD is not able to interpret the strange timing from the pins.

When reassigning the LCD pins to a different port I get the same behavior. The ports otherwise work correctly as outputs. I have additionally tried setting trisx as outputs in the main loop without success.

Changing the device to a 16F877 corrects the problem and the LCD works.
Many thanks
Howard

[Benj]

Hi Howard,

How fast is your K22 micro running? It could be a read/modify/write issue.

In the custom code for the LCD component have a look at the defines section.

There should be some code that looks like this.

Code: Select all

   	#define %a_PORT0    port%b
   	#define %a_PORT1    port%c
   	#define %a_PORT2    port%d
   	#define %a_PORT3    port%e
   	#define %a_PORT4    port%f
   	#define %a_PORT5    port%g

Change so it looks like this.

Code: Select all

	#define %a_PORT0    lat%b
	#define %a_PORT1    lat%c
	#define %a_PORT2    lat%d
	#define %a_PORT3    lat%e
	#define %a_PORT4    lat%f
	#define %a_PORT5    lat%g

Let me know how you get on.

[howard123]

Hi Ben.
The K22 is running at 19.6608 meg and I have also tried it at 7.3728 meg. Changing the defines you identified had no improving effect, as it is below the 33meg switch.
In both the above cases changing to a 16F877 resulted in the LCD working correctly and also in both cases a delay() ran correctly as externally timed.
I have had a look through the K22 data and cannot find anything unusual for port b. Not using the LCD macros and sending a word to the port and it behaves as it should.
Regards
Howard

[victorhantelmann]

I had a similar problem with a LCD, you should be carefull with your PIC settings, consult the datasheet carefully. Mostly your OSC settings, as an advice try to use the internal clock as Microchip does a preety good job of tunning the internal OSC.
Also, in my case there were erratic signs when the LCD's controller wasn't booting well.
That was due to the fact that I was not allowing enough time for the supply voltage to reach a constant value and then and only then to perform the initialisation procedure of the LCD display.
Also be carefull to read the LCD's datasheet and may be errata and adapt your code to it.
The people in this forum were very helpfull and provided me with enough info to solve all my problems.
Here is the link: http://www.matrixmultimedia.com/mmforum ... 807#p44424

[howard123]

Hi Victor and thank you,

I have tried your recommendations particularly around the clock settings without success. I have tried the internal 1 meg oscillator on the K22 and was surprised to find how accurate it was with less than 1% error. Thanks for that insight. My LCD controller is booting fine, I think, as the identical hardware, code and operating frequency work the LCD when the chip is changed to a 16F877.

I had noticed some time ago that certain LCD displays do not boot well, as you correctly say, and in that case it was due to the rate of change of applied power to the LCD being too slow. Delaying the initialization code did not help but this should nevertheless be done.
Yes you are right the people on this forum are very helpful. I will keep scratching and let you know.

Regards
Howard

[victorhantelmann]

I have previously posted something related to PIC18FxxK80, sorry for that.
If with your LCD and PIC18F45K22 you have problems and with the same LCD and PIC16F877 or 887 you don't have problems then there is a high probability that you either have a hardware problem in your schematic or you have clock related problems...
There is no other posibility because your LCD works fine with PIC16F877 as you say.
You could post your schematic and tell me the technical details about your LCD.
P.S. There is nothing wrong in using high frequency INTOSC settings, you only use more power but you get much faster feedback from your application, 1MHz is preety slow and is a shame not to use the entire power of your uC... Just as a personal oppinion.

Regards.

[howard123]

Hi
This does seem to be a read-modify-write issue only happening with the LCD macro and in my case only with a 18F device. I had thought that perhaps reflections from my 250mm long LCD ribbon cable might be upsetting the port read operation. I set this code to toggle the 6 LCD bits as fast as possible in order to get a view of the pulse edges;
Trisb=0b11000000;
While 1
Portb=0b010101;
Portb=0b101010;
With the LCD connected to portb I got well defined 1.2uS periods on all 6 bits with minimal reflections. There was no interaction between the bits when loaded with realistic values, which I otherwise get using the LCD macro.
Removing this code and using the LCD macro I get interaction between the bits in that when I electrically load a bit, there is interaction with an adjacent bit. I have noticed that sometimes ENABLE and RS work but are on the wrong pin. Mostly the data pins are high (I count through ASCII values so the 4 bits should toggle).
Not sure that the LAT register is being used within the LCD macro. As I understand, using that would be the equivalent of what my above code is doing.
regards
Howard

[victorhantelmann]

Try this code please.

Also revert your custom code for the LCD component back to original.

You should have the two LED flashing ON 500 ms and OFF 500 ms if I got right the settings for your internal OSC.

The two LED use RA6 and RA7 normally used by external OSC.

LAT registers in PIC are lached output registers so you set with TRISx.y = 1 as input or TRISx.y = 0 as output and if it is output and you send data to LATx.y = bit_val then untill you software change your data with LATx.y = new_bit_val then the pin will stay at bit_val. So LAT is static latched while PORT is buffered. I had in the past problems with PORT buffered output and I had to use LAT to overcome the problems, so Benj is probably right with his recomandation. Still you should test this with PORT first and then with LAT to see if LAT is really needed.

Tell me how it worked, I am curious because since I don't have the 18F45K22 chip I can't test it here.

Regards.

[howard123]

Hi Victor
I am using identical hardware for both a 18F4550 and a 18F45K22. I have a dip socket and I unplug the one device and insert the other. Both devices have the same port B pin allocation so they can equally drive my LCD device without any code allocation changes.
Both devices are running at the same (correct) speed as confirmed by instrumentation. Delays have correct periods.
Using the same code for both devices results in the 4550 device writing correctly to the LCD and the 45K22 not writing correctly to the LCD.
Port B is otherwise working correctly on the 45K22 when used with code other than the LCD macro.
Can’t help but think there is some functionality of port B on the 45K22 that I do not understand. The 45K22 is certainly reading the pins at times and rewriting them incorrectly.
Thanks for your continuing interest in this.
Regards
Howard

[Enamul]

Can you please post both programs?

[howard123]

Hi Enamul.

Yes sure I have included both files.
The 18F4550 works well however the 18K45K22 in problematic in writing to the LCD display.

I have however recently noticed that the K22 does sometimes work when using an internal clock. I had previously used the internal clock default (1 MHz.) but for the purpose of this note had included the osccon=0b00110010; instruction, for clarity. On doing this the LCD worked and on reverting to the default it stopped working.
Changing to a xtal of 19.6608 MHz (or other xtal frequencies) and the LCD stops working.

The system frequency was correct in all internal clock and xtal applications – pin C.0 has a frequency of 1 Hz in all test cases.

I should say that I have not tried another K22 as it seems unlikely that the device is faulty, given that the port otherwise works. I could be wrong on this.

Many thanks
Howard

[Enamul]

Can you please try it now with LCD connected at PORTB<0:5> with crystal connected 19.66MHz or 20MHz

[howard123]

Thanks again. Unfortunately there is no change. I cannot understand that it is a timing issue as the four data lines just hang high. On stepping through the ASCII table, as in this case, one should see these lines toggle irrespective of the device speed.
Regards Howard

[howard123]

Hello again.
I seem to have made some progress with this.

When writing to port B of the 18F45K22 (using the standard output), the pins are able to both source and sink reasonable currents however on using the LCD macro to write to port B, there is no ability from the port pins to sink and the pins remain high. Connecting instrumentation under these circumstances caused the irregular irregular behavior I had seen.

I have placed 1k pull-down resistors on the 6 pins of port B and the LCD now works as it should. I am now getting well defined logic levels under all circumstances. There is a clear difference in changing between with and without pull-down resistors.

I would not like this to be a permanent solution and so would like to find a code solution, if possible.

Regards
Howard.

[Benj]

Hi Howard,

That's a good find. Are you using the LCD on a ribbon cable or using lengths of wire or maybe just long PCB traces etc? I wonder if due to this there is noise creeping in or some kind of transmission line problems such as signal echoing which the pull down resistors are helping to eliminate.

[howard123]

Hi Ben

There is a ribbon cable and I have tested for reflections. These are minimal and I have incorporated suppression of 33R series resistors. This hanging high behavior is still present with both the ribbon cable and LCD disconnected from the port. Writing to the port with code other that the LCD macro and at a speed comparable to that of the LCD macro results in the signal being well defined and correct.

Other PIC devices work correctly with the LCD macro on the same hardware.

Many thanks

Howard

[victorhantelmann]

This "This hanging high behavior is still present with both the ribbon cable or LCD disconnected from the port." phrase you posted ... I think that your problem lies on clean output configuration ... take a look below and in the datasheet ...

From datasheet regarding pullpus doc. DS41412F-on page 117

REGISTER 9-2: INTCON2: INTERRUPT CONTROL 2 REGISTER
R/W-1 R/W-1 R/W-1 R/W-1 U-0 R/W-1 U-0 R/W-1
RBPU INTEDG0 INTEDG1 INTEDG2 — TMR0IP — RBIP
bit 7 bit 0
Legend:
R = Readable bit W = Writable bit U = Unimplemented bit, read as ‘0’
-n = Value at POR ‘1’ = Bit is set ‘0’ = Bit is cleared x = Bit is unknown
bit 7 RBPU: PORTB Pull-up Enable bit
1 = All PORTB pull-ups are disabled
0 = PORTB pull-ups are enabled provided that the pin is an input and the corresponding WPUB bit is
set.

Also by default RB5 is P3A and needs to be configured to be used as RB5.

10.3.3 ALTERNATE FUNCTIONS
PORTB is multiplexed with several peripheral functions (Table 10-5 (Very important !!!) ).
The pins have TTL input buffers.
Some of these pin functions can be relocated to alternate pins using the Control fuse bits in CONFIG3H.
RB5 is the default pin for P2B (28-pin devices).
Clearing the P2BMX bit moves the pin function to RC0.
RB5 is also the default pin for the CCP3/P3A peripheral pin.
Clearing the CCP3MX bit moves the pin function to the RC6 pin (28-pin devices) or RE0 (40/44-pin devices).
Two other pin functions, T3CKI and CCP2/P2A, can be relocated from their default pins to PORTB pins by clearing the control fuses in CONFIG3H.
Clearing T3CMX and CCP2MX moves the pin functions to RB5 and RB3, respectively.

Again datasheet:

10.3.1 WEAK PULL-UPS
Each of the PORTB pins has an individually controlled weak internal pull-up.
When set, each bit of the WPUB register enables the corresponding pin pull-up.
When cleared, the RBPU bit of the INTCON2 register enables pull-ups on all pins which also have their corresponding WPUB bit set.
When set, the RBPU bit disables all weak pull-ups. (clean output signal tested by me under all clock freq. and apps.)
The weak pull-up is automatically turned off when the port pin is configured as an output. (hmm... I use software control of TRIS, RBPU and WPUB to be certain)
The pull-ups are disabled on a Power-on Reset. (true but still in the init part of your program you need to configure TRIS, RBPU and WPUB)

On a Power-on Reset, RB<5:0> are configured as analog inputs by default and read as ‘0’; RB<7:6> are configured as digital inputs.
When the PBADEN Configuration bit is set to ‘1’, RB<5:0> will alternatively be configured as digital inputs on POR.

So it might be that you have to control by software the behaviour of PORTB in order to have precise signals. I don't use resistors.

Yes I know that it is harder because you need to use at least C or better ASM and look into C:\Program Files (x86)\Flowcode\v5\Tools\boostc\include\PIC18f45k22.h for definitions and usage of registers in conformance with the datasheet... but still once is solved you put it in a reusable text code file and save it on your hard drive for later use.

Datasheet DS41412F-page 140 ASM code gives you one ideea of what it can be done in assembly. It all depends on your application because there are so many possibilities to play with the functions of PORTB pins ... Good luck !

Regards.

Victor

[howard123]

Hello Victor

Many thanks for your detailed description of the port functioning and your code example.

The code enabled pull up resistors you describe are unfortunately not the cause of my problem. In my case I need to provide pull down resistors which seems to be very non intuitive given my understanding of how the pins are driven.
Also the pins are correctly allocated as the LCD display works but only when adding the pull down resistors.

I will get a new 18F45K22 chip for no particular reason and let you know if I make any progress.

Regards
Howard

[howard123]

Hello

I have solved this by setting a longer slew rate for port B by using slrcon=0b00011101;

Thanks to all for suggestions
Howard

[medelec35]

It looks like this post would apply:
http://www.matrixmultimedia.com/mmforum ... 34&p=45260
Plus also Bens suggestion is also required.
So it maybe worth altering altering FCD for the K series to allow for this on the higher speeds?