V1.0.0 ili9341 bug when Re-flashing

On Win10 Simulide V1.0.0 I have trouble to reload and run code which shall give an output on the ili9341 display.

Situation:

1. Start V1.0.0
   
2. Open demo_simu.sim1
   
3. Load Firmware "Pacman.hex"
   
4. Run Simulation (shows only a Pacman like screen)
   
5. Load Firmware "not_running.hex"
   
6. Run Simulation (shows nothing - the students had trouble to run the code, quite likely timing problems)
   
7. Load Firmware "Pacman.hex"
   
8. Run Simulation
   

Awaited Output
Shows Pacman like screen on the ili9341 again, since steps 7. and 8. are similar to 3. and 4.

Shown Output
Nothing on the ili9341

"Bonus Bug"
The bug is not reproducable with R768 and 4.15RC9 since there the simulation crashes after loading the firmware..

Somehow also the V1.0.0 is not really stable when reloading firmware or measuring with the scope.

The hex's, simu and sim1 are attached.
(My students would apprechiate the investigation   )

Load Firmware "not_running.hex"
Run Simulation (shows nothing - the students had trouble to run the code, quite likely timing problems)

Indeed this was a bug in simulide. Solved in Rev 770.

This is what it's showing now:
Fonts have an empty line every other column, making them twice as wide.
This caused address go out of range (boundary checking was wrong).
This looks like an error in the firmware:
X address is incremented by 2 instead of by 1 while printing each column of the font.
If it's not an error in the firmware, please let me know. It could also be an error reading data.

The bug is not reproducable with R768 and 4.15RC9 since there the simulation crashes after loading the firmware.

This was a silly bug I introduced recently. Solved in Rev 769.

I will upload new Tester builds soon, hopefully today.
But solving the firmware issue it should work normally.
The bug only kicks in if there is an address out of range sent with commands:
- 0x2A: Column Address Set.
- 0x2B: Page Address Set.

In SR9 it looks better (I included a condition to catch too great x / y positions). The letters seem to be completely filed:

https://wiki.mexle.org/_media/blog/301221_output_in_sr9.jpg

I also attached the corrected hex file.

Yes, you are right.
Indeed the fonts don't look stretched.

It was an error introduced in my last fix (Rev 770).
Solved in Rev 774.

Debugging the data received by ili, I see the "endY" is not correct.
For example to set startY = 4, endY = 5:
4 bytes are sent after command 0x2B (Page Address Set).
It should be: 0, 4, 0, 5
But it receives: 0, 4, 5, 5

Data for sartX and endX looks correct.
Not sure if it's an error in the firmware or in simulide.

You are right: The "standard" lib has a bug in the code.
The right shift for y2 by 8 bits is missing; the lower byte gets send twice.

e.g.
https://www.avrfreaks.net/sites/default/files/project_files/ili9341_0.c
https://gist.github.com/postmodern/ed6e670999f456ad9f13

Code:

void ili9341_setaddress(uint16_t x1,uint16_t y1,uint16_t x2,uint16_t y2)//set coordinate for print or other function
{

...

ili9341_writecommand8(0x2B);
ili9341_writedata8(y1>>8);
ili9341_writedata8(y1);
ili9341_writedata8(y2);
ili9341_writedata8(y2);

ili9341_writecommand8(0x2C);//meory write
}


I assume, that in real life no display took care, since y seems to be "often" the width (max 240). Probably the display just ignores the higher byte..

I haven't used the ili9341 often, but it seems, that sometimes the ILI9341_TFTWIDTH is set to 240 (see http://adafruit.github.io/Adafruit_ILI9341/html/_adafruit___i_l_i9341_8h_source.html ) and sometimes to to 320 ( https://gist.github.com/postmodern/ed6e670999f456ad9f13 )

I assume, that in real life no display took care, since y seems to be "often" the width (max 240). Probably the display just ignores the higher byte..

I'm not sure...
This display is indeed 240(H)x320(V)

Rotation can be configured (I don't understand yet how it works).
But it just changes how memory is mapped to pixels.
Memory adresses are always: X= 0 to 239 , Y= 0 to 319.

Here is the explanation of rotation in the datasheet (Row / Column Exchange):
Btw, ther is an error:
MV(Vertical refresh order bit)="0"   MV(Vertical refresh order bit)=" 1"
Should be:
MV(Row / Column Exchange)="0" MV(Row / Column Exchange)=" 1"



So when rotated, the image is "croped" and "overflows" in itself.. or something like that.

I think that the normal operation to print in "landscape" mode is just leave the rotation by default and send the data with X and Y values swaped.

In any case in simulide only the basic commands are implemented.

arcachofo wrote:Rotation can be configured (I don't understand yet how it works).
But it just changes how memory is mapped to pixels.
Memory adresses are always: X= 0 to 239 , Y= 0 to 319.

Definetly I don't understand how it works...

Diving into the datasheet I found that the MV bit (Row / Column Exchange) indeed change the orientation in memory:
MV=0: Memory adresses are: X= 0 to 239 , Y= 0 to 319.
MV=1: Memory adresses are: X= 0 to 319 , Y= 0 to 239.

But then I don't undestand this:

I interpret the manual in that way, that the memory has "X= 0 to 239 , Y= 0 to 319" as a fixed setup. When MV=1 is used writing beyond X = 239 seems possible on address level, but will be shown on the display in as overwritting from the left.
This in the end does not make too much sense, since only a part of the display is usable. It looks to me more like a way to cope with a wrong firmware setup...

Might also be a kind of firmware "base setup" of the ILItek drivers. Also other drivers seem to have this register (page 112):
https://www.waveshare.com/w/upload/7/78/ILI9486_Datasheet.pdf

Unluckily, I don't have a real display at hand.

This in the end does not make too much sense

Yes, that's what made me think that the memory space was always written the same way.

But in command Column Address Set (2Ah) (End of X) value at reset is:
If MADCTL’s B5 = 0: EC [15:0]=00EFh
If MADCTL’s B5 = 1: EC [15:0]=013Fh

And Page Address Set (2Bh) (End of Y):
If MADCTL’s B5 = 0: EP [15:0]=013Fh
If MADCTL’s B5 = 1: EP [15:0]=00EFh

Unluckily, I don't have a real display at hand.

Me neither.
That's the only way to really know what it does in each case.

These functionalities are not used in most cases.
But I would like to implement them eventually.
This talk is helping me to get a better idea of how it works.

It would be great to have the RGB <-> BGR switching implemented. Some of the libs do use RGB. The used from the student sent 0xF8 0x00 but instead of red, I got blue...

When zooming into the screen it looks like BLUE pixels are moved one pixel to the top. It is a kind of strange.

See https://wiki.mexle.org/_media/blog/020122_output_in_100.jpg?t=1641159299&w=500&h=108&tok=a871fd

Additionally I seems that i have to send the bits as bbbbbrrrrrrggggg (Blue Red Green), I thought they need to be RGB..

The (RGB corrected) hex is attached.

When zooming into the screen it looks like BLUE pixels are moved one pixel to the top. It is a kind of strange.

Yes, I noticed it.
Not sure if this is related to the "EndY" error.
I will have a look.

It would be great to have the RGB <-> BGR switching implemented.

Ok, I will do this one, this I understand (hopefully)  

Additionally I seems that i have to send the bits as bbbbbrrrrrrggggg (Blue Red Green), I thought they need to be RGB..

There are 2 modes, but always RGB (RGB <-> BGR not implemented yet):
- 16 bits format: RRRRRGGGGGGBBBBB
- 18 bits format: RRRRRR00GGGGGG00BBBBBB00

Some of the libs do use RGB. The used from the student sent 0xF8 0x00 but instead of red, I got blue...

Maybe the lib is using 18 bit format (3 bytes)?

Source code and circuit for a simple example with the library you are using would be helpful.

I wil try to implement Memory Access Control (36h) command.
This one defines all the suff we talked about rotating, RGB/BRG, etc

No, I'm using the 2 bytes format.

You can find the adjusted lib for simulide 1.0.0 here:
https://wiki.mexle.org/microcontrollertechnik/ili93541-ansteuerung#beispiel_lib

I had to correct the color as bbbbbrrrrrrggggg, see ili9341.h:
#define RED 0b0000011111000000

The color is used in ili9341.c, see function ili9341_splashscreen() and ili9341_settextcolour(). This part of the lib is similar to the original Code i found in the web..

What I found by now:

void ili9341_init(void)
ili9341_send_multiple(2,ILI9341_CMD_MEMACC , 0x48); //memory access control

0x48: 0100 1000
bit3: BRG = 1

Oh dear.. You are right.
Sorry.

I dont have my laptop with me now. I will check it in the evening.

The funny thing is that it is changed again later, at least ili is receiving the command...
But don't know yet where it is changed.

I'm debugging it right now.
Give me a few minutes (hopefully) and I will come with more...

arcachofo wrote:The funny thing is that it is changed again later, at least ili is receiving the command...
But don't know yet where it is changed.

Yet another (silly) bug in simulide.

Another potential issue:

#define ILI9341_CMD_SET_FNC        0xB6    //    Display Function Control

void ili9341_init(void)
ili9341_send_multiple( 4 ,ILI9341_CMD_SET_FNC  , 0x08, 0x82, 0x27);        //display function control

This command has 4 parameters, so it should send 4+1 bytes:



Probably in a real device this is not a problem.
Simulide was expecting 4 parameters.
I changed the implementation so this issue don't make errors.

Finally I think this is working.

I implemented partially command 0x36: Memory Access Control:

MY: bit7, Row Address Order.
MX: bit6, Column Address Order.
MV: bit5, NOT IMPLEMENTED.
ML: bit4, Irrelevant  for simulation.
BGR: bit3, RGB-BGR Order.
MH: bit2, Irrelevant for simulation.

By now I'm not gona implement MV, it's a nightmare.

____________________________________________

arcachofo wrote:What I found by now:

void ili9341_init(void)
ili9341_send_multiple(2,ILI9341_CMD_MEMACC , 0x48); //memory access control

0x48: 0100 1000
bit3: BRG = 1

This command is also setting bit6 (MX) which makes X addresses go backwards.
I think it should be just 0x00.

____________________________________________


Remember that color definitions need to be reverted to RGB format (or use BGR).


EDIT: Fixes at Rev 783.

The 3byte <-> 4byte missmatch at "ili9341_send_multiple( 4 ,ILI9341_CMD_SET_FNC , 0x08, 0x82, 0x27)" is interesting: It also appears in both base libraries I had.
You are probably right, that the hardware might overlook this situation.

This hint is great, since sending an additional 0x00 not only solve the color problem, but also the "misalignment" of red and blue pixels!

Thanks!

This hint is great, since sending an additional 0x00 not only solve the color problem, but also the "misalignment" of red and blue pixels!

Yes, that was causing the missalignment, but now it will work without it.