FSMC NOR and LCD Issue

[tkjmail2]

Posted on April 22, 2011 at 14:57

FSMC NOR and LCD Issue

[Tesla DeLorean]

Posted on May 17, 2011 at 14:32

If things are seizing up, then you should probably pay very close attention to the wait state generation via PD6/NWAIT. How it's wired, how it's configured, and how it's behaving. It looks to anticipate that this pin is configured as an input/pulled high (ie driven from a shared OC driver on the assorted externally bussed memory devices).

Consider also if the DMA to drive the LCD is fired up before the external bus and devices are all configured. This might explain why enabling address pins appears to cause the seizure event, perhaps that presents a different address to an external decoder/device, via a background DMA event. Call your ST FAE and discuss this with them. UK offices would almost certainly be closed this Monday, and last Friday.

[tkjmail2]

Posted on May 17, 2011 at 14:32

No one knows the answer on this problem - or is the ST guys on vacation (easter)?`

Thomas

[tkjmail2]

Posted on May 17, 2011 at 14:32

Dear Clive.

Thank you for your response.

We are using the STM3210E-EVAL board, with the M29W128GL NOR flash.

Also we aren't using the DMA for the LCD controlling - we are writing directly to the register of Bank 1, SRAM 4 of the FSMC.

Must the two FSMC devices be initialized at the same time (right after each other)?As what we are doing currently is initializing the LCD first, do some LCD writing, and then initialize the NOR.

Best Regards

Thomas Jespersen

[Tesla DeLorean]

Posted on May 17, 2011 at 14:32

Must the two FSMC devices be initialized at the same time (right after each other)?As what we are doing currently is initializing the LCD first, do some LCD writing, and then initialize the NOR.

I'm just musing on possible issues based on memory/hardware lockup issues I've encountered in the past. Wait-States, or some dead-locked bus arbitration/sequencing scheme? Yes, I would say you'd want to initialize the whole subsystem first, before accessing either device attached to it. There could of course be some real hardware issues or errata going on here too, but you'd have to get the ST HW guys to start digging deeply into it. To start that process, I'd guess you'd need to get a customer facing FAE involved, with a clear demonstrable test case, who can walk it up the chain to the engineers who designed it. It sounds like you have the problem reasonably confined now, so hopefully ST can get some eyes on this, and at least look to see if it's just an initialization or pin state problem, or if it is something deeper.

[tkjmail2]

Posted on May 17, 2011 at 14:32

Dear Clive.

I don't think it's a hardware issue, as the two devices works fine when they are not used at the same time - individual projects.

The problem is that we have a design deadline in a couple of weeks, so who could we contact? Are we allowed to freely contact ST, or do they require payment for helping with theese issues?

Best Regards

Thomas Jespersen

[John F.]

Posted on May 17, 2011 at 14:32

You are using the STM3210E-EVAL board. In that design, the LCD chip select is tied to FSMC_NE4 (PG12). The FSMC_NOE and FSMC_NWE (read / write) signals are shared with the memory device(s).

Are you sure that you are not accidentally enabling both the memory and the LCD at the same time in your software? Do you need to make sure the chip select pins are set to inactive levels (high) before enabling them?

[tkjmail2]

Posted on May 17, 2011 at 14:32

Hi John.

Isn't the FSMC taking care of the Chip Select signals, only driving them low when doing something with the device/chip/LCD?

I think I scoped the CS signal, and noticed that it was low when trying to setup the FSMC bus for the NOR Flash.

Thomas

[John F.]

Posted on May 17, 2011 at 14:32

How should I know? Software is software, hardware is hardware, a pin is just a pin (GPIO).

You wrote, ''Actually the STM32 never comes to the FSMC initialization''. I was just suggesting that

your

software might be enabling more than one device simultaneously (by incorrectly configuring GPIO pins for example). If the FSMC is never initialised, I think it would be a little unreasonable to expect it to be ''taking care of the Chip Select signals'' .

[tkjmail2]

Posted on May 17, 2011 at 14:32

Yes, I don't think it has something to do with this either.

I think the problem lays in the initialization routine, somewhere in the Standard Firmware Library.

Best Regards

Thomas Jespersen