FSMC SRAM Example bug

[ccowdery9]

Posted on April 07, 2009 at 02:10

FSMC SRAM Example bug

[michaellane9]

Posted on May 17, 2011 at 13:02

Hi,

Just wondering if anyone can shed any light on why this member existed in the FSMC_NORSRAMInitTypeDef struct in the first place - because as far as we could tell from the STM32F10xxx Reference Manual the external wait signal is only available for synchronous burst mode (section 18.5.6 ''NOR/PSRAM controller registers'')? ST online tech. support have also confirmed that the NWAIT pin is only available in synchronous and not available in asynchronous mode. Was the intention different at some point?

[sjo]

Posted on May 17, 2011 at 13:02

For info the FSMC_AsyncWait member has been removed in the latest stm32 libs.

Regards

sjo

[ccowdery9]

Posted on May 17, 2011 at 13:02

There appears to be a bug in the FSMC demo, specifically \examples\FSMC\SRAM.

The initialisation of the FSMC controller is via a populated structure FSMC_NORSRAMInitStructure, which is initialised in

void FSMC_SRAM_Init(void)

in fsmc_sram.c

Unfortunately the field .FSMC_AsyncWait is not initialised, so it could contain random garbage. This causes a garbage initialisation of the FSMC and as a result random HardFaults when the memory area is accessed later on....

This line needs to be added, to ensure _all_ fields are initialised:

FSMC_NORSRAMInitStructure.FSMC_AsyncWait = FSMC_AsyncWait_Disable; // MISSING FROM SAMPLE SRAM CODE!!

Chris.

[jj_it]

Posted on May 17, 2011 at 13:02

@sjo-

Thank you!

Really great, precisely detailed post - valuable to many - much appreciated.

Second sjo's request for ST comment...

[sjo]

Posted on May 17, 2011 at 13:02

It was last mentioned in rev 4 of the stm32 ref manual - bit 15 of the control reg (FSMC_BCRx).

=======================================================================

Bit 15 ASYNCWAIT: Wait signal during asynchronous transfers.

This bit enables the FSMC to use the NWAIT signal, even during an asynchronous protocol. In such

a case FSMC takes the value into account and waits until it is de-asserted before closing the

access.

0: NWAIT signal is not taken into account when running an asynchronous protocol (default after

reset)

1: NWAIT signal is taken into account when running an asynchronous protocol

=======================================================================

As to why it is now not supported i have no idea - perhaps ST can give us more info ????

Cheers

sjo

[michaellane9]

Posted on May 17, 2011 at 13:02

Thanks for that sjo.

That also explains the references to the mysterious bit 15 in tables 76, 78, 81, 84, 87 and 90 in Rev. 8 of the reference manual.

Regards,

Mike