diff --git a/_posts/2024-06-04-diving-into-jtag-part-5.md b/_posts/2024-06-04-diving-into-jtag-part-5.md
index 5289edb3..4b80654f 100644
--- a/_posts/2024-06-04-diving-into-jtag-part-5.md
+++ b/_posts/2024-06-04-diving-into-jtag-part-5.md
@@ -8,10 +8,10 @@ tags: [arm, cortex-m, mcu, debugging, debugger]
In previous articles, we have considered the primary uses of JTAG, including
-debugging and testing boards in production. For firmware/embedded developers,
-the first - debugging - is the most common. In this article, I want to look at
-two uses of JTAG Boundary Scan, which are also common tasks for a
-firmware/embedded developer: board bring-up and reverse engineering.
+debugging and testing boards in production. For firmware developers, the first -
+debugging - is the most common. In this article, I want to look at two uses of
+JTAG Boundary Scan, which are also common tasks for a firmware developer: board
+bring-up and reverse engineering.
@@ -74,7 +74,7 @@ specify a .BSD file for a TAP, it will be put into the `BYPASS` state.
We specify
[STM32F405_415_407_417_LQFP100.bsd](https://bsdl.info/details.htm?sid=61a8799988cb03f688ca59b002289d77)
-file for the first TAP - SGS/Thomson(`06413041h`) as it is responsible for
+file for the first TAP - SGS/Thomson (`06413041h`) as it is responsible for
Boundary Scan. We leave the second TAP in `BYPASS`. To select a file, click the
_CLICK HERE TO SET_ link and select the desired file.
@@ -161,7 +161,7 @@ are turned on by setting the pin to a logical one and turned off by a logic
zero. To select the required level on a pin, it is necessary to find this pin in
the _Pin_ window and select the necessary actions from the context menu:
-
+
### GPIO input state view
@@ -170,16 +170,15 @@ pin. This can also be done using the JTAG Boundary Scan and TopJTAG application.
You can view the output state either in the _Watch_ window or in the _Waveform_
window. Let's look at the state of the output to which the button is connected:
-
+
-> **Note:** that as mentioned in the article
-> [Diving into JTAG. Part 3 - Boundary Scan](https://interrupt.memfault.com/blog/diving-into-jtag-part-3)
+> **Note:** As mentioned in the article
+> [Diving into JTAG. Part 3 - Boundary Scan](https://interrupt.memfault.com/blog/diving-into-jtag-part-3),
> there can be several scan cells per pin, and here you can see two of them: one
-> for receiving and one for transmitting. And as you can see, when the
-> controller transmits something, the receiving scan cell duplicates this
-> signal, as seen in the video with LEDs. Still, if the output works only for
-> receiving, the signal is present only on one cell, as seen in the video with
-> the button.
+> for receiving and one for transmitting. When the controller transmits
+> something, the receiving scan cell duplicates this signal, as seen in the
+> video with LEDs. Still, if the output works only for receiving, the signal is
+> present only on one cell, as seen in the video with the button.
## Reverse Engineering
@@ -201,13 +200,13 @@ transmission of the symbol "**U**" (which has a code equal to `0x55`) through
UART at 1200 baud looks like:
-
+
and at 2400 baud:
-
+
As you can see, even at 2400 baud, the signal is distorted (2 bits were lost).
@@ -215,7 +214,7 @@ As you can see, even at 2400 baud, the signal is distorted (2 bits were lost).
And here is what the SPI signal looks like with baudrate of 250 KBits/sec:
-
+
As you can see, it is hard to recognize SPI from this waveform, especially if
@@ -231,7 +230,7 @@ in some specific cases: you can see which pins of the controller are alive and
functioning at all or analyze the logic of the firmware, for example on this
example:
-
+
You can see that after we press the button, communication starts on some
protocol. Although it is difficult to understand it from the signal, it is SPI
+ 
+ 
+