Problem uploading with 3.5 MCU TFT

[hectorlee]

Just tried using the latest version and there's a bug with uploading to my Uno with a 3.5 TFT from mcufriend. The sketch begins to run on the Uno but the Arduino IDE shows its still uploading and throws a bunch of error messages.

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

Seems like there is a problem identifying the controller. I got it working on the official v2.9 from the Arduino thread by forcing an id of 0x9486. I found this controller id through trial and error which leads me to believe my shield has the ILI9486 controller. ID returned through serial monitor was 0xD3D3. I believe this means its a write-only shield and requires a forced id. Not forcing the id on v2.9 still results in the display working fine but color is inverted and display is flipped.

The latest version on the master branch causes the returned id to be 0x8357. Not sure why the id has changed. Without forcing the id of 0x9486 the upload will cause the Arduino IDE to hang and with the error above. Forcing the id of 0x9486 solves the problem.

I think this is a bug which needs fixing as most people will just upload the sketch without editing for the first time. This will cause the display to glitch and the IDE to hang. Not sure what the new default controller the library assigns.

[prenticedavid]

The v2.9.0 "release" supports most 2.4" Shields. The v2.9.1-Beta i.e. the current Master on GitHub has many changes for 3.5" Shields.

As always, the first step is to run the LCD_ID_readreg sketch from the examples. Copy-Paste the Serial output to the Arduino Forum (or here)

I have got datasheets for most controllers even if I do not physically possess the Shield. However certain controllers are "guesswork" and some seem to disobey their own datasheets.

If you have got an "unsupported" controller, you can force different IDs and find the nearest match. Run the graphictest_kbv sketch and make notes of every problem on paper. With your help, I can add support. But this does need accurate written reporting of a problem.

Posting a video is the easiest way to report.

David.

[hectorlee]

Here's the LCD_ID_readreg output for my shield. I did run this before but was having problems interpreting the output. Maybe there could be a wiki entry explaining how to interpret this?

Read Registers on MCUFRIEND UNO shield
controllers either read as single 16-bit
e.g. the ID is at readReg(0)
or as a sequence of 8-bit values
in special locations (first is dummy)

reg(0x0000) C0 C0   ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 00 80 00 Manufacturer ID
reg(0x0009) 00 00 61 00 00  Status Register
reg(0x000A) 00 08   Get Powsr Mode
reg(0x000C) 00 06   Get Pixel Format
reg(0x0061) E1 E1   RDID1 HX8347-G
reg(0x0062) E2 E2   RDID2 HX8347-G
reg(0x0063) E3 E3   RDID3 HX8347-G
reg(0x0064) E4 E4   RDID1 HX8347-A
reg(0x0065) E5 E5   RDID2 HX8347-A
reg(0x0066) E6 E6   RDID3 HX8347-A
reg(0x0067) E7 E7   RDID Himax HX8347-A
reg(0x0070) 00 63   Panel Himax HX8347-A
reg(0x00A1) 00 00 00 00 00  RD_DDB SSD1963
reg(0x00B0) F0 F0   RGB Interface Signal Control
reg(0x00B4) F4 F4   Inversion Control
reg(0x00B6) F6 F6 F6 F6 F6  Display Control
reg(0x00B7) F7 F7   Entry Mode Set
reg(0x00BF) FF FF FF FF FF FF   ILI9481, HX8357-B
reg(0x00C0) C0 C0 C0 C0 C0 C0 C0 C0 C0  Panel Control
reg(0x00C8) C8 C8 C8 C8 C8 C8 C8 C8 C8 C8 C8 C8 C8  GAMMA
reg(0x00CC) CC CC   Panel Control
reg(0x00D0) D0 D0 D0    Power Control
reg(0x00D2) D2 D2 D2 D2 D2  NVM Read
reg(0x00D3) D3 D3 D3 D3 ILI9341, ILI9488
reg(0x00DA) 00 00   RDID1
reg(0x00DB) 00 80   RDID2
reg(0x00DC) 00 00   RDID3
reg(0x00E0) E0 E0 E0 E0 E0 E0 E0 E0 E0 E0 E0 E0 E0 E0 E0 E0 GAMMA-P
reg(0x00E1) E1 E1 E1 E1 E1 E1 E1 E1 E1 E1 E1 E1 E1 E1 E1 E1 GAMMA-N
reg(0x00EF) EF EF EF EF EF EF   ILI9327
reg(0x00F2) F2 F2 F2 F2 F2 F2 F2 F2 F2 F2 F2 F2 Adjust Control 2
reg(0x00F6) F6 F6 F6 F6 Interface Control

I'm glad to help document the problems with my shield. So far with the beta it the problem with the uploading not completing. I think maybe there could be a better 'catch all' or default controller assumed which would at least allow the upload to complete or at least not hang the ide.

Run the graphictest_kbv sketch and make notes of every problem on paper.

Do you mean the problems after forcing the id or the problems without forcing the id?

[prenticedavid]

You have a Himax HX8357-D controller. I only test for [xx 00 80 00] Of course it is quite possible that you have some other make of controller. A definitive identification would be:

    if (msb == 0x00 && ret == 0x8000) { //HX8357-D [xx 00 80 00]
        uint8_t cmds[] = {0xFF, 0x83, 0x57};
        pushCommand(0xB9, cmds, 3);
        msb = readReg(0xD0);
        if (msb == 0x99 || msb == 0x90)
            return 0x8357;
    }

```Your original question said that you had a bad Upload.
I suggest that you restart your IDE.   Or even restart your PC.   The Upload should work ok.
The Library should work 100% with ID=0x8357

David.

[hectorlee]

So its just testing the manufacturer's id in this line?

reg(0x0004) 00 00 80 00 Manufacturer ID

I just tested it again based on your suggestions. I restarted my computer. Loaded up from examples a brand new graphics test. No editing and no forcing. Same errors.

Next I tried forcing the id again but this time forcing 0x8357.

tft.begin(0x8357);

Upload completed and display with working fine. Seems like the bug might be the auto-detection portion.

In case you need this. The Serial monitor printout for the graphicstest.

Serial took 0ms to start
ID = 0x8357

[hectorlee]

Finally managed to upload a video of the error on youtube. Hope that is helpful for you to troubleshoot the error.

https://youtu.be/gXYoKALbYZ0

[prenticedavid]

@Hector, I can not reproduce your problem. I suggest that you delete your current library directory. And install a fresh copy from GitHub. Re-start your PC. If necessary, re-install the Arduino IDE.

The example graphictest_kbv.ino should identify ID=0x8357 on the Serial Terminal. All the library methods are tested in this sketch and should work 100%. I can see no reason for your Upload error.

David.

[hectorlee]

I'm very confused as well. I reinstalled the library via a download from github this time. Was using git the previous time. I've reinstalled the Arduino IDE as well. Suspected it might have been Teensyduino but it is still the same.

I've left the uploading running this time and after quite a number of minutes the upload completes. But as you can see from the video that the display isn't correct.

I modified the setup code to verify the id without using serial monitor. I've attached the code below but this code still has the exact same error. Except the display just shows black this time.

void setup(void) {
    Serial.begin(9600);
    uint32_t when = millis();
    //    while (!Serial) ;   //hangs a Leonardo until you connect a Serial
    if (!Serial) delay(5000);           //allow some time for Leonardo
    Serial.println("Serial took " + String((millis() - when)) + "ms to start");
    static uint16_t identifier;
//        tft.reset();                 //we can't read ID on 9341 until begin()
    g_identifier = tft.readID(); //
    Serial.print("ID = 0x");
    Serial.println(g_identifier, HEX);
    if (g_identifier == 0x00D3 || g_identifier == 0xD3D3) g_identifier = 0x9481; // write-only shield
    if (g_identifier == 0xFFFF) g_identifier = 0x9341; // serial
    if (g_identifier == 0x8357) Serial.println("Board found");
    if (g_identifier == 0x8357) g_identifier = 0x8357;
//    g_identifier = 0x9329;                             // force ID
    tft.begin(g_identifier);
}

This is the output from Serial Monitor.

Serial took 0ms to start
ID = 0x8357

The code below on the other hand works perfectly fine. Which is very strange.

void setup(void) {
    Serial.begin(9600);
    uint32_t when = millis();
    //    while (!Serial) ;   //hangs a Leonardo until you connect a Serial
    if (!Serial) delay(5000);           //allow some time for Leonardo
    Serial.println("Serial took " + String((millis() - when)) + "ms to start");
    static uint16_t identifier;
//        tft.reset();                 //we can't read ID on 9341 until begin()
    g_identifier = tft.readID(); //
    Serial.print("ID = 0x");
    Serial.println(g_identifier, HEX);
    if (g_identifier == 0x00D3 || g_identifier == 0xD3D3) g_identifier = 0x9481; // write-only shield
    if (g_identifier == 0xFFFF) g_identifier = 0x9341; // serial
    if (g_identifier == 0x8357) Serial.println("Board found");
    if (g_identifier == 0x8357) g_identifier = 0x8357;
//    g_identifier = 0x9329;                             // force ID
    tft.begin(0x8357);
}

Are you testing with the same board?

[prenticedavid]

Yes, I have two Shields exactly the same as your pcb photo. They work fine with Teensy3.2 @96MHz There are glitches if you clock @ 120MHz.

Your post makes little sense. Why not simplify it:

void setup(void) {
    Serial.begin(9600);
    if (!Serial) delay(5000);           //allow some time for Leonardo
    g_identifier = tft.readID(); //
    Serial.print("ID = 0x");
    Serial.println(g_identifier, HEX);
    if (g_identifier == 0x8357) Serial.println("Board found");
    tft.begin(g_identifier);
}

If the tft.readID() call identifies 0x8357, this will end up with tft.begin(0x8357)

David.

[hectorlee]

I left the ones in your original code untouched and tried just adding the two lines as an initial step to figure out that it wasn't your code that was the problem.

So today I tried this block of simplified code and it works! So it got me wondering that maybe something in your original example code that is causing the problem. So I debugged it by commenting out one line, upload, see if there is an error and then repeat with another line. I finally found the piece that is causing the error.

String((millis() - when))

This is the piece that is causing the error. Some how this timing calculation is creating the out of sync problem. My guess is there might be some execution timing issue? I'm still not very good at understanding C yet so please pardon me.

Removing that small portion from your full example code resolves the problem. My suggestion would that the setup code in graphictest_kbv needs cleaning up. And that part needs to be removed/fixed. Maybe the simplified code should be the setup code in the example files.

I just realised that I never gave you my specs:

• Mac OS 10.9.5
• Arduino 1.6.13
• Arduino Uno R1

[prenticedavid]

Ah-ha. You are using a R1 Uno. I presume that it uses the Optiboot Bootloader i.e. 32,256 bytes of Flash memory. I am using v1.6.12 of the IDE on a Win7-32 Laptop. I doubt if the String Library is changed in 1.6.13 If you omit String methods, does everything work? Note that I want to test String with tft.print()

I am sure that Arduino will work just fine on a Mac. But I have no experience of the Mac. If you are worried about String, just write some test sketches or run String examples. Likewise, with MCUFRIEND_kbv. Run some simple sketches. Report back.

David.

[hectorlee]

Yup. Does the R3 have more flash memory? I thought its supposed to be the same?

When loading your graphictest_kbv sketch and just commenting out that line in the setup which uses the String library fixes the sketch.

So I did some more tests and suspect it might not be the String library in particular but rather that commenting out that line causes Arduino to not compile the String library which reduces the memory usage. I'm not sure if program storage space or dynamic memory is the one causing the problem. I believe its suppose to be dynamic memory that causes the problem?

https://www.arduino.cc/en/Tutorial/Memory

From reading this article it seems like SRAM (dynamic memory) is the problem here?

So I did some tests without forcing the g_identifier. I've attached the compiler output below.

With String Sketch uses 29,118 bytes (90%) of program storage space. Maximum is 32,256 bytes. Global variables use 1,568 bytes (76%) of dynamic memory, leaving 480 bytes for local variables. Maximum is 2,048 bytes. Low memory available, stability problems may occur.

Without String Sketch uses 27,132 bytes (84%) of program storage space. Maximum is 32,256 bytes. Global variables use 1,532 bytes (74%) of dynamic memory, leaving 516 bytes for local variables. Maximum is 2,048 bytes.

With one String call in the loop() Sketch uses 29,518 bytes (91%) of program storage space. Maximum is 32,256 bytes. Global variables use 1,568 bytes (76%) of dynamic memory, leaving 480 bytes for local variables. Maximum is 2,048 bytes. Low memory available, stability problems may occur.

I then tried creating a barebones sketch that has all your setup code but the only code in the loop is tft.println(String("Hello World"));. This sketch loads and work fine.

I took a look at the graphictest sketches from the adafruit library and the sketches uses much lesser flash and memory. Maybe the key here is there is a need to slim down the graphictest_kbv so that it can be run on the Uno without problems. And the reason why commenting out the line with the String library was just excluding the String library all together to save on memory usage.

[prenticedavid]

You can use 100% of Flash memory without problems whatever the program. i.e. 32256 bytes with Optiboot. In practice, you can use up to 93% of SRAM memory with the graphictest_kbv.ino sketch. 76% of SRAM is perfectly safe.

I would guess that you can beg, steal or borrow a regular Windoze or Linux PC. And find that the examples all compile, upload and run 100% successfully.

If you can identify a problem with Mac or Arduino IDE, I would be very interested to see a test that exhibits the behaviour. I do not own a Mac. I am sure that there are many Mac owners that could try to reproduce your problem.

Regarding the String library. The Arduino implementation is very messy but it works. Adafruit_GFX inherits from Stream and String. My example sketch should show up any "feature".

David.

[hectorlee]

This is weird then. I do have a Windows PC and just updated to the beta on that machine. Was previously using the stable version. It's a clean upgrade, I deleted the library and download a fresh copy from github.

This windows machine has Teensyduino 1.32 installed. There is still an error on Windows. Display has the same visual glitch with the unedited graphictest_kbv example.

Sketch uses 29,118 bytes (90%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,568 bytes (76%) of dynamic memory, leaving 480 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x00
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrthe selected serial port avr does not exist or your board is not connected

Solution is also to reduce memory usage by commenting out the use of the String library.

Sketch uses 27,132 bytes (84%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,532 bytes (74%) of dynamic memory, leaving 516 bytes for local variables. Maximum is 2,048 bytes.

I don't believe the difference of the 8u2 on the R1 vs 16u2 on the R3 should make a difference so there might be something else happening here. Not sure if there's any other significant difference between the R3 and R1 that would cause such problems. Maybe the older firmware on the R1 needs more free memory?

I don't have a linux image to work with at the moment. Be considering finding a spare drive to setup a linux machine again so I can't confirm this problem on linux.

[hectorlee]

So I did another test to cut down on the sketch size. I removed one test to see how it would affect.

Windows 10, Removed testFilledRoundRects(). Success

Sketch uses 28,578 bytes (88%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,568 bytes (76%) of dynamic memory, leaving 480 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.

This upload is fine even with the low memory warning. Dynamic memory usage is the same. I'm not familiar with arduino enough to know if removing that one test could cause any changes in memory usage while the sketch is actually running.

I then duplicated test 10 one more so there are still 11 tests running and the upload fails. I've uploaded this sketch with comments at the top.

Test01.zip

So far the only conclusion I can come to is that this sketch is exceeding the limit of the Uno R1. I don't have an Uno R3 to test. Refactoring and optimising the sketch is the current solution to getting it to work right out of the box with the R1. Optimization should be possible since the official adafruit TFTLCD sketch only uses 62% flash and 23% of dynamic memory. But to confirm this result would require another Uno R1 to exclude the possibility of a hardware problem. It would be very interesting to figure which specific limit of the Uno R1 was exceeded.

Please let me know if you have any specific code/tests you would like me to run.

[prenticedavid]

An 8u2 or 16u2 should not make much difference to the Serial communication with USB. I am sure that you can Google for any "features" of Uno R1. It might be that the USB code has been revised. Or the Optiboot version has been revised.

Personally, I do not own an official Uno R3. Only Seeeduinos (FTDI) or Uno R3 clones. Some with 16u2 and some with CH340. I suspect that you have an 8u2 or Bootloader problem.

The compiled sketch should be identical on Mac, Linux or Windoze. 62% Flash or 100% Flash is fine. The SRAM usage is perfectly safe too. Most SRAM is used in the "Software Scroll buffer". And I test more methods than the regular Adafruit_TFTLCD example.

David.