mLink Arduino library for mLink modules

[andrew]

Hi Roger,

I have no idea why it would be doing that. Changing the cursor direction requires a specific write to the display's control register 2. That register only handles the display size and cursor direction so unless there is a need to specifically write to that register then it shouldn’t get changed.

One thing to keep in mind though, is it’s one of the few registers that when updated gets stored to NVRAM. So if at any point the cursor dir bit gets set, it will remain set even after reset or power is removed from the display. Just something to keep in mind while you’re trying to get to the bottom of the issue.

Can I confirm that this is only happening to one of your displays, and only when you upload a new sketch?

Do you by any chance have a 5V Arduino that you could test it with?

[RogerL]

One thing to keep in mind though, is it’s one of the few registers that when updated gets stored to NVRAM. So if at any point the cursor dir bit gets set, it will remain set even after reset or power is removed from the display. Just something to keep in mind while you’re trying to get to the bottom of the issue.

I wondered if this was the case which was why I mentioned I hadn't been toggling the cursor direction in any of my test programs.

Can I confirm that this is only happening to one of your displays, and only when you upload a new sketch?

Yes, its only when I upload a sketch. Its only happened so far on one of my displays (#1). With my second display I did about 10 program uploads as a test and didn't get the problem. With display #1, even if it worked to start with, it started failing after 4 or 5 uploads and then continued to fail.

Do you by any chance have a 5V Arduino that you could test it with?

That was the next thing I was going to try! I will report back.

As a general principle, I prefer to explicitely set parameters in my programs rather than rely on defaults, so its not a big deal for me to do this. However, it would be good to know if this was a library bug you could fix, a firmware glitch on the display that I need to work around or a hardware fault with this particular display.

[RogerL]

I hooked the display up to a Uno and after several downloads it was still working OK. I unplugged the display from the Uno, connected it to the ESP32, downloaded the program and the direction flipped. Then something weird happened.....

One thing to keep in mind though, is it’s one of the few registers that when updated gets stored to NVRAM. So if at any point the cursor dir bit gets set, it will remain set even after reset or power is removed from the display. Just something to keep in mind while you’re trying to get to the bottom of the issue.

After re-reading this I realised that the cursor direction should not have been resetting when I power cycled the board and display. But it has always done so when I have been working with the ESP32. So, when I got the error on the ESP32 board I powered down the board and display. I then connected the display back to the Uno and powered up the Uno and display. I was expecting this to reset the cursor direction. It didn't. I had to download a new program to explicitely set the cursor direction back to 0. I repeated the whole process again (Uno - ESP32(error) - Uno) and got the same result. So, power cycling with ESP32 clears the problem, power cycling with Arduino Uno doesn't.

This is the bare-bones program I have been using for testing (un-commenting the cursDir command when required):

#include "mLink.h" // Include the library
mLink mLink; // Create an instance of the library
#define I2C_ADD 0x56 // Default I2C address

void setup()
{
mLink.init(); // Initialise the library
mLink.cLCD_dispType(I2C_ADD, 1); //set display type to 2004
// mLink.cLCD_cursDir(I2C_ADD, 0);
}

void loop()
{
mLink.cLCD_clear(I2C_ADD);
mLink.cLCD_backlight(I2C_ADD, 5);
mLink.cLCD_cursor(I2C_ADD, 5, 0); // Set the cursor to col 0 row 0
mLink.cLCD_print(I2C_ADD, "Hello "); // Print something
mLink.cLCD_cursor(I2C_ADD, 5, 1); // Set the cursor to col 0 row 1
mLink.cLCD_print(I2C_ADD, "World "); // Print something
mLink.cLCD_cursor(I2C_ADD, 5, 2); // Set the cursor to col 0 row 2
mLink.cLCD_print(I2C_ADD, "Hello "); // Print something
mLink.cLCD_cursor(I2C_ADD, 5, 3); // Set the cursor to col 0 row 3
mLink.cLCD_print(I2C_ADD, "World "); // Print something
while(1);
}

I am feeling I would like to draw a line under this now and get back to working on my project.

[andrew]

Thanks again for the answers. This conversation is getting a bit long so just for myself I’m going to summarise the issue:

• The issue is the cursor direction is sometimes being set to right to left. I.e. bit 0 of register CR2 is being set.
• This only happens occasionally and only whilst uploading a sketch
• It only happens to one of two displays.
• It happens when using an ESP32 with level shifters.
• It does not happen when interfaced directly to a 5V arduino.
• Edit: Power cycling the module & ESP32 clears the cursor direction bit

Feel free to let me know if any of the above is incorrect.

As a general principle, I prefer to explicitely set parameters in my programs rather than rely on defaults, so its not a big deal for me to do this. However, it would be good to know if this was a library bug you could fix, a firmware glitch on the display that I need to work around or a hardware fault with this particular display.

I don’t want to rule out the possibility it is one of the above but the fact that it is only happening to one screen would suggest it’s not a firmware issue (don’t want to rule it out though).

I don’t think it would be a library issue because at power up the library does not write anything to the display at all. Only when your sketch starts running does something get written to the display.

It could be some weird physical problem with that particular display but if that was the case I don’t know why it would work fine with your 5V Arduino.

It feels like something is operating on the edge when using with the ESP32+level shifters.

One thing that’s interesting is to set the cursor bit, you can write 0b00001111 0b11111111 as the address and data bytes. Apart from the first 4 bits of the address but that’s all 1’s. I don’t if it's significant but it could be a clue.

Do you have any way to confirm that the level shifter is driving the SDA&SCL pins high enough? Is it possible to disconnect the level shifter from your Pico and manually force the level shifter to drive the SDA&SCL pins high, then check the voltage at the SCAL&SDA pins?

[RogerL]

The issue is the cursor direction is sometimes being set to right to left. I.e. bit 0 of register CR2 is being.

Yes

This only happens occasionally and only whilst uploading a sketch

It happens most of the time with one of the displays. It has only happend so far when uploading a sketch, but then my total focus over recent days has been to test for and understand the upload issue, so I haven't done any extended use testing.

It only happens to one of two displays.
It happens when using an ESP32 with level shifters.
It does not happen when interfaced directly to a 5V arduino.

Yes.
I think the other thing we should not loose sight of is that power cycling the board with ESP32 is resetting the cursor direction bit.

It feels like something is operating on the edge when using with the ESP32+level shifters.

I agree that this is the next thing to check.

Do you have any way to confirm that the level shifter is driving the SDA&SCL pins high enough? Is it possible to disconnect the level shifter from your Pico and manually force the level shifter to drive the SDA&SCL pins high, then check the voltage at the SCAL&SDA pins?

Yes, I have the tools to do this. However, it may take me a few days to fit this in.

[RogerL]

I managed to grab an hour to do the tests.

I loaded a program to just set the SDA and SCL pins high. With the 2-channel level-shifter I have been using, the ESP32 side was 3.290V, the LCD side was 4.675V. This was with an actual 5V supply measurement of 5.059V. So, the LCD side voltage was looking lower than I expected. I tried another 2-channel level-shifter from the same batch and got the same result. I then replaced that with a new 4-channel shifter I had in stock. This gave an output voltage level of 5.053V. I connected the LCD to this new level-shifter and downloaded the display test program I have been using. The text displayed OK. I downloaded the program again and the direction flipped. I cleared the error by power cycling the board and downloaded the program again. The direction flipped. I cleared the error again, this time by including the cursDir statement in setup. I then removed the cursDir statement and downloaded the program again. The direction flipped.

Electrically, things are looking a bit cleaner, but we still have the problem.

[andrew]

Yes.
I think the other thing we should not loose sight of is that power cycling the board with ESP32 is resetting the cursor direction bit.

That’s a good point, I missed that one. I’ll add it to the list.

With the 2-channel level-shifter I have been using, the ESP32 side was 3.290V, the LCD side was 4.675V.

That looks fine to me.

This gave an output voltage level of 5.053V. I connected the LCD to this new level-shifter and downloaded the display test program I have been using. The text displayed OK. I downloaded the program again and the direction flipped. I cleared the error by power cycling the board and downloaded the program again. The direction flipped. I cleared the error again, this time by including the cursDir statement in setup. I then removed the cursDir statement and downloaded the program again. The direction flipped

Electrically, things are looking a bit cleaner, but we still have the problem..

I agree, the levels at least are fine. I’ve had a look through the firmware but I don’t see anything there. Unless the LCD is reset, or something is received on the I2C bus then it does not actively do anything - and as previously mentioned the library doesn’t write anything to the module until the sketch starts running commands. Even the init function doesn’t write anything to the module, it just initialises the I2C library. So I still don’t know exactly what it exactly could be causing it.

One thing about your sketch, and sorry if you’ve mentioned this previously, but the first line after the init is setting the display type to 20x4. Has that always been in your sketch?

I ask as it is the very first thing to be written to the display and it’s writing to the same register as the cursor direction.

[RogerL]

One thing about your sketch, and sorry if you’ve mentioned this previously, but the first line after the init is setting the display type to 20x4. Has that always been in your sketch?

Yes. I have a dedicated breadboard setup and programs for my 2004 display testing and the code defining the display type has been in from the start. At one stage I did put delays in the setup code between all the display-related commands in case the issue might be with busy states not being handled, but it had no effect.

[andrew]

Yes. I have a dedicated breadboard setup and programs for my 2004 display testing and the code defining the display type has been in from the start. At one stage I did put delays in the setup code between all the display-related commands in case the issue might be with busy states not being handled, but it had no effect.

The screen type is one of the things that gets saved in NV memory and like the cursor direction, it should only ever need to be set once. And that said, we set it to the correct setting at the time of flashing the firmware so it's not even a thing you'd need to worry about. So.....

If you comment out the display type and cursor direction lines of your sketch, does the problem go away?

[RogerL]

Since I commented out the dispType command the cursor direction hasn't flipped.

Looking at several of your example programs I see that the dispType command was never included, which poses the question why I put it in? I have been looking back through the versions of the larger program I was working on when I first had the problem. The dispType line first appears the day before I raised the issue with you, but I don't know if that was done before or after things first started going wrong. When I first had the problem I hadn't figured out the cursor direction was flipping and thought areas of display were being blanked, If it wasn't already in there, setting the screen size would have been the first thing I tried just so the library would know what display area it was dealing with. When I raised the issue and got into doing all the specific testing I chopped my big program down to what I thought was the basics so it would compile and upload quicker, but the dispType line got left in.

Anyway, things are working OK at the moment after several downloads. I will let you know if that changes.