FSMC NAND

[barthess]

Driver for STM32 was added in latest trunk. Testhal application was added too.
@Giovanni
I need some help about porting to v3.
1)

Code: Select all

/**
 * @brief   Wakes up the waiting thread.
 *
 * @param[in] emcnandp  pointer to the @p EMCNANDDriver object
 * @param[in] msg       wakeup message
 *
 * @notapi
 */
static void wakeup_isr(EMCNANDDriver *emcnandp, msg_t msg){

  osalDbgCheck(emcnandp->thread != NULL);

  if (emcnandp->thread) {
    thread_t *tp = emcnandp->thread;
    emcnandp->thread = NULL;
    tp->p_u.rdymsg = msg;
    chSchReadyI(tp);
  }
}

/**
 * @brief   Put calling thread in suspend and switch driver state
 *
 * @param[in] emcnandp    pointer to the @p EMCNANDDriver object
 */
static void emcnand_lld_suspend_thread(EMCNANDDriver *emcnandp) {

  emcnandp->thread = chThdGetSelfX();
  chSchGoSleepS(CH_STATE_SUSPENDED);
}

Is this code correct for use with v3? I am talking about thread handling.
2) For testhal application I need time measurment instruments. What I must use instead of tmStartMeasurement() from v2.6

[Giovanni]

Hi,

Please, see my PM. Before adding major features to the repository the thing must be discussed beforehand.

About your question: there are osalThreadSuspendS(), osalThreadSuspendTimeoutS() and osalThreadResumeI() you could use for synchronization.

Giovanni

[barthess]

Please, see my PM

I have no new PM mail box.

the thing must be discussed beforehand

This thing was disscussed some time ago and tested in real hardware.
Anyway I understand I done this in wrong way. Could you write
short step by step guide for contributors? For example:
-fork branch
-develop
-describe featrue in special place of forum
-etc

[Giovanni]

I must have pressed the wrong button instead of SEND.

Anyway, the problem here is that before including major features there must be a discussion, I don't recall authorizing this EMC driver.

About the driver, I googled EMC and found nothing, what's that? the EMC driver does not even have an API, what is supposed to abstract?

Giovanni

[barthess]

EMC means "external memory controller". This featrue has different names on different MCUs. That name chosen to be more or less common (like EXTI vs EXT in smt32). Code contains basic initialization routines for EMC (FSMC in terms of stm32).

[Giovanni]

I see, but without an API it is just a way to initialize the FSMC, there is no abstraction because all the functionality is platform-dependent. This means that it should be a platform driver (STM32-specific) like RCC or DMA, a division in HLD and LLD is not even required, there is not even point in inventing a name, just call it FSMC driver.

The point of the HAL is to abstract some kind of common functionality and this seem not the case.

Different is the EMC-NAND but for that one I would object that what we would need is a generic flash driver, the fact that it is connected through FSMC should not be relevant, ideally a flash driver would abstract any kind of flash memories, whatever connected. Why do a driver for a nand flash connected through EMC, another for devices connected through SPI and so on.

A flash driver, in my opinion, should abstract:
- The transport, it should be transparent to the API.
- The sectors organization of the device connected, there must be an API for getting the actual device organization. This means some kind of mini-driver for each supported device.
- Extra features like ECC etc.

The special case of a specific flash type connected through a specific interface is not general enough for the HAL, it should eventually go in the devices_lib, note, there is already a flash directory in there.

Giovanni

[barthess]

Hiding FSMC initialization inside stm32 driver looks reasonable. I'll rework it.

Different is the EMC-NAND but for that one I would object that what we would need is a generic flash driver, the fact that it is connected through FSMC should not be relevant, ideally a flash driver would abstract any kind of flash memories, whatever connected. Why do a driver for a nand flash connected through EMC, another for devices connected through SPI and so on.

I understand your desires but they are very hard to realize in real life. We have 3 very different types of non volatile RAM.
NAND:
- erase only whole blocks
- read only whole page
- write only whole page
- has only parallel bus (FSMC). Any body know NAND with SPI bus?
- manufactured with some deffective blocks. Deffective blocks count increases during lifetime.
NOR:
- erase only whole blocks
- read byte
- write byte
- use parallel bus (FSMC) or SPI. But they are for different purposes
- has no deffective blocks
EEPROM (devices like 24AA):
- rewrite data (no need to erase)
- read byte
- werite byte
- r/w operations limited by 1 page in single transaction
- has no deffective blocks
- use SPI or I2C

Only SPI/I2C EEPROMs can be painlessly abstracted between themself. Huge NAND and NOR devices probably can be abstracted using some kind of file system (UFFS, F2FS, etc) but such layer is too RAM hungry for MCU (even for STM32F4x).

Extra features like ECC etc.

It is not hard to realize correction using hardware ECC inside driver. But better to realize this in user's application because default hardware ECC may be not strong enough (especially for MLC NAND).

The sectors organization of the device connected

No one IC I have used (or read about) provides any information about sectors organization. I heard about NAND contain such information but this is not mandatory.

[Giovanni]

I know the differences... there are drivers using both types I think, I will verify what the AUTOSAR driver does tomorrow.

Anyway, lets limit the discussion to NAND devices, lets name the driver simply "nand". Question, the devices are meant for storage, probably the driver should implement a block interface.

Giovanni

[barthess]

lets name the driver simply "nand"

Agree about high level drive. Low level I suppose to keep in 2 separate parts: fsmc_lld and fsmc_nand_lld

Question, the devices are meant for storage, probably the driver should implement a block interface.

Block interface to NAND looks challenging. I am not sure it can be realised RAM effective. We use it as one huge ring buffer for data acquired from sensors. Small region was used with UFFS for testing. I am not very impressed by this FS but it works more or less.

[Giovanni]

The FSMC is STM32-specific and does not belong to the portable HAL, there is no need to have a lower part.

Giovanni