STM32 FSMC and LCD problem - processor hangs!

Hi.

Originally I made a project controlling a 7" LCD connected to an STM32F103ZGT6. Though suddenly it had stopped working and it is only working once in a while (very unstable).

I have reverted every changes made since it was working, but it still doesn’t work. I have an RLink debugger, and the LCD never finishes the initialization, as it hangs when it tries to write to the FSMC RAM.

So I definitely think it’s a FSMC related problem, but sometimes it works and other times it doesn’t. It worked in the debugger once, but when I then ended the debugging and just reprogrammed the STM32, it didn’t work. Though the “refresh rate” of the LCD is much slower, when it sometimes works, than it was when it worked without any problems!?

Sometimes I also get an error from the RLink, telling me that the processor had stopped responding, and then it quits debugging.

I’ve done some more debugging, and the the STM32 hangs when I try to write to the RAM of the FSMC, where the LCD is connected.

It can initialize the FSMC and GPIO fine, and it can write to the Register (LCD->LCD_REG), but when I try to write to the RAM, it hangs (LCD->LCD_RAM).

This is my definitions of the LCD FSMC port:

typedef struct

{

__IO uint16_t LCD_REG;

__IO uint16_t LCD_RAM;

} LCD_TypeDef;

/* Note: LCD /CS is CE4 - Bank 4 of NOR/SRAM Bank 1~4 */

#define LCD_BASE ((uint32_t)(0x60000000 | 0x0C000000))

#define LCD ((LCD_TypeDef *) LCD_BASE)

I’m using the STM3210E-EVAL board with the STM32F103ZGT6 processor.

The project can be downloaded here: http://www.tkjelectronics.dk/GUI_Application.zip

I’m really looking forward to an answer :slight_smile:

Best Regards

Thomas Jespersen

if your hardware is still a prototype, check cabling, grounds, power supplies,…

Angelo

Polux rsv:
if your hardware is still a prototype, check cabling, grounds, power supplies,…

Angelo

The hardware is a prototype, yes, but I have checked cabling and such. But when fx measuring the FSMC signals, nothing is generated.

It’s a problem with the processor, and I think I’ve found out why it happens.

The problem occours when using the new StdPeriph library (STM32 driver), V3.4.0. When I switched to the older, V3.1.2, everything worked fine, no FSMC problems at all!

So there might be a problem with FSMC in V3.4.0 of the StdPeriph_Driver library.

Best Regards

Thomas Jespersen

This caught me out aswell :slight_smile:

FSMC_AsynchronousWait member was added to FSMC_NORSRAMInitTypeDef in 3.4.

It is mentioned in the release notes.

For info we have a hardware platform based on the same combo:

http://www.youtube.com/watch?v=SiGuGaEDeC8

Cheers

Spen

ntfreak:
This caught me out aswell :slight_smile:

FSMC_AsynchronousWait member was added to FSMC_NORSRAMInitTypeDef in 3.4.

It is mentioned in the release notes.

For info we have a hardware platform based on the same combo:

http://www.youtube.com/watch?v=SiGuGaEDeC8

Cheers

Spen

Yes, I contacted you last week about some questions about your products, as we might be interested in buying a couple.

Though one of your sales representatives responded to me, telling me that you won’t do business with anyone outside UK.

Best Regards

Thomas Jespersen

Oh,

To be honest we do focus on the uk market, so that probably makes sense.

Did my suggestion fix your problem?

Cheers

Spen

ntfreak:
Oh,

To be honest we do focus on the uk market, so that probably makes sense.

Did my suggestion fix your problem?

Cheers

Spen

Yes it did, thank you...

It is just me being inattentive - I should have read the release notes :slight_smile:

Thomas