0:09
Hello and welcome to Controllers Tech.
0:12
Today we are beginning a brand new
0:13
miniseries focused on STM32
0:17
IoT projects using the ESP 8266 Wi-Fi
0:22
transceiver module. In this series, we
0:24
will explore step by step how to connect
0:26
the STM32 to a Wi-Fi network using the
0:32
how to send sensor data to a cloud
0:34
server, and how to control STM32GPIOs
0:38
directly from a web dashboard. Along the
0:40
way, we will also implement the MQTT
0:43
protocol. And towards the end, we will
0:46
even try out STM32 overtheair OTAA
0:50
firmware updates through the ESP 8266.
0:54
This is going to be a very exciting set
0:56
of videos spread across the next couple
0:59
of months and it will give you a strong
1:01
foundation in building IoT applications
1:05
In today's first video of the series, we
1:08
will start with the basics. We will look
1:10
at how to configure STM32 cube, how to
1:14
make the hardware connection between
1:20
and finally, how to use simple commands
1:22
to connect the ESP 8266
1:25
to a Wi-Fi network. For this entire
1:28
series, I will be working with the
1:33
development board from WAX Studio. If
1:36
you're based in India, you can also
1:38
purchase this board directly from
1:39
shop.controllerssteech.com.
1:42
On the Wi-Fi side, I'll be using the
1:48
serial Wi-Fi module. This module is
1:51
quite compact, but it comes with
1:53
multiple pins, which can make direct
1:56
connections to the development board a
1:57
bit inconvenient. To solve this issue
2:00
and simplify the setup, I'll be using an
2:03
ESP 8266 adapter. This adapter reduces
2:07
the number of pins from eight down to
2:10
just four, leaving only TX, RX, VCC, and
2:14
ground. This makes it much easier and
2:17
cleaner to connect the module with the
2:19
development board. All the links to the
2:21
components I am using in this video are
2:25
provided in the article mentioned in the
2:27
description below. If you would like to
2:28
support the channel, you can do so by
2:31
purchasing through these affiliate
2:32
links. It really helps us continue
2:35
making more content like this. Before we
2:37
begin working on the STM32 project, the
2:40
first step is to make sure that our ESP
2:43
8266 Wi-Fi module is responding
2:46
correctly to AT commands. To test this,
2:50
we will connect the ESP 8266
2:54
to any USB to TTL converter, which will
2:57
then be connected to the computer. The
2:59
wiring is very straightforward. Connect
3:01
the pins in a cross fashion. The TX pin
3:04
of the ESP 8266 goes to the RX pin of
3:08
the converter, and the RX pin goes to
3:11
the TX pin of the converter. If you're
3:13
using the ESP01 adapter, you should
3:16
provide it with a 5V power supply since
3:18
the adapter already has an onboard
3:20
voltage regulator that steps it down to
3:23
3.3 volts, which is the operating
3:25
voltage of the ESP 8266.
3:29
However, if you're connecting directly
3:31
to the ESP 8266 module without the
3:35
adapter, make sure you supply 3.3 volts
3:38
only. Otherwise, you may damage the
3:41
module. Once the connections are ready,
3:44
open any serial terminal software and
3:46
select the correct USBTL port. Now, the
3:50
ESP 8266 modules usually have different
3:54
baud rates. I'm not sure which baud rate
3:57
this one is set to, but by default, many
4:00
modules are programmed with 9,600 bps.
4:03
So, we will start by trying that. When
4:05
sending 8t commands, remember they must
4:08
be followed by both carriage return and
4:11
line feed characters. Some serial
4:13
terminal programs allow you to
4:15
automatically add this tail, but if
4:17
yours doesn't, you can manually include
4:20
it in the command itself. Let's begin by
4:22
sending a simple at command. The command
4:26
was transmitted successfully. The send
4:28
count shows four bytes, two for the
4:31
command and two for the tail. However,
4:34
we did not receive any response from
4:36
module. At this stage, the first thing
4:38
you should do is check your wiring and
4:41
the power supply to ensure everything is
4:43
correct. In my case, the connections are
4:46
fine. So, I'll try changing the baud
4:50
bps and send the command again. This
4:52
time, we receive some data back. That
4:55
means the module is alive, but clearly
4:57
the baud rate is not yet correct. Next,
5:00
I'll try another common baud rate.
5:05
bps. After sending the AT command at
5:08
this rate, we received six bytes, but
5:10
still not the proper response we were
5:12
expecting. Now, let's switch the baud
5:17
bps. And test again. This time, we
5:20
receive the correct response from the
5:22
ESP module. It replied with okay for the
5:25
AT command. That confirms the module is
5:28
configured to operate at 115,200
5:32
bps. It's possible that I had
5:34
reconfigured this in one of my earlier
5:36
projects since most ESP 8266 modules
5:41
originally come preset to 9,600 bps.
5:45
With the baud rate confirmed, let's try
5:48
out a few more AT commands. AT plus GM
5:52
are is used to check the firmware
5:53
version. As you can see, the ESP module
5:57
responds with its 8T version and SDK
6:00
version details. Notice that every valid
6:03
response ends with okay. This is
6:05
important because later in our STM32
6:08
code, we can use that as a marker to
6:11
confirm successful command execution. AT
6:14
plus CW mode is used to check the
6:17
current Wi-Fi mode of the ESP module.
6:20
The response shows mode one, which means
6:23
the module is set to station mode,
6:25
allowing it to connect to an existing
6:27
Wi-Fi network. AT plus reset can be used
6:31
to restart the module. As you can see,
6:34
the ESP module reboots successfully.
6:37
Now, in my case, the Wi-Fi is already
6:40
connected. That's because during a
6:42
previous test, I configured the network
6:45
credentials and the ESP 8266 stored them
6:49
in its internal flash memory. Because of
6:52
that, it automatically reconnects during
6:54
boot. So, everything looks good. The
6:57
module is working, responding properly
6:59
to AT commands, and is ready to be used
7:02
in our STM32 IoT project. I have already
7:06
written the library files that will
7:08
handle the processing of a commands and
7:11
we will be using them in the project
7:13
later. You can download these library
7:15
files from the article linked in the
7:17
description of this video. Now let's
7:22
cube IDE and create a new project. As
7:25
mentioned earlier, I will be working
7:27
with the STM 32F 446 re development
7:31
board. Let's give the project a suitable
7:33
name and then click finish to create it.
7:36
We will begin by setting up the clock
7:38
configuration. For this project, I am
7:41
selecting the internal oscillator and
7:43
I'll configure the system to run at its
7:46
maximum frequency of 180 MHz. Next,
7:50
let's configure the UART that will be
7:52
used to communicate with the ESP module.
7:55
I am assigning UART 4. For this purpose,
7:58
the pins PA0 and PA1 will serve as your
8:02
ART 4TX and RX respectively. From our
8:05
earlier test, we already know that the
8:07
ESP module is communicating at a baud
8:13
So, we will configure UART 4 with the
8:15
same baud rate. Leave the rest of the
8:17
UART settings at their default values.
8:20
In addition to this, we need one more
8:22
UART to view user interactions and to
8:25
log debugging information. For this, I
8:28
will use UR1. The pins PA9 and PA10 will
8:33
act as UART 1TX and RX. I will keep the
8:36
baud rate for UART1 at 115,200
8:40
as well. That's all the configuration
8:43
required in CubMx for now. I will show
8:46
the actual hardware connections in just
8:48
a bit. For now, click save to generate
8:51
the project. The first thing we'll do
8:53
inside the project is to copy the
8:55
library files. Copy the C source file
8:59
into the project source directory and
9:01
the header file into the include
9:03
directory. Let's take a closer look at
9:08
STM 32 header file. Here we need to
9:11
specify which UART is being used for the
9:14
ESP module. If you're using a different
9:16
UART than what I've shown, you can
9:18
configure it here. I recommend keeping
9:21
the user logs enabled because they
9:23
display important information about the
9:25
ongoing processes. If you encounter
9:28
errors, you can then enable the debug
9:30
logs which will print detailed
9:32
step-by-step messages showing exactly
9:35
what led to the error. This makes
9:37
troubleshooting much easier. Currently,
9:40
the library provides three global
9:43
functions. ESP underscoret. This
9:46
initializes the ESP8266
9:50
module. ESP score connect Wi-Fi. This
9:54
connects the module to a Wi-Fi network
9:56
and retrieves its IP address. The
9:59
parameters for this function are SSID
10:02
and password of the Wi-Fi access point,
10:05
an IP buffer to store the assigned IP
10:08
address, and the buffer length which
10:11
defines the maximum size of that IP
10:13
buffer. ESP_get connection. This
10:16
function allows us to check and retrieve
10:19
the current connection status of the ESP
10:24
Now, let's go through how these
10:25
functions are written inside the source
10:27
file. We'll begin with the
10:29
initialization function. Inside this
10:32
function, the first step is to restart
10:35
the ESP module by sending the at plus
10:38
reset command. Just like we did earlier
10:40
in the serial terminal, this command
10:42
must end with a carriage return and line
10:45
feed. After the command is sent, the
10:48
module immediately acknowledges it with
10:50
an okay response. However, the restart
10:53
process itself continues for a few
10:56
seconds in the background to allow the
10:58
module enough time to reboot properly.
11:01
We add a delay of about 5 seconds after
11:04
sending this command. If you do not want
11:06
to restart the module every time, you
11:08
can simply skip this part of the
11:10
initialization function. In that case,
11:13
just add a small delay at the very
11:15
beginning of the function. This short
11:17
pause ensures that the ESP 8266 does not
11:21
receive commands while the STM32 code is
11:24
still flashing. Once the restart is
11:27
handled, we can begin the actual
11:29
initialization by sending the basic AT
11:32
command. Here we expect the module to
11:35
respond with okay, which confirms that
11:37
communication is working. If the
11:39
response is valid, we then proceed to
11:42
the next step. The next command we send
11:47
which disables command echoing. Again we
11:50
wait for the okay response. Once this
11:53
response is received we consider the
11:55
module successfully initialized. The
11:58
second important function is esp connect
12:01
Wi-Fi which connects the ESP 8266
12:06
to a known Wi-Fi network. The process
12:08
starts by setting the module to station
12:10
mode using the command a + cw mode
12:15
equals 1. As always, we wait for the
12:18
okay response to confirm that the
12:20
command was accepted. Next, we send a
12:26
along with the SSID and password of the
12:29
Wi-Fi network as parameters. The module
12:32
now attempts to connect to the access
12:35
point. Since this process takes a little
12:37
longer, we provide a timeout of 10
12:40
seconds. If the credentials are correct,
12:43
the ESP 8266 will respond with Wi-Fi
12:47
connected. In general, the timeout
12:49
values vary depending on the command
12:51
being sent. I have set the default time
12:54
out to 2 seconds, but you can adjust
12:56
this based on your needs. Once the
12:58
module is connected to the Wi-Fi, we
13:01
call a static function called get IP to
13:04
retrieve the module's IP address. Inside
13:07
the get IP function, we send the AT +
13:12
or command and wait for the response.
13:15
Since my module is already connected to
13:17
Wi-Fi, let's try this command directly.
13:20
As you can see, the module responds with
13:22
its IP address, MAC address, and an okay
13:26
at the end. In this response, the IP
13:29
address is associated with the label
13:31
station IP. So in our code, we search
13:34
for the keyword stip
13:37
in the incoming buffer. Once we find it,
13:40
we extract the IP address that appears
13:42
immediately after it and store it for
13:44
use in the project. Finally, let's look
13:47
at how the send command function works.
13:49
Since this function is central to all
13:52
communication inside send command, the
13:55
command string is first transmitted to
14:00
After that, we begin reading the
14:02
incoming data from the module one
14:04
character at a time and store it in the
14:06
RX buffer. While capturing this data,
14:09
the function continuously checks if the
14:12
expected acknowledgement string, for
14:14
example, okay, appears in the buffer. If
14:17
the acknowledgement is found, the
14:20
function returns success. And throughout
14:22
this process, if debug logs are enabled,
14:26
they will print detailed messages at
14:28
each step of the function. This makes it
14:30
very easy to follow what's happening
14:32
inside the code. Now, let's move on and
14:36
write the main file. First, include the
14:41
STM32 header file. Next, we will define
14:45
a custom write function. This function
14:48
will route the printf output to UR1 so
14:51
that all log messages can be displayed
14:53
on the serial console. Inside the main
14:56
function, the first step is to call the
14:58
ESP init function to initialize the ESP
15:03
8266 module. If initialization fails, we
15:07
will print an error message on the
15:09
console and call the error handler
15:11
function to stop further execution. Once
15:13
the module is initialized successfully,
15:16
we call the ESP connect Wi-Fi function
15:19
and pass the network SSID and password
15:23
as parameters. I am connecting the ESP
15:27
to my home Wi-Fi network, which is also
15:30
the same network that my computer is
15:32
connected to. The IP address assigned to
15:35
the module will be stored inside a
15:36
buffer. So, we need to define this
15:38
buffer first to make it reusable later
15:41
in the series. We will define the buffer
15:44
globally. If the connection function
15:46
fails, once again an error log will be
15:49
printed and the error handler will be
15:51
called. Now let's build the project. The
15:54
code compiles without any errors, which
15:57
means we are ready to flash it to the
15:59
development board. Before flashing,
16:01
let's double check the hardware
16:02
connections. The RX pin from the ESP
16:05
adapter is connected to PA0 UART 4TX.
16:10
The TX pin from the adapter is connected
16:15
The ESP adapter is powered with 5V from
16:19
the STM32 board itself. Make sure the
16:22
USB cable is plugged into the
16:24
development board since the STLink V2
16:26
provides only 3.3V for the board. If
16:30
you're using an external 5V supply for
16:33
the ESP adapter, ensure that the ground
16:36
of the external supply is properly
16:38
connected to the STM32 board's ground.
16:42
For debugging logs, the PA9TX
16:47
pin is connected to the RX pin of the
16:49
FT232 USB to serial adapter. Since we
16:53
only need to send logs to the console,
16:55
connecting just the TX pin is
16:57
sufficient. With everything connected,
17:00
let's flash the project to the board.
17:02
Now, open the serial terminal on your
17:05
computer. Select the correct port and
17:07
set the baud rate to 115,200.
17:11
Here you can see the sequence of events.
17:13
The ESP module begins initialization.
17:17
Once initialized, it switches to station
17:20
mode. It then connects to the Wi-Fi
17:22
network. Finally, the module retrieves
17:25
and displays its IP address. Everything
17:28
worked as expected. The process went
17:31
smoothly from initialization to Wi-Fi
17:34
connection and finally obtaining the IP
17:36
address. At this point, our STM32 board
17:43
is ready to handle network-based
17:44
protocols. If you encounter errors in
17:47
the user logs, you can always enable the
17:49
debug logs for a more detailed
17:51
breakdown. Let me show you an example.
17:54
With debug logs enabled, you can see
17:56
every step clearly. It logs which
17:59
command was sent, whether the expected
18:01
response was received, and even displays
18:04
the entire buffer received after each
18:06
command. So, that completes this part of
18:09
the tutorial. I hope this video helps
18:12
you successfully connect your STM32 to
18:15
the network using the ESP 8266
18:19
module. This is just the beginning. We
18:21
will continue building on this series in
18:24
the upcoming videos. In the next video,
18:26
we will focus on logging sensor data to
18:29
a cloud server. I will use the BME280
18:32
sensor to read temperature, pressure,
18:34
and humidity and then log that data to
18:37
the things cloud platform. After that,
18:40
we will move on to exploring network
18:42
protocols like the MQTT client. That's
18:45
it for this video. You can download the
18:47
full project from the link provided in
18:49
the description. If you have any
18:51
questions or if there's a specific topic
18:54
you would like me to cover in this
18:56
series, feel free to leave a comment.
18:58
Keep watching and have a great day