prenticedavid / MCUFRIEND_kbv

MCUFRIEND_kbv Library for Uno 2.4, 2.8, 3.5, 3.6, 3.95 inch mcufriend Shields
Other
357 stars 177 forks source link

R61581 Shield on STM32 Nucleo L476RG #203

Open giuliocorradini opened 2 years ago

giuliocorradini commented 2 years ago

Hello David, I'm having trouble while trying to interface a 3.5 inch display bought from Amazon, which was advertised to be based on the ILI9486 controller.

I tested the display and I had no issues with an Arduino UNO. I want an higher refresh rate and I'm trying to use it with an STM32 Nucleo L476RG by plugging it in directly, but it's not working.

I tried the diagnose_tft_support sketch on both MCUs, here are the results:

Arduino UNO

tft.readID() finds: ID = 0x1581

MCUFRIEND_kbv version: 3.0.0

PORTRAIT is 320 x 480

Run the examples/graphictest_kbv sketch
All colours, text, directions, rotations, scrolls
should work.  If there is a problem,  make notes on paper
Post accurate description of problem to Forum
Or post a link to a video (or photos)

I rely on good information from remote users

this suggests the display is actually based on the ILI9481/R16581. The display shows the various colours and changes rotation just fine.

STM32

tft.readID() finds: ID = 0x0

MCUFRIEND_kbv version: 3.0.0

This ID is not supported
look up ID in extras/mcufriend_how_to.txt
you may need to edit MCUFRIEND_kbv.cpp
to enable support for this ID
e.g. #define SUPPORT_8347D

New controllers appear on Ebay often
If your ID is not supported
run LCD_ID_readreg.ino from examples/
Copy-Paste the output from the Serial Terminal
to a message in Displays topic on Arduino Forum
or to Issues on GitHub

Note that OPEN-SMART boards have diff pinout
Edit the pin defines in LCD_ID_readreg to match
Edit mcufiend_shield.h for USE_SPECIAL
Edit mcufiend_special.h for USE_OPENSMART_SHIELD_PINOUT

the shield is directly plugged onto the Nucleo board.

Could you help me sort this out?

Thanks in advance

prenticedavid commented 2 years ago

If it works on the Uno it should work on the Nucleo-L476RG.

I just tried it on Keil with a L476 and R61581 and Release-2.9.9 Sure enough it returns an ID = 0x0000.

I suggest that you just do a kludge for the moment e.g.

    uint16_t ID = tft.readID(); //
    if (ID == 0x0000) ID = 0x1581;                             // force ID
    tft.begin(ID);

I will investigate what is happening later today. It seems to read other IDs ok.

My particular R61581 has a hardware fault. Sometimes it works and sometimes it dies. i.e. it is unreliable on a Uno.

giuliocorradini commented 2 years ago

Your suggestion worked like a charm. Let me know if I can help with further investigation, doing tests etc.

For the record I'm compiling the project using PlatformIO with STM + Arduino framework, and now I have no issues.

Thanks a lot!

prenticedavid commented 2 years ago

Are you sure that it reads the ID correctly on the Uno ?

From the datasheet: image

You will see that there is

    WriteCmdData(0xB0, 0x0000);   //R61520 needs this to read ID

at the end of the reset() command. i.e. it should enable the Manufacturer Commands on ILI9481, HX8352B, R61581

Since my R61581 is damaged you can trace the readID() sequence in the Nucleo.

    ret = readReg40(0xBF);
    if (ret == 0x8357)          //HX8357B: [xx 01 62 83 57 FF]
        return 0x8357;
    if (ret == 0x9481)          //ILI9481: [xx 02 04 94 81 FF]
        return 0x9481;
    if (ret == 0x1511)          //?R61511: [xx 02 04 15 11] not tested yet
        return 0x1511;
    if (ret == 0x1520)          //?R61520: [xx 01 22 15 20]
        return 0x1520;
    if (ret == 0x1526)          //?R61526: [xx 01 22 15 26]
        return 0x1526;
    if (ret == 0x1581)          //R61581:  [xx 01 22 15 81]
        return 0x1581;
    if (ret == 0x1400)          //?RM68140:[xx FF 68 14 00] not tested yet
        return 0x6814;

I have never used PlatformIO. I presume that it handles the STLink debugging ok.

David.

giuliocorradini commented 2 years ago

The Uno can correctly read the ID without any edit to the given sketch. Didn't know you need to release "Access Protect".

On the STM, it seems like performing two resets before reading the ID register magically resolves the issue

tft.reset();
tft.reset();

uint16_t ID = tft.readID();    //returns 0x1581 as expected

and the display is correctly initialized.

I can't quite understand why this works... I will try to investigate more.

P.S. The debugger frontend of PlatformIO and behaves nicely with STLink debugging.

Giulio.

prenticedavid commented 2 years ago

Try adding a delay(10) at the end of reset(). See whether this enables the Manufacturer Commands. i.e. instead of your second tft.reset() call. I would expect writing 0x0000 to reg(0xB0) to take immediate effect. It is more likely that the hardware reset pulse needs a longer delay. e.g. 150ms But that would show up on a Uno.

I can fully understand lock and unlock sequences for Manufacturer Commands. But it seems crazy for the ID (0xBF) to be a restricted register.

I have never used PlatformIO. It seems to be built on Eclipse. I am much happier with building in Arduino IDE. Then debugging the ELF file in Rowley Crossworks.

Or just writing regular C, C++ in Rowley Crossworks in the first place. Now that Keil has an unrestricted hobbyist licence I might use Keil more often.