Chibistudio example

[tronicgr]

Hi all,

I have a STM32F4-discovery board that I try to make it work with my SSD1289 LCD screen.

Resset lead me to a chibistudio example he had for a different screen , and after I changed all files for my screen I only get a blank white screen. The LCD works as it came with a Open107 development board and it displays fine the demonstration programs.

Is there available a complete example of STM32F4-discovery for Chibistudio and ugfx for that LCD? Nothing fancy, just display a hello message maybe.

I'm sure that even if I compiled the example I have, with no errors, I must be missing something...

Best Regards,

Thanos

[Joel Bodenmann]

Hello tronicgr and welcome to our forum!

I tested the SSD1289 driver myself two days ago and it still worked fine, therefore the issue must be somewhere else.

How is the display connected on your board? Is it a GPIO bit bang or does it use the FSMC interface of the F4? Can you attach the schematics of the board? I have some F4 discovery and an SSD1289 here, so I can try to hook one up to that board.

Also, what does 'black/white screen' exactly mean? Do you see anything or just a black screen and nothing at all?

And to answer your question: There are no ChibiStudio examples themself, sorry. But I am sure we can make this working without any problems

~ Tectu

[resset]

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.

Edited September 30, 2013 by Guest

[Joel Bodenmann]

This guide leaves some notes about getting the GDISP_RAM value set properly.

~ Tectu

[tronicgr]

Thanks for the welcome and the prompt replies!

what does 'black/white screen' exactly mean? Do you see anything or just a black screen and nothing at all?

The screen remains blank with white background, unless that is the backlight.

I'm trying to use the FSMC interface of the F4 as described in the connections guide but I'm not sure if it set correctly:

static inline void init_board(void) {

	#if defined(STM32F1XX) || defined(STM32F3XX)
		/* FSMC setup for F1/F3 */
		rccEnableAHB(RCC_AHBENR_FSMCEN, 0);

		#if defined(GDISP_USE_DMA) && defined(GDISP_DMA_STREAM)
			#error "DMA not implemented for F1/F3 Devices"
		#endif
	#elif defined(STM32F4XX) || defined(STM32F2XX)
		/* STM32F2-F4 FSMC init */
		rccEnableAHB3(RCC_AHB3ENR_FSMCEN, 0);

		#if defined(GDISP_USE_DMA) && defined(GDISP_DMA_STREAM)
			if (dmaStreamAllocate(GDISP_DMA_STREAM, 0, NULL, NULL)) gfxExit();
			dmaStreamSetMemory0(GDISP_DMA_STREAM, &GDISP_RAM);
			dmaStreamSetMode(GDISP_DMA_STREAM, STM32_DMA_CR_PL(0) | STM32_DMA_CR_PSIZE_HWORD | STM32_DMA_CR_MSIZE_HWORD | STM32_DMA_CR_DIR_M2M);
		#endif
	#else
		#error "FSMC not implemented for this device"
	#endif

	/* set pins to FSMC mode */
	IOBus busD = {GPIOD, (1 << 0) | (1 << 1) | (1 << 4) | (1 << 5) | (1 << 7) | (1 << 8) |
							(1 << 9) | (1 << 10) | (1 << 11) | (1 << 14) | (1 << 15), 0};

	IOBus busE = {GPIOE, (1 << 7) | (1 << 8) | (1 << 9) | (1 << 10) | (1 << 11) | (1 << 12) |
						(1 << 13) | (1 << 14) | (1 << 15), 0};

	palSetBusMode(&busD, PAL_MODE_ALTERNATE(12));
	palSetBusMode(&busE, PAL_MODE_ALTERNATE(12));

	/* 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;

	/* Bank1 NOR/SRAM control register configuration
	 * This is actually not needed as already set by default after reset */
	FSMC_Bank1->BTCR[FSMC_Bank] = FSMC_BCR1_MWID_0 | FSMC_BCR1_WREN | FSMC_BCR1_MBKEN;

	/* Display backlight control */
	/* TIM3 is an alternate function 2 (AF2) */
	pwmStart(&PWMD4, &pwmcfg);
	palSetPadMode(GPIOD, 13, PAL_MODE_ALTERNATE(2));
	pwmEnableChannel(&PWMD4, 1, 100);

}

Thanks,

Thanos

[Joel Bodenmann]

We need to have the schematics of your hardware in order to check your board file.

~ Tectu

[tronicgr]

The schematics and pin description of the LCD can be seen here:

http://www.wvshare.com/product/3.2inch-320x240-Touch-LCD-A.htm

And its connected for FSMC like in the connections guide here: http://ugfx.org/gdisp/interface

I use a STM32F4-Discovery board so the FSMC connections are exactly as in the guide.

Thanks

Thanos

Edited September 30, 2013 by Guest

[resset]

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;

[tronicgr]

Hi Resset,

The timings you posted are the same I use right now (in the zip file and in the piece of code I posted). :roll:

How I set slower timing? I'm not familiar with the meaning of these bits and what should change for slower operation:

/* 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;

[tronicgr]

I'll double check the wiring between the STM32F4-Discovery board and the LCD once again to make sure, and I'll get back to you if I get any response.

Thanks

[resset]

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:-)

[tronicgr]

Well. I didn't had a camera around in the lab and used one of the test phones... :lol:

You can see how long are the wires:

[tronicgr]

I have great new... I guess I must messed up my wiring before. Rewired everything double checking every single connection and voila:

[Joel Bodenmann]

Nice to hear that you got it working!

Good luck with the SPI - the forum will always be there

~ Tectu

[resset]

I'm glad it is working now:)

[dm13dv1b]

Dear members! I've some problem with the SSD1289 and the STM32F4Discovery with FSMC. I've double checked the wiring but I guess I have some timing problems. I've made a video: http://youtu.be/TfZJQ1cZm9U

After reset it turns darker with some lines. I've checked the lines with a logic analyzer and the data flows. Have you ever seen problem like this? Thank you!

[inmarket]

It is pretty hard to tell from the video however it appears it might be a problem with the back-light or with the display not being driven.

Close visual inspection might help you determine which is happening.

• For a back-light issue: At reset it appears the backlight turns full on and then partially fades out leaving horizontal bars. Check the black-light is set to 100% and this is done as a solid logic level drive rather than a PWM signal. A PWM signal to the back-light at too high a frequency might cause this behaviour. If it is definitely the backlight but not a PWM issue then there is a hardware fault with the LCD panel.
  
• If it is not the back-light: It appears as if the display might not being driven at all. That explains the "fade" affect as the capacitance on the display charges or discharges. Perhaps the display is still in the "OFF" state or the address you are using to talk to the display is incorrect. Check the board file for the display matches your physical display connection. Double check that the display controller is what you think it is and that it matches the driver you are using. There are many E-Bay purchased displays that are mis-labeled with regard to their controller chip. Also, because physical line length to the display significantly affects timing, use the shortest possible connections between the display and your board. In your board file also choose the most conservative timings possible at least until you have the display operational.

Hope that helps.

[dm13dv1b]

Thank you for your answer! I'll check these!

[dm13dv1b]

I checked everything from wiring to board files and it was absolutely my fault

No it's working as expected. The FSMC timing was the key.

As I see some people use this configuration so I think someone should make an example for this combo (STM32F4Discovery+SSD1289).

I'm not a good programmer just a hobbyist so I'm not the perfect man for this But I will put my working project to github.

Thank you for your help. Next week I have to change the orientation of the LCD and I will try to get the touch panel working.

Have a good weekend

[inmarket]

Send us your board file and/or the link to your repository and I will add it ti the official ugfx repository as either a full board definition or in the boards/addons directory.

It is a pleasure to help where we can. Well done on getting it going.

[fastlink30]

no news on repository?

[dm13dv1b]

Here it is:

https://github.com/dm13dv1b/STM32F4_Chi ... chtest.git

STM32F4Discovery, SSD1289, ADS7843

[fastlink30]

i tryed to use this example to complete my source code, i have copied the file board_SSD1289.h & gdisp_lld_SSD1289.c as explained in the read.me file (ginput_lld_mouse_board.h missing, so i have used another found in the c:\ChibiStudio\ugfx\boards\base\Olimex-STM32-LCD\ directory), modified the makefile (looked your original, and changed mine)

but when i compile i had this errors:

In file included from c:/ChibiStudio/ugfx/drivers/gdisp/SSD1289/gdisp_lld_SSD1289.c:16:0:

c:/ChibiStudio/ugfx/boards/addons/gdisp/board_SSD1289_stm32f4discovery.h:27:1: error: unknown type name 'PWMConfig'

c:/ChibiStudio/ugfx/boards/addons/gdisp/board_SSD1289_stm32f4discovery.h:29:3: warning: excess elements in scalar initializer [enabled by default]

c:/ChibiStudio/ugfx/boards/addons/gdisp/board_SSD1289_stm32f4discovery.h:29:3: warning: (near initialization for 'pwmcfg') [enabled by default]

c:/ChibiStudio/ugfx/boards/addons/gdisp/board_SSD1289_stm32f4discovery.h:30:3: warning: excess elements in scalar initializer [enabled by default]

thanks

[Joel Bodenmann]

The errors you are getting is because your board file ueses the PWM peripheral of your microcontroller but you didn't enable it in your ChibiOS/RT configuration. You have to enable the PWM peripheral in your halconf.h and you then have to enable the corresponding PWM driver in your mcuconf.h.

Which readme told you to copy the board_SSD1289.h & gdisp_lld_SSD1289.c sources? That is completely wrong. The only thing that you copy into your project directory is the board_SSD1289.h.

~ Tectu

[fastlink30]

ok, now i can compile, thinked i have ctivated the pwm in halconf.h, but not

the read.me present on the repository that dm13dv1b write, with example to use uGFX with ssd1289 & chibios

i hope he see this & add also the ginput_lld_mouse_board.h file on repository

thanks