R61581 Shield on STM32 Nucleo L476RG
giuliocorradini opened this issue · 5 comments
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
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.
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!
Are you sure that it reads the ID correctly on the Uno ?
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.
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.
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.