resset

I'm glad it is working now:)

Assuming your wires/traces are not too long, this values should be ok, but you may still try to extend various phases of FSMC transactions ("slower timing" is not too precise term). Please look at page 1354 of RM0090 (STMF4xx datasheet) and figures mentioned there. For instance FSMC_BTR1_ADDSET_2 | FSMC_BTR1_ADDSET_1 gives 0110 in FSMC_BTR1_ADDSET and this means that FSMC assumes that after sending address, 6xHCLK cycles should be enough for LCD module to receive this address reliably. Configuration like this: FSMC_BTR1_ADDSET_3 | FSMC_BTR1_ADDSET_1 will make it to be 1010 which equals 10xHCLK (one could call it "slower" FSMC). This is similar with DATAST, BUSTURN and others. Checking hardware always helps:-)

Which version of gdisp_lld_board.h is the one you use, the one from ZIP or the one from your post? Because version inside ZIP has rather small delays introduced, try to use this code instead: /* FSMC timing */ FSMC_Bank1->BTCR[FSMC_Bank + 1] = (FSMC_BTR1_ADDSET_2 | FSMC_BTR1_ADDSET_1) \ | (FSMC_BTR1_DATAST_2 | FSMC_BTR1_DATAST_1) \ | FSMC_BTR1_BUSTURN_0;

At a first glance it looks like initialization problem. As far as I remember you use FSMC interface. Have you set your GDISP_RAM properly (in gdisp_lld_board.h)? Have you seen this file: https://bitbucket.org/Tectu/ugfx/src/a370394dbb0b/drivers/gdisp/SSD1289/gdisp_lld_board_st_stm32f4_discovery.h? Could you post init_board() content? Edit: I missed you zip file, sorry. Digging into this.

Now I see. The problem appears when you try to do this: gdispSetOrientation(GDISP_ROTATE_90); create_button(); // or whatever that draws button with text gdispSetOrientation(GDISP_ROTATE_0); Tectu: what should be done/executed to handle this type of operation properly? Some gwinResize/gwinRedraw functions maybe?

I've just run your code and it works well up tp this point: display changes orientation form 0 to 90 and button "OPEN" (create_button) is properly drawn. (After clicking the button app hangs, but maybe it's because I refused to provide memcpy to uGFX;)) I have newest uGFX and ChibiOS/RT possible. Do you get any strange warnings during compiling? Do you have your gfxconf.h and board files up to date?

Does it work? Generally, one should read Tectu's post again: either of these two addresses should have 0x60000000 as a 'base'. Usually you set GDISP_REG to 0x60000000 and GDISP_RAM to (0x60000000 | flag), where 'flag' is a mask that says to which pin is your RS line hooked. For example, in SSD2119 I have RS (DC) pin on FSMC_A19, so I set GDISP_RAM to 0x60100000.

I had similar issue on different driver. Please check how do you initialize FSMC, especially BTR register. The reason of such behaviour can be too short delays introduced by FSMC. For instance, I'll show you how was it in my case (STM32F4): This was losing/misplacing pixels: FSMC_Bank1->BTCR[FSMC_Bank + 1] = (FSMC_BTR1_ADDSET_2 | FSMC_BTR1_ADDSET_0) \ | (FSMC_BTR1_DATAST_2 | FSMC_BTR1_DATAST_0) \ | FSMC_BTR1_BUSTURN_0; And this works OK: FSMC_Bank1->BTCR[FSMC_Bank + 1] = (FSMC_BTR1_ADDSET_2 | FSMC_BTR1_ADDSET_1) \ | (FSMC_BTR1_DATAST_2 | FSMC_BTR1_DATAST_1) \ | FSMC_BTR1_BUSTURN_0; The reason may also be too long wires, but I'm not expert here.