HD44780 Corrupting Cerberus Firmware

Archive
1

It appears there’s something in the HD44780 PrintString() that is causing a corruption of the TinyBooter and/or firmware on my Cerberus. Before I remembered the SetCursur(), I attempted to use “\n\r” notation to get to a new line. What I discovered is that if you send either of these escaped characters to PrintString() then it will corrupt your firmware. I’ve tried just doing an erase from MFDeploy and MFDeploy no longer recognizes the Cerberus once this code has been executed. I can reproduce this 100% of the time.


display.PrintString(_displayLine[0] + "\r" + _displayLine[1]);

I don’t think it matters what _displayLine[n] values are but in my test they were…
_displayLine[0] = “Good morning!”
_displayLine[1] = “”

It would be nice to harden the driver a bit to handle this better.

2

Very unlikely to happen. Have you tried it again?

3

I reinstalled my Tinybooter + firmware five times last night :frowning:

4

@ ianlee74 - I cannot address the issue you are having, but since you mentioned SetCursor, I remembered that there is an issue with that routine. You can see more here
http://www.tinyclr.com/forum/topic?id=9727

I just checked the latest code and the issue appears to still be there. Just thought I would give you a heads up.

5

@ taylorza Thanks.

I’ll try pulling just the problem code into a new project tonight just to verify that it’s not a combination of problems. But, last night I was able to step to the .PrintString() line and the device would then become unresponsive.

6

I tried creating a new project that only contains the following. I couldn’t reproduce the corrupt/locking Tinybooter that I can create in the other project. There must be some combination of other modules, threads, etc. I’ll try to narrow it down farther if I get any other ideas as to what it is.

However, this test did reveal something odd. If I run this code through Visual Studio debugger then I end up with junk on the display. If I disconnect and reset the device and let it run at full speed then I end up with “No bug.” as expected. Perhaps that means something to someone as to why I’m seeing the other problem in the other project.


        void ProgramStarted()
        {
            Debug.Print("Program Started");
            
            // display_HD44780 is connected to socket #4 of Cerberus.
            display_HD44780.PrintString("Bug.");
            var line = new string[2] {"Good morning!", ""};
            display_HD44780.PrintString(line[0] + "\n" + line[1]);
            display_HD44780.Clear();
            display_HD44780.PrintString("No bug.");
        }

EDIT:
@ taylorza - yea…I’ve run into the SetCursor() bug. It seems that running a custom version of the driver will be the only way to get something printed on the second line :frowning:

7

@ ianlee74 - This is the code snippet that I use to print to both lines of the Char display


void PrintScreen(string row1, string row2)
        {
            display_HD44780.Clear();
            display_HD44780.CursorHome();
            display_HD44780.PrintString(row1);
            display_HD44780.SetCursor((byte)0x01, (byte)0x00);
            display_HD44780.PrintString(row2);
        }

This code was written for, and currently running on, Cerb-family hardware without issue.

8

@ James - Try the following


display_HD44780.SetCursor(2,4);
display_HD44780.Putc((byte)'X');

You should see that the ‘X’ is shown in column 0. At least with the drivers we currently have.

The answer I provided in the linked post explains what the problem is.
http://www.tinyclr.com/forum/topic?id=9727&page=1#msg96860

9

Thanks, James. I’ll try that. I was using this which I had borrowed from a previous project that (I believe) did work last time I ran it months ago


display_HD44780.PrintString("Good morning,");
display_HD44780.SetCursor(2, 1);
display_HD44780.PrintString("America!");

However, looking at your code it appears that the row value is zero based and I was probably printing off screen somewhere. This has me wondering about my old test project… I’ll try that tonight.

10

@ James - Ah, I see why I might have caused some confusion. I did not realize that the HD44780 with screen is only 2 lines, the issue I am referring to will only present with a 4 line display. Sorry if I caused any confusion, but it would be good to get the driver fixed.

11

@ taylorza - I have added this as an issue to be looked at, and will return with an answer as soon as possible.

12

From the code snippets from everyone’s posts, I was unable to reproduce the firmware corruption.

@ ianlee74,

Can you post the entire code that caused the issue for you so I can see if it happens here?

13

@ Aron Because I was never able to create a minimal project that would reproduce the problem, I sent you the entire project. It’s still not very big but there are a few modules connected and some combination of those is apparently what is causing the problem. Look in Program.cs UpdateDisplay() for some notes on the problem line. The Extender is simply being used to indicate a break in a wire between gnd & pin #9 or gnd & pin #8. I wasn’t sure of your email, so I sent it to Gus’ & ghielec addresses. Let me know if you need anything else.

14

@ ianlee74

I had an opportunity to test your code. The Cerberus does appear to lock up in the display.PrintString() function but only if you have anything that would seem to function as an escape sequence. If there are no escape sequences being concatenated between the string variables then the function executes and exits as normal and, as you reported, the firmware appears to lock-up when you have the escape sequences concatenated between the string variables. However, there is an interesting note that we are investigating. If you place the escape sequence within the string variable, the system does not lock up.

I would recommend using the lines of code that you indicate that they do work in your code until an answer to this issue can be found.

15

Cool. Yea, the lines are totally incorrect for operating the display but I posted this for your information since I believe even bad code should not be allowed to lock up the firmware :slight_smile: Thanks for checking into it.

16

Any chance this could impact a Cobra II? I have two of them with this lcd and every couple days I have to reflash them because the firmware becomes corrupt. It seems random.

I am running them with 9v 1a power supplies.

17

@ - user 12135 This thread is older than the current SDK ( see http://www.ghielectronics.com/support/.net-micro-framework ). We had some timing issues in the driver that were corrected. I would say it is unlikely that the LCD display driver is the problem with your application. Age old advice: attempt narrow down what, where, when fails in your code and then post the small example that we can examine.

18

Will do. I am running the latest but i will try to narrow it down.

19

Well, Taylorza… I’m for one is very glad you posted this. I was also experiencing the same problem on my 4x20 LCD. I’ve been meaning to try and find the fault myself, but this bug was so subtle I probably would not have found it myself.