[STM32F4 STM32F7] Overwrite HAL_Delay to allow SD example

[adustm]

The weak function HAL_Delay is overwritten to use mbed function
'wait_ms'.
Thanks to this, the user can use stm32f[4/7]xx_hal_sd.c that calls
HAL_Delay
This will allow us to add an example detecting / writing / reading an SD
card on DISCO_F469NI and DISCO_F746NG

(cherry picked from commit d491e3c)

[0xc0170]

wait_ms() is not yet here in HAL. It's in the common API, therefore we rather use what HAL provides. We can define our own internal wait_ms() for this:

#include "us_ticker_api.h"

static void wait_ms_internal(uint32_t ms)
{
    ms = ms * 1000; // us ticker operates on us
    uint32_t start = us_ticker_read();
    while ((us_ticker_read() - start) < (uint32_t)ms);
}

In the future, we should create common HAL implementation, for instance this wait_ms() could be moved there.

@adustm What do you think?

[adustm]

Hello,
I would prefer to use the already existing wait_ms than duplicate it.
I thought that if it is in common API, we could use it. I've seen it is used at several locations in mbed library.
What would be the impact of moving wait_ms in HAL ? If no impact, I think it would be good to move wait_ms there. Let me know if you want to move wait_ms or if I should duplicate wait_ms.
Kind regards,

[dinau]

Hello,

HAL_Delay() is impemented in stm32f4xx_hal.c as follows,

__weak void HAL_Delay(__IO uint32_t Delay)
{
  uint32_t tickstart = 0;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }

and HAL_GetTick() is incremented in hal_tick.c.
Why dose HAL_Delay() have to be reimplement using wait_ms() ?

dinau

[adustm]

Hello @dinau , It seems we are blocked in the while((HAL_GetTick() - tickstart) < Delay)
and that uwTick is never incremented. That's why I wanted to use wait_ms.
I'll try to figure out the reason why uwTick is not incremented.

[adustm]

Hello @dinau @0xc0170
I have a clearer view on the issue.
I have created a class for SD card, that calls HAL_Delay during its init phase. If I use a global variable for this class, it will be initialised at the RAM init, between SystemInit function and mbed_sdk_init function.
(refer to this example : https://developer.mbed.org/teams/ST/code/DISCO-F469NI_SD_demo/file/c802bce0ce54/main.cpp
SD_DISCO_F469NI sd; is a global variable )

At this moment, the timer is off (it is switched off at the end of SystemInit, and restarted in mbed_skd_init).
Then the HAL_Delay is stuck into a while loop while((HAL_GetTick() - tickstart) < Delay)
(because the timer is not incremented)

Using wait_ms instead of HAL_Delay initializes again the timer and restarts it. This is the reason why it solves the issue I have.

In case I use a local sd variable (inside the main function), the timer has been restarted by mbed_sdk_init and HAL_Delay works fine.

Could you let me know how you usually use a wait function between the SystemInit and the mbed_skd_init function, when timer is supposed to be off ?

[adustm]

Hello,
After an internal discussion within stm team, we think that the cleanest way of fixing our issue is to rewrite HAL_Delay function, as it is done in the PR.
The timer needs to be stopped during the RAM initialization.
It avoids us to apply a modification of the official STM Cube release.
It allows anyone to use global variables.
Please @0xc0170, could you proceed into merging this PR as is ?

Cheers
Adu

[0xc0170]

As I understand, you dont want to change HAL_Delay. Why not reimplement HAL_Delay as you did, but instead of using code from the upper layer, to just reinit ticker to get the same job done?

[dinau]

Hello @adustm @0xc0170,

If I use a global variable for this class, it will be initialised at the RAM init, between SystemInit function and mbed_sdk_init function.

Why is the global variable cleared "between SystemInit function and mbed_sdk_init function" ?
I think the system design like this is very weird.
STM team and we must reconsider this issue,
otherwise we would need "many workarounds" like this in the featur.
Probably the root cause would be alike as this ( I mentioned before about gcc ),
#1432.

dinau

[0xc0170]

@dinau Create an issue with this problem, and you can paste there the info you shared about GCC

[0xc0170]

@adustm What do we do, considering this is workaround for now. I am not in favour of using wait_ms in HAL for now.

[adustm]

Hello, sorry for the long silent period.
I just read again the #1432 comment.
This startup sequence is out of my scope... it's always been there. I consider it is normal to initialize variables between the system_init and the main... It has to be done anyway...
This is the reason why we have investigated a workaround.
What do you think ?
@0xc0170 , I'll check again how to avoid using the top level code.

[0xc0170]

@0xc0170 , I'll check again how to avoid using the top level code.

Any luck?

[adustm]

Hello, I just commited this new version that uses mbedhal instead of mbed common.
Let me know if it's ok.
Kind regards

[0xc0170]

Thanks, Lets merge this. Please @adustm create an issue why this was added