NUCLEO-F401RE and X-NUCLEO-IDW04A1 with X-CUBE-WIFI1 v3.1.1: demo application doesn't work out of box

[Mike Duffy]

Using the above hardware with IAR EWARM 8.11. I am working with a freshly extracted copy of your example code, specifically the STM32CubeExpansion_WIFI1_V3.1.1\Projects\Multi\Client_Socket project.

I made the following change to the project options. I changed SPWF01 to SPWF04 to reflect the actual hardware I am using. By default, this project uses the UART, since CONSOLE_UART_ENABLED is defined in the project options.

With no other change, the project behaves as expected, connecting to the specified access point, and interacting with the server.

BUT....

When I remove the define for CONSOLE_UART_ENABLED and rebuild (after changing the jumpers from the UART to the SPI configuration), the project hangs at the "Wi-Fi Initialized And Ready" message.

BTW, the X-NUCLEO board has the latest firmware on it, so that's not an issue:

AT-S.Var:build=171117-0328fe3-SPWF04S

AT-S.Var:fw_version=1.1.0

Can you verify that the Client_Socket example does work with both UART and SPI (and provide your configuration)?

Thanks very much.

Mike

[Mike Duffy]

Looking more closely at the VCOM example (which I thought ran with SPI):

As long as the jumpers are set for UART, it will run without CONSOLE_UART_ENABLED. So, in fact, the VCOM example doesn't support SPI. If you change the jumpers to SPI and remove CONSOLE_UART_ENABLED, the autobaud detection (which is not relevant to SPI), hangs.

I'd love to have one example program which is known to run with the SPI when only CONSOLE_UART_ENABLED is removed (and the jumpers are correctly set for SPI operation). So, far I haven't found one. If you believe there is one that should work, please tell me what it is.

If an example doesn't support SPI, it should not compile if CONSOLE_UART_ENABLED is missing, since that is the (software) convention for enabling SPI support.