18F27K40 i2c LCD fails but 18F2320 works

[chico]

Hi - I recently revived a mature FC7 (7.3.0.5) project. It was originally developed on FC7 and has worked well for years.

The project originally used 16F886 or 18F2320 chips interchangeably. It still compiles under FC7 and works with those chips.

However, I now need to move to 18F27K40 chips for this design. I changed the project options accordingly. The updated code compiles correctly, as with the older chips, and uploads to the hardware without error.

Unfortunately, with the 18F27K40 the i2c LCD doesn't work if the "i2c Config Channel" is set to "Channel 1" (hardware). The LCD_start macro hangs (never returns).

The 18F27K40 simulates correctly within Flowcode. With the actual hardware it fails when it hits the LCD_start macro.

If I change the "i2c Config Channel" from "Channel 1" to "Software" it works, but is very slow...about the speed of a 300 baud modem (for those old enough to remember those days )

I'm licensed for FC7 but tried the code with a friend's FC8 and FC9...same thing. The 18F27K50 simulates correctly but the LCD won't run on the actual hardware.

I've gone over all my chip parameters but can't identify why the i2c hardware component works with the 16F886 and 18F2320 but not the 18F27K40. I'm happy to post my code but wanted to ask first if anybody offhand knows the likely reason.

I've attached screenshots of my chip configs, which is where it seems the problem would be, but I can't identify any issues.

I've tried adding C code statements "OSCFRQ = 0x08; // from INT_OSC helper" and "WPUC = 0xFF; // port c weak pullups enabled" to no avail.

Any thoughts or assistance would be very welcome. Thanks.

Screen Shot 2023-08-16 at 2.11.08 PM.jpg (162.3 KiB) Viewed 14605 times

Screen Shot 2023-08-16 at 2.11.56 PM.jpg (75.24 KiB) Viewed 14605 times

Screen Shot 2023-08-16 at 2.13.00 PM.jpg (153 KiB) Viewed 14605 times

[chipfryer27]

Hi

Unfortunately I don't have one of those PICs to check.

What version of FC are you using? I ask as my FC v7.3.0.7 shows a very different properties dialogue layout to yours.

Capture.JPG (41.99 KiB) Viewed 14592 times

I assume you have done the usual one-second flash test to verify clock settings. Have you tried the I2C address sniffer to see if addresses / comms are all good?

https://www.flowcode.co.uk/wiki/index.p ... ss_Scanner

It is sounding quite specific to that chip though.

Regards

[medelec35]

Hi
I have tested the I2C LCD with Flowcode versions 7,8,9 & 10
There is only an issue with version 7, it works as expected with the other versions with 18F27K40 @ 64MHz
As it does work on FC8 & 9, I would recommend trying a 1-sec flasher test first, to make sure the microcontroller is running at the correct speed.

[chico]

What version of FC are you using? I ask as my FC v7.3.0.7 shows a very different properties dialogue layout to yours.

Oops, you're right, my screenshot was taken after testing with FC8 on a colleague's machine. My actual setup is FC7 v7.3.0.6, and here is the FC7 screenshot of the LCD component:

Screen Shot 2023-08-17 at 8.57.56 AM.jpg (136.98 KiB) Viewed 14578 times

As it does work on FC8 & 9, I would recommend trying a 1-sec flasher test first, to make sure the microcontroller is running at the correct speed.

I may have miscommunicated...it DOES NOT work using FC8 or FC9. So it doesn't seem to be version specific. Looking at the FC site I see I can trial FC10. I'll give that a shot, see if there's any difference in operation. (If it works, time to purchase an upgrade!)

Yes, I placed a 1-second LED flash loop in my code before it gets to the LCD_start macro, and it does indeed flash at 1-second intervals.

Since the hardware 18F27K40 locks up in some way in the LCD_start macro, I could try to use MPLABX to single-step through the code to see where the hangup occurs, but since it doesn't hang up in simulation, and my 3 hardware debuggers (ICD3s) have all failed over time, that's probably not going to happen

I welcome any other suggestions...thanks.

[chipfryer27]

Hi

As I'm sure you know, v10 and all components are free for non commercial use so it is certainly worth considering.

As I don't have the chip to try myself, I'm only able to offer what you have probably already tried, although I do think the I2C address sniffer would be a good step as it doesn't use the LCD component and will tell you what if anything it finds. That may help to narrow things down.

I do see that you are using address 39 (whereas the default is 32) so it should come back with that address if it finds your display / anything.

Regards

[chico]

As I'm sure you know, v10 and all components are free for non commercial use so it is certainly worth considering.

When they first announced v10 a long time ago I downloaded it and registered for the free trial. But work got in the way and I never got time to try it out, so now I can't investigate if the screen component would work with my hardware. But you're right, I should take a second look. Do you know if there's a way to get a trial to function again if you already had one but never "trialed" it...?

As I don't have the chip to try myself, I'm only able to offer what you have probably already tried, although I do think the I2C address sniffer would be a good step as it doesn't use the LCD component and will tell you what if anything it finds. That may help to narrow things down.

Because the hardware works fine with a 16F886 and 18F2320, the i2C address appears correct. But I'll give the sniffer a try anyway, in case some behavior leads to a clue. I could put a scope on the lines and dig deep but not sure I have time for that kind of investigation at the moment....

I do see that you are using address 39 (whereas the default is 32) so it should come back with that address if it finds your display / anything.

Yes, that's the default on this display (0x27) and I've also tried a different display with address 63 (0x3f)...both work with the 16F886 and 18F2320 but neither with the 18F27K40...sigh...

Would love to be able to single step the hardware, see where in the LCD_start routine it's stuck...

[medelec35]

Hello.
Flowcode v10 is different as it has no trial, so no time limit.
So long as you have got one of the free target devices shown here and the required toolchains from here you will be good to go

[chico]

Flowcode v10 is different as it has no trial, so no time limit.
So long as you have got one of the free target devices shown here and the required toolchains from here you will be good to go

My Flowcode v10 runs in trial mode, it just doesn't work with any PICs I have on hand, including the 18F27K40 which is has the issue I'm describing in this thread. I'd probably purchase the PIC8 pack if I knew for sure the 18F27K40 works with the i2c LCD...

Anyway, the code using Flowcode v7 (mine) and v8 (a colleague's) never returns from the i2c Start macro. In the source code this is the function "FCD_0c591_lcd_I2C1__Start()".

So I replaced the Flowcode macro with my own C code macro that includes the same source generated by a Flowcode compile-to-C command. I then placed LED debug blinkers inside that code to see what the offending command was.

The original code looks like this:

Code: Select all

void FCD_0c591_lcd_I2C1__Start()
{

	if (FCV_0c591_lcd_I2C1__ADDRESSOVERRIDE == 1)
	{

		//Comment:
		//Ignore as we have already set the overridden address

	} else {

		FCV_0c591_lcd_I2C1__I2C_ADDRESS = 39;

	}

	FC_CAL_I2C_Master_Init_1();

	FCI_DELAYBYTE_MS(12);

	FCD_0c591_lcd_I2C1__EnablePulse(3);	// ****** 18F27K40 NEVER RETURNS FROM THIS FUNCTION CALL ******

	FCI_DELAYBYTE_MS(4);

	FCD_0c591_lcd_I2C1__EnablePulse(3);

	FCD_0c591_lcd_I2C1__EnablePulse(3);

	FCI_DELAYBYTE_MS(4);

	FCD_0c591_lcd_I2C1__EnablePulse(2);

	FCD_0c591_lcd_I2C1__RawSend(0x2C, 0);

	FCD_0c591_lcd_I2C1__RawSend(0x06, 0);

	FCD_0c591_lcd_I2C1__RawSend(0x0C, 0);

	FCD_0c591_lcd_I2C1__RawSend(0x01, 0);

	FCI_DELAYBYTE_MS(2);

}

The problem is that the processor hangs in first occurrence of " FCD_0c591_lcd_I2C1__EnablePulse(3)". By inserting debug LED blinkers into the code I was able to trace the code as running to just before that line of code, but never after.

Unfortunately, it appears that that code is pre-compiled and linked in at compile time, I suspect from inside the component "lcd_i2c.fcpx". I don't know much about how Flowcode works but this is my guess at the moment.

Without being able to view the source code to see where the hangup occurs, I think I've hit a wall.

Based on what I've seen, since the code works with a 16F886 and 18F2320 but not the 18F27K50, there appears to be a bug in the component that causes this particular processor to hang up at that point. I suspect there's a register manipulation necessary to allow the code to work as intended but it's not being performed by the component code. Or maybe some silly other issue on my end that I'm missing...

I did connect a scope to the i2c clock and data lines and they never toggle, not even once, with the 18F27K50, but look just fine with the other processors.

[chipfryer27]

Hi

In v10, source codes were kindly made available in the WiKi. It is well worth the upgrade in my opinion.

https://www.flowcode.co.uk/wiki/index.p ... AL)_(Misc)

Funnily enough, I'm having I2C issues with an ESP device. Too early to say what the problem is as both chip and sensor are "new" so could quite easily be me doing something wrong.

Regards

[chico]

In v10, source codes were kindly made available in the WiKi. It is well worth the upgrade in my opinion.

https://www.flowcode.co.uk/wiki/index.p ... AL)_(Misc)

Thanks for the info. I was hopeful, but unfortunately it's not C source code. I'm trying to see why the LCD_i2c function "FCD_0c591_lcd_I2C1__EnablePulse(3)" fails on the 18F27K40, but the page you referenced doesn't show the i2c macro underlying C source code. The downloadable FC project "FC_Comp_Source_I2C.fcfx" appears to consist of lower level macros that underlie the normal high level macros presented by Flowcode to the user, although I may be misunderstanding what I'm viewing. It's interesting, but not useful to me in trying to remedy my particular issue.

Do you think I should file a bug report on this? Or is FC7 too old to be supported anymore? As I said, it also fails on a colleague's FC8 and FC9 installations, but I don't have ongoing access to his machine to dig deeply into it on those versions...

[chipfryer27]

Hi

Whilst you can go to Build>View C-Code, it may not be what you need. V7 is old now and I don't know how much official support it receives, but posts do get replies, especially if the subject also impacts later versions.

If I had that chip I'd happily check it out further, but it certainly does look specific to it.

Regards

[chico]

Whilst you can go to Build>View C-Code, it may not be what you need.

That's what I've been using so far. I can use that code to create C-code blocks and replace various macros with actual C code, and that gives me the ability to insert my own debugging code (for example, insert LED blinkers at places in that code to track whether it's being executed, or display a certain number of blinks to indicate state or variable information, etc.).

The problem is that components (in this case, "LCD_I2C.fcfx") appear to be compiled code, not C-source code, and are linked in at compile time. So I don't have access to any code I can trace or place debug statements or LED blinks or other debugging aids. I know there's a problem with a component and my particular processor, but I can't diagnose it.

At least that's my understanding of how FC works...would appreciate being corrected by anyone who knows FC better than I do...