Skip to main content
Robert Kwan
Robert Kwan
Associate II
April 26, 2017
Question

IDW01M1 Wifi Sample Codes for STM32F411RE

  • April 26, 2017
  • 24 replies
  • 5417 views
Posted on April 26, 2017 at 07:24

Hello!

I recently bought the IDW01M1 WiFi expansion board 

and I am trying to have it working with the STM32F411RE.

However, from the examples in en.x-cube-wifi1_firmware.zip,

I can find the .bin file for STM32F401RE-Nucleo only

and so I tried to flash this WiFi_VCOM .bin to the STM32F411RE board.

I can see LED1 is green, so power is ok.

No other LED On, so module is ok?!

When I use Tera Term, I don't see any output and when I send 'AT', no 'OK' either.

So my question is that  F401RE .bin image cannot work directly on F411RE board please?!

Since I am still a newbie to this WiFi module, I am not sure if it will be easy to recompile the sample application for F411RE then?!

Any suggestion / comment is welcome.

Thanks & Best Regards,

Robert

#stm32f411re-wifi-idw01m1
This topic has been closed for replies.

24 replies

Show previous replies
Robert Kwan
Robert KwanAuthor
Associate II
June 7, 2017
Posted on June 07, 2017 at 02:17

So I tried to use the stm32f4xx_hal_cortex.c from the sample app instead,

but the compiled image would still have the HAL_SYSTICK_Config() be in the Discarded Input Sections.

And I have no idea on why it would be placed in the Discarded Input Sections please?!

Thanks & Best Regards,

Robert

Robert Kwan
Robert KwanAuthor
Associate II
June 8, 2017
Posted on June 09, 2017 at 00:43

Hello!

I would like to ask if the parameter unit for HAL_Delay() in the STM HAL driver is ms or us please.

After twisting my merged codes a bit more without using the mbed hal_tick.o,

I can have the WiFi module initialized ok now

but then my original code would not work anymore

because we use wait_ms() and wait_us() from the mbed driver,

which I cannot use anymore now...

I think that HAL_Delay() is taking the parameter as ms only?!

And if so, how can I implement something like for waiting for x us delay please?

Thanks & BR,

Robert

Gerardo GALLUCCI
Gerardo GALLUCCI
ST Employee
June 10, 2017
Posted on June 10, 2017 at 12:26

From

HAL_Delay() into 

hal.c file:

/**

* @brief This function provides accurate delay (in milliseconds) based

* on variable incremented.

* @note In the default implementation , SysTick timer is the source of time base.

* It is used to generate interrupts at regular time intervals where uwTick

* is incremented.

* @note This function is declared as __weak to be overwritten in case of other

* implementations in user file.

* @param Delay: specifies the delay time length, in milliseconds.

* @retval None

*/
Robert Kwan
Robert KwanAuthor
Associate II
June 10, 2017
Posted on June 10, 2017 at 23:49

Hi Jerry,

Thanks for the confirmation.

I saw that too.

So my next question is any way to have us delay as in mbed implementation please?

If not, I still cannot use this module then.

It's pretty bad that after all the efforts to get it so close but still cannot use it.

Thanks & Best Regards,

Robert

Gerardo GALLUCCI
Gerardo GALLUCCI
ST Employee
June 11, 2017
Posted on June 11, 2017 at 12:00

I'm not familiar with that code. However, module is not requiring us delay. You can replace us with 1ms...

If cannot, this is a simple code waiting for us:

void udelay(u16 us)

{

volatile u32 loops = (SystemCoreClock / 1000000) * us;

while(loops--);

}
Robert Kwan
Robert KwanAuthor
Associate II
June 12, 2017
Posted on June 12, 2017 at 21:02

Thanks, Jerry.

I tried but it's still not working yet

and so I think that the UART driver difference may be the other source of problem to be debugged next...

In fact, I don't get any of the Wifi Indication message displayed at all

but I know that my Wifi initialization is still ok because I received the hardcoded data I sent.

So I suspect that the mixing of UART driver code is causing both the Wifi Indication message problem and my usart_print() problem now...

Thanks & BR,

Robert

Terms & ConditionsAccessibility statement