1
\$\begingroup\$

I have an STM32F2 that has a "Flexible Static Memory Controller" (FSMC). For some reason, when I configure the Chip Enable (CE#) pin of my PSRAM as a FSMC pin, the STM32 will pull the pin low (by default the pin is pulled high with an external pull-up).

The reason I ask is because this CE# pulse maybe explain why the very first read/write operation fails on my PSRAM.

Why is there such a pulse? Does STM have detailed documentation for it's Flexible Static Memory Controller explaining this behaviour?

\$\endgroup\$
10
  • \$\begingroup\$ Do you configure the CE# pin with the normal GPIO configuration? In that case, it might help to set it high before you configure it as output (or before you configure it to be a FSMC pin). \$\endgroup\$
    – hli
    Commented Jul 25, 2012 at 9:00
  • \$\begingroup\$ I do not configure the CE# pin as output, I configure it as "Alternate Function FSMC". \$\endgroup\$
    – Randomblue
    Commented Jul 25, 2012 at 10:03
  • \$\begingroup\$ But configuring it that way implicitly configures it as output (since FSMC_NE[x] must be an output). But when that happens, AFAICS the value of the output data register gets written to the output. Try setting the value there to 1 before configuring the pin. \$\endgroup\$
    – hli
    Commented Jul 25, 2012 at 10:12
  • \$\begingroup\$ Ah, got you. I tried that, but I still see this pulse when calling the function GPIO_Init. \$\endgroup\$
    – Randomblue
    Commented Jul 25, 2012 at 10:32
  • \$\begingroup\$ Is GPIO_Init() something you have written by yourself, or is it part of a library? Could it be that it sets its own state for the output pin? (I was assuming that you do the configuration by writing to all of the registers manually). If it's your code, can you post it? \$\endgroup\$
    – hli
    Commented Jul 25, 2012 at 11:02

2 Answers 2

3
\$\begingroup\$

It looks perfectly normal to have \$\mathrm{\overline{CE}}\$ low for an external memory controller. The external memory will ignore all signals if \$\mathrm{\overline{CE}}\$ is high. \$\mathrm{\overline{CE}}\$ is often logically combined with the output of a partial address decoder to avoid several devices simultaneously accessing the databus.

You probably won't have pin conflicts with GPIO as long as you don't change the pin's function from FSMC to GPIO.

\$\endgroup\$
6
  • \$\begingroup\$ But is it normal to have CE# pulsed low before I make a read or write operation? \$\endgroup\$
    – Randomblue
    Commented Jul 25, 2012 at 10:33
  • \$\begingroup\$ @Randomblue - If by "pulsed" you mean going low and back high again, then no, that's not normal. It should go low as the start of the I/O operation, and stay low until it's finished. \$\endgroup\$
    – stevenvh
    Commented Jul 25, 2012 at 10:39
  • \$\begingroup\$ There is a pulse (low then back high again) when I initialise the pin (without any I/O). For I/O operations, it goes low and back high when it's finished, as expected. \$\endgroup\$
    – Randomblue
    Commented Jul 25, 2012 at 10:51
  • \$\begingroup\$ @Randomblue - the pulse looks harmless to me, and shouldn't affect subsequent actions. Shouldn't happen though, and IMO could be a hardware bug. \$\endgroup\$
    – stevenvh
    Commented Jul 25, 2012 at 10:54
  • \$\begingroup\$ You're probably right, but I'm investigating all options to find an explanation for this. \$\endgroup\$
    – Randomblue
    Commented Jul 25, 2012 at 10:57
1
\$\begingroup\$

I think this could be causing your issue, you should be able to have CE start out high when configuring the pin.
This sounds like it could be a small silicon issue, but getting any info from ST will probably be difficult (I just had a similar issue with SPI SS on an STM32F1, but the documentation is very misleading, the issue has been asked about on the ST forums for ~2 years and ST are yet to comment...)

Anyway, to test maybe you can keep the pin set as a normal GPIO and toggle it as necessary during a read/write. If the first operation succeeds like this then it looks like that's your problem.
Also (as hli suggests) if you haven't set the GPIO->ODR register before initialising the pin (whether you try it as AF or normal), try doing this (i.e. set ODR bit high so it hopefully starts out that way)
I did a similar thing with the SPI, controlling the SS pin in software.

\$\endgroup\$
2
  • \$\begingroup\$ That's a good suggestion (to drive the pin manually) but I'm afraid the timing requirements are too subtle that I would probably get them wrong. \$\endgroup\$
    – Randomblue
    Commented Jul 25, 2012 at 11:02
  • \$\begingroup\$ True - I was only thinking of it as a way to confirm the cause of the problem though, not to use as a solution. I think the "solution" would maybe be to just do the first R/W twice. \$\endgroup\$
    – Oli Glaser
    Commented Jul 25, 2012 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.