FMC NOR is extremely slow !

[ranran]

Hello,

I run the FMC nor example for stm32h743 eval, with the eval board, and I get very poor timing:

I used the original configuration , and only changed DataSetupTime   from 8 to 10 (with the original configuration, the test fails with my eval board ! ).

Yet, the write speed of NOR flash is extremely slow:

Writing 64KB took 3 minutes and 10 seconds --> speed is 360 B/sec !

Does it make sense that nor write is so slow ? Is it the HW write speed or ineffective write routine (or both) ?

Thank you,

ran

Is there any idea ?

Thanks

ran 

[ranran]

Hello Mohamed,

Thank you very much for the help.

Did you get to check why the NOR write speed is extremely slow ?

It is also observed in your above testing of 7 seconds.

Thank you,

Ranran

[Tesla DeLorean]

The H743I-EVAL NOR examples have multiple flaws and have not been properly validated. Some of the issues will only become apparent if larger data sets are used. Some of the functions don't appear to have any test coverage, and Hard Fault.

[DOsbo]

Hi, I've just run into this problem too. We have several STM32H753I-EVAL2 revE boards. They supposedly have MT28EW128 Parallel NOR Flash. It's so slow, it's unusable. OpenOCD times out when loading just a small application.

The STM32CubeProgrammer can erase/write to the NOR Flash, but can't read it. When it reads it misses the lower byte that's on the bus. If we ignore that for the moment, it seems the erase/write is quite fast. That implies there is nothing wrong with the design. I'm wandering (=)) if we can reverse engineer the STM32CubeProgrammer to determine its settings. Unfortunately, I don't think my OCD skills are up to the task.

It's disappointing to hear ST doesn't have any test coverage here. These boards cost over $400USD, so it's not too unreasonable to expect them to work with the support code.

Cheers,

David

[ranran]

Hi David,

Let me share with you how I've resolved it, maybe it will help.

Check function

void HAL_NOR_MspWait(NOR_HandleTypeDef *norHandle, uint32_t Timeout)
{
  uint32_t timeout = Timeout;
//ranran
 
 
  /* Polling on Ready/Busy signal */
  while((HAL_GPIO_ReadPin(NOR_READY_BUSY_GPIO, NOR_READY_BUSY_PIN) != NOR_BUSY_STATE) && (timeout > 0)) 
  {
    timeout--;
  }
  
  timeout = Timeout;
  
  /* Polling on Ready/Busy signal */
  while((HAL_GPIO_ReadPin(NOR_READY_BUSY_GPIO, NOR_READY_BUSY_PIN) != NOR_READY_STATE) && (timeout > 0)) 
  {
    timeout--;
  }  
}

I've noticed that on reducing timeout value, the read/write test still works without any issues.

Try reducing the values.

I can't say I understand the meaning of this routine, and and the need to wait on discrete pins(?) from NOR flash. Maybe someone who understand it can give more information.

Thanks,

ran

[DOsbo]

Hi Ran,

Thanks for replying. You're in the right area, but have the wrong fix. There are two issues I can see:

1. The timeouts provided in stm32h743i_eval_nor.h are based on the CPU clock. However they have not been adjusted for the faster H7. They need to be increased but it doesn't have a major impact on the operation.
2. The main issue is the port pin assigned to the READY/BUSY signal on the NOR Flash is incorrect. The firmware has it as C6 when it should be D6. It's an easy change to stm32h743i_eval_nor.h

#define NOR_READY_BUSY_GPIO   GPIOC  // wrong
#define NOR_READY_BUSY_GPIO   GPIOD  // correct

I don't want to step on Clive's toes, so I'm just posting the fix here. Clive also said there were more than one issue with the NOR Flash code.

Cheers,

David