製品開発で個人的に初めてNANDフラッシュROMを採用し、設計で苦労したので、
自戒の念を込めて注意点を書かせていただきます。
（１）NORフラッシュROMの採用を検討する。
（２）NANDに合った演算チップを選定する。
（３）代替ブロック利用、ウェア・レベリング処理を検討する。
（４）NANDで最初に起動されるブートプログラムはブロック０に配置する。
（５）ROMライターにバッドブロックマークの検出をさせる。
（１）NORフラッシュROMの採用を検討する。
NANDはNORより集積度が高いですが、これから書くような課題を内在し、費用と工数が発生します。
保存するデータ量、組み込み筐体スペース、トータルでペイするかの観点から、NORの採用をまずは検討してみるべきでしょう。
費用は組み込み機器本体の開発以外に、ROMライターのソフト更新でも発生します。
これらがNAND採用による部品コストダウンより大きいかを比較する必要があります。
NANDはかなり面倒なデバイスだと思うので、使わないで済むならそれに越したことはありません。
（２）NANDに合った演算チップを選定する。
NANDはビットエラーが発生するため、対策として誤り訂正（Error Correcting Code=ECC）が必須です。
ECCの要求仕様はNANDの微細化に伴い、高度化（多ビット化）しています。
ECCの実装方法にはOn-Die、Hardware、Softwareの３つがありますが、
NANDに対応した演算チップを選定し、Hardwareの機能によりECCを実現するのが主流です。
On-Dieは現在、ほとんどないようです。
Softwareは処理負荷が高くなるのと、その演算チップでメーカー保証が受けられない改修になる可能性が高いのが難点です。
私は見事にこのステップを飛ばしてしまい、後からソフトで対応することになりました。
チップメーカーの保証外の機能を使うことになり、メーカー提供ツールのバグもあったりして、
非常にヒヤヒヤする開発をする羽目になりました。
（３）代替ブロック利用、ウェア・レベリング処理を検討する。
ECCの能力を超えるエラービットが発生した場合、そのブロックはバッドブロックとして利用不可になります。
バッドブロック発生時のために以下のような機能を主にソフトで実装する必要があります。
・代替ブロックを用意しておき、バッドブロック発生時にはそちらから読み書きするようにする、
・読み書きの回数が特定ブロックに偏ることによりバッドブロックになりやすくなるのを避けるため、
アドレスをローテーションさせる（ウェア・レベリング）
（４）NANDで最初に起動されるブートプログラムはブロック０に配置する。
ブロック０は工場出荷時にバッドブロックなしが保証されています。
よって、最初のブートプログラムをブロック０に配置することで製品組み上げ時には確実に起動することが保証されます。
そのためにはブートプログラムは１ブロック分以下のサイズである必要があります。
起動以外に使う保守用の機能などはブートプログラムと分けたほうが良いでしょう。
私はブートプログラムが１ブロック以上のサイズになっており、
不要な機能を見極めてソースコードを整理するのに苦労しました。
始めからサイズを考慮して設計をしておくべきでした。
（５）ROMライターにバッドブロックマークの検出をさせる。
NANDの工場出荷時にバッドブロックだったブロックは、バッドブロックマークが付与されています。
ROMライターソフトではバッドブロックマークを検出し、書き込みをしない処理が必要になります。
この場合は初めから代替ブロックを使うことになります。
初心者が調べ調べして、ようやく開発を乗り切ったという状況ですので、
ご指摘などあれば是非お願いいたします。