Can i interface an external nand flash with a STM32F103VBT6?

[siddj]

Posted on January 07, 2009 at 18:21

Can i interface an external nand flash with a STM32F103VBT6?

[siddj]

Posted on May 17, 2011 at 12:57

I have to interface a external nand flash chip with a STM32F103VBT6. All the documentation on the ST's website shows that you need to use FSMC peripheral which is only available in high density devices the ''STM 32F 103 E'' series.

Is it not possible to interface an external nand flash with the medium density chips the STM32F103 VB? (100pins)

[16-32micros]

Posted on May 17, 2011 at 12:57

Hi,

Yes, you can but you have to implement the low level driver using Bit-Banging with GPIO and DMA to drive the NAND flash signals, Here is an app note with STR710 that can help you to understand what you have to implement

http://www.st.com/stonline/products/literature/an/11974.pdf

Cheers, STOne-32.

[relaxe]

Posted on May 17, 2011 at 12:57

See the STM32F103VBT6 datasheet.

1) Pin description does not talk about the FSMC 2) Page 9 table 3 is pretty clear Short answer: No. Long answer: Yes, you can interface an external memory and drive it by yourself (using all necessary pins as GPIOs and coding your own driver). Doing this will be a lot slower than a real FSMC peripheral, will require a lot of ram/rom code to drive, and in the end, will save you about 2$ per board to redeem your hard work instaed of taking the easy route of the STM32F103VET6. Of course, a NAND software library could exist out there to reduce your design time.....

[siddj]

Posted on May 17, 2011 at 12:57

Thanks for your reply,

where can I get an access to the NAND Software library that you are talking about? Thanks.

[siddj]

Posted on May 17, 2011 at 12:57

Is there a guide on how i actually implement the bit banging?

Also GPIO's from what i understand can either be General purpose or can be used as AF which have a default predefined function ex, SPI,uSART etc. How can I possibly use these GPIO's to drive memory signals then? Please please help!

[siddj]

Posted on May 17, 2011 at 12:57

Thanks a ton for your reply. Is the Bit-Bang Memory management software the same as the memory management software? That's what i got from google. Also the chip i am writing to is an 8 bit Micron NAND flash.

I can only imagine that it's going to be a pain to configure all this, but that's the board that I have gotten to work on, with the ''wrong chip'' My boss is considering changing the chip. Thanks a lot and if you can, please give me the link for the memory mangement software. Also any other tips are more than welcome.

[jj]

Posted on May 17, 2011 at 12:57

Often agree with relaxe - his comment about the merits of your objective are the same as mine. (much work - larger, more complex pcb, minimal final payoff)

Bit banging guide: a) based upon your memory chip you need to dedicate bi-directional I/O to allow transfers micro to/from memory b) in addition - you need to dedicate one-way (output I/O) to the address lines of the external memory chip c) finally you need to dedicate one-way (output I/O) to the various control lines of the external memory chip Assuming a 16 bit wide memory this will total in excess of 40 I/O. You can gain some simplification by selecting a memory chip with multiplexed address/data lines - reducing the micro to memory interconnect. d) Bit-Bang Memory Mangagement Software: this is the major deal breaker - imho. Should you choose a 16 bit wide memory you will devote one entire STM32 port to data. You will require an additional 16 bit wide port for the lower 16 addresses - and yet another port for those address bits in excess of 16! You may be able to use this same port to generate the control lines needed by the memory - again you've ''eaten'' 3 - 16 bit ports! The major weakness is when you attempt to transfer data - ALL via software bit-banging. (port banging in this case) Here's one method: a) present 16 bit data to the memory's data port b) present 16 bit data to the lower 16 bits of the memory chip address c) present the ''higher memory address bits'' to the memory d) insure the control lines are proper (CS, RD, WR, others) e) strobe the WR or RD lines to effect the transfer (this process has achieved a ''single'' 16 bit transfer) f) now you must increment/decrement the 16 bit ''low address port'' watching for ''overflows'' which will affect the ''high address port'' g) and now you can effect your 2nd data transfer Perhaps someone brighter than me can simplify - believe I have the essence for you. Big question is ''Why do this?'' Suggest instead that you choose an FSMC STM32 device - many, many on this forum ''begged'' for them - they eliminate this ''pain and suffering!'' Read the data sheets carefully - there are 100 pin FSMC devices which may be able to work for you. (may have to choose different memory type)

[jj]

Posted on May 17, 2011 at 12:57

Sounds as if this is one of your early projects - I doubt that any ''official'' bit-bang, Micro to parallel Memory software - exists. What relaxe & I were describing is a general, ''method of attack.'' Due to the vast number of micros - and memory chips - it is difficult to develop a basic program that will satisfy all.

In the old days - when micros did not have ''on-chip'' memory - we had no choice but to route the micro's dedicated address and data bus to the corresponding pins of the memory. And - the micro automatically managed the address lines and all of the control strobe signals. Now you will be charged with doing ALL of this. Not easy and it is doubtful that this effort can be properly managed and made predictable. ST invested much to develop FSMC - they know what they're doing - you are being tasked with ''reinventing the wheel!'' ST's ''wheel'' is new, shiny, true, tested and affordable. Suggest that you show your manager ST's newer ''EVAL-''E'' board (with neat TFT AND external flash memory) and focus on your application & ease of use.

[relaxe]

Posted on May 17, 2011 at 12:57

Hold on a second...

You plan on using a 8-bits wide flash chip? Could you please specify what model/part#? What do you intend to do with the flash? Run code on it? Store various logs? What speed do you think you'll need (''As long as it Read/Write''? Continous 1K/sec, blazing fast video stream recording?) Because choosing a 8-bit part on a 32-bit MCU is kind of non-optimal for most applications. -Either you need a small but fast storage, in wich case I would recommend using a part of the MCU rom as storage -either small storage with slow acess to do datalogging, and I would recommend the Atmel's Dataflash or any SPI/I²C based flash/EEPROM chips. -If you need a huge storage, use a SDCard over SPI. The Code is out there. -And then, only then, if you need medium/large storage with ultra-mega-lightning-fast read/writes, you need a =16/32bits-wide flash chip=, not a 8-bits. And then, I smell somebody with a specific board with a MCU soldered-on, and just changing for a 15$ pin-compatible MCU requires more tools and/or skills than what you have. TQFP is scary, I know, but you can solder/remove such chips. see the SparkFun site tutorial's, plenty of tips and tricks for low-cost high quality prototyping. I had to replace a STM32F103ZE twice last month, and it was pretty easy by cutting the chip loose with a dremel, then soldering with a big tip iron and lots of solder braid. Of course, a steady had and a bit of practice on any junk electronic is the key to sucess in these surgery. Try it, and if you don't feel confident enough, spare some cash for a professional in your area. And now, my final warnings: BitBanging is easy on the paper. It's like a 5 to 10 steps loop. You can see the diagrams as nice one-page wide flowcharts in the flash datasheets. Implementing is not as easy as it looks like, as the devil is in the detail. It all start with the word ''Timing'' and ends with ''mostly into specs''. You will encounter various timing issues, error not covered by you code, etc. Now, just figure you want to read/write the chip... wich part of the code you do first? You can not even test your routines without an actual memory programmer. You will never know if your read routine works, until your write works. Then, what if you write works well, but your read is broken? It's very hard to diagnose. Just for fun, google around for USART bitbanging forums for MCU without hardware usart, you'll then know what kind of sorcery is involved... ofr a very very very easier and simpler protocal. Doing this is feasible, but please, really really really really consider: 1) Switching chip with a pin-compatible drop-in with FSMC. 2) Changing your flash strategy, and use an easier interface like SPI flashes or SPI SDCards. [Warning! Dubious car analogy follows!] Writing a bitbanging flash routing is kind of like pimping a 40K$ Camaro with 40K$ (and lots of time), instead of just buying a 70K$ Corvette from the start. -Relaxe