201 lines
8.7 KiB
Markdown
201 lines
8.7 KiB
Markdown
firmware is for the SWJ finder.
|
|
|
|
project
|
|
=======
|
|
|
|
summary
|
|
-------
|
|
|
|
this tools allow to find JTAG and SWD (SWJ) interface on up to 16 channels.
|
|
|
|
usage
|
|
-----
|
|
|
|
connect the pins or test points of the target device to the SWJ finder channels pins on the connector.
|
|
select the first and last channel to probe using the `start <CH>` ans `stop <CH>` commands.
|
|
this prevents sending data on the unselected channels.
|
|
this will also make the scan faster, else it needs up to 5 seconds.
|
|
|
|
also connect the target voltage pin to the SWJ finder in order to use the right signal voltage level.
|
|
alternatively, the SWJ finder can supply 5V or 3.3V to the target voltage pin using the `voltage 5` or `voltage 3` command.
|
|
to revert to using the externally provided target voltage, use the `voltage 0` command.
|
|
to measure the target voltage, use the `voltage` command.
|
|
|
|
to scan for JTAG interfaces, use the `jtag` command.
|
|
to scan for SWD interfaces, use the `swd` command.
|
|
the scan results and found SWJ pins will be displayed as they are found.
|
|
it will also try to identify the target debug core.
|
|
the scanning will take up to 5 seconds.
|
|
WARNING: data will be sent on the selected channels (see limitations).
|
|
|
|
you can also reset the target board if you connected to target reset pin to the SWJ finder.
|
|
you can select of to drive the reset pin (OD for open-drain, PP for push-pull) and active level (H for high, L for low) using the `reset [ODL|ODH|PPL|PPH]` command.
|
|
to assert or release the reset, us the `reset 1` or `reset 0` commands.
|
|
alternatively, pressing/releasing the button on the SWJ finder asserts/releases the reset signal
|
|
|
|
use the `help` command to list all commands.
|
|
this will also list the shortcuts for the commands.
|
|
|
|
technology
|
|
----------
|
|
|
|
to scan for JTAG interfaces, it will use all 2-pin combinations as TCK and TMS signals to:
|
|
|
|
- switch the target to JTAG mode (in case it is in SWD mode)
|
|
- put in reset state (TEST-LOGIC-RESET)
|
|
- go into SHIFT-DR state to have the target output the IDCODE
|
|
|
|
any activity on one the other pins could be the IDCODE output on TDO.
|
|
this allows to identify the TCk, TMS, and TDO pins.
|
|
|
|
it will than send a patterns on each of the other pins.
|
|
if this pattern is found on the TDO will, the TDI pin is identified.
|
|
|
|
|
|
to scan for SWD interfaces, it will use all 2-pin combinations as SWCLK and SWDIO pins to:
|
|
|
|
- switch the target to SWD mode (in case it is in JTAG mode)
|
|
- put in reset state (using line reset)
|
|
- request the DPIDR (e.g. IDCODE)
|
|
|
|
if the target replies, the SWCLK and SWDIO have been successfully identified.
|
|
|
|
limitation
|
|
----------
|
|
|
|
the target voltage should not be higher than 5.5V (board I/O-pins limitation).
|
|
but I am not sure a SWJ target with signals higher than 3.3V even exist.
|
|
it can operate down to 1.5V (BSS138-based level shifter limitation).
|
|
|
|
all channel pins are pulled to by a 10 kOhm to the target voltage.
|
|
this is required to operate the level shifter.
|
|
this also means all channel pins are inter-connected by a 20 kOhm resistor when no target voltage is provided.
|
|
|
|
all channel pins have a 150 Ohm inline resistor protection.
|
|
this means the SWJ finder will sink up to 22 mA when transmitting a low level signal (high level is provided by the pull up resistor).
|
|
|
|
the reset pin has no inline protection resistor and can sink up to 25 mA.
|
|
in open drain mode, an external pull-up resistor is required, most often provide by the target device.
|
|
in push-pull mode it can only source 3.3V up to 25 mA.
|
|
|
|
when the IDCODE seems corrupted and the decoded manufacturer looks wrong, it might be due to too low impedance on the clock (SWCLK/TCK) line.
|
|
the clock signal needs a very sharp rising edge, but we are limited by the voltage shifter.
|
|
try shorter cables, or remove any other device (e.g. logic analyzer) from the test points.
|
|
|
|
board
|
|
=====
|
|
|
|
the underlying hardware uses a [WeAct MiniF4](https://github.com/WeActTC/MiniF4-STM32F4x1) board, based on a STM32F401CCU6.
|
|
the bi-directional level shifter are BSS138 n-channel MOSFET based.
|
|
switching the target voltage are done using BSS84 p-channel MOSFET.
|
|
|
|
connections
|
|
===========
|
|
|
|
channel pins:
|
|
|
|
- PB12, high voltage side of level shifter, low voltage side goes to CH0
|
|
- PB13, high voltage side of level shifter, low voltage side goes to CH1
|
|
- PB14, high voltage side of level shifter, low voltage side goes to CH2
|
|
- PB15, high voltage side of level shifter, low voltage side goes to CH3
|
|
- PA8, high voltage side of level shifter, low voltage side goes to CH4
|
|
- PA9, high voltage side of level shifter, low voltage side goes to CH5
|
|
- PA10, high voltage side of level shifter, low voltage side goes to CH6
|
|
- PA15, high voltage side of level shifter, low voltage side goes to CH7
|
|
- PB3, high voltage side of level shifter, low voltage side goes to CH8
|
|
- PB4, high voltage side of level shifter, low voltage side goes to CH9
|
|
- PB5, high voltage side of level shifter, low voltage side goes to CH10
|
|
- PB6, high voltage side of level shifter, low voltage side goes to CH11
|
|
- PB7, high voltage side of level shifter, low voltage side goes to CH12
|
|
- PB8, high voltage side of level shifter, low voltage side goes to CH13
|
|
- PB9, high voltage side of level shifter, low voltage side goes to CH14
|
|
- PB10, high voltage side of level shifter, low voltage side goes to CH15
|
|
|
|
BSS138 n-channel MOSFET based bi-directional level shifter:
|
|
|
|
- high voltage supply is 5V
|
|
- low voltage supply is connected to drain of BSS84 p-channel MOSFET
|
|
- source of BSS84 p-channel MOSFET is target voltage pin
|
|
- gate of BSS84 p-channel MOSFET is connected to PA5, pulled up to target voltage using 100 kOhm resistor
|
|
|
|
BSS84 p-channel MOSFET to supply target voltage with 5V:
|
|
|
|
- source is connected 5V
|
|
- drain is connected to target voltage
|
|
- gate is connected to PA7, pulled up to target voltage using 100 kOhm resistor
|
|
|
|
BSS84 p-channel MOSFET to supply target voltage with 3.3V:
|
|
|
|
- source is connected 3.3V
|
|
- drain is connected to target voltage
|
|
- gate is connected to PB0, pulled up to target voltage using 100 kOhm resistor
|
|
|
|
target voltage measure:
|
|
|
|
- PA1 is connected to target voltage through 22 kOhm inline resistor
|
|
- PA1 is connected to ground through 22 kOhm inline resistor
|
|
- this creates a /2 voltage divider, allowing to measure up the 6.6V
|
|
|
|
other:
|
|
|
|
- PA6 is connected target reset pin
|
|
- reset button is connected to PA0 on one side, ground on the other.
|
|
|
|
all pins are configured using `define`s in the corresponding source code.
|
|
|
|
code
|
|
====
|
|
|
|
dependencies
|
|
------------
|
|
|
|
The source code uses the [libopencm3](http://libopencm3.org/) library.
|
|
The projects is already a git submodules.
|
|
It will be initialized when compiling the firmware.
|
|
Alternatively you can run once: `git submodule init` and `git submodule update`.
|
|
|
|
firmware
|
|
--------
|
|
|
|
To compile the firmware run `rake`.
|
|
|
|
documentation
|
|
-------------
|
|
|
|
To generate doxygen documentation run `rake doc`.
|
|
|
|
flash
|
|
-----
|
|
|
|
There are two firmware images: `bootloader` and `application`.
|
|
The `bootloader` image allows to flash the `application` over USB using the DFU protocol.
|
|
The `bootloader` is started first and immediately jumps to the `application` if it is valid and the DFU mode is not forced (i.e. by pressing the user button on the board or requesting a DFU detach in the `application`).
|
|
The `application` image is the main application and is implemented in `application.c`.
|
|
It is up to the application to advertise USB DFU support (i.e. as does the provided USB CDC ACM example).
|
|
|
|
The simplest way do flash the `bootloader` image is using the embedded bootloader.
|
|
By pressing the BOOT0 button (setting the pin low) while powering or resetting the device, the micro-controller boot its embedded UART/USB DFU bootloader.
|
|
Connect a USB cable and run `rake dfu_bootloader`.
|
|
|
|
Once the `bootloader` is flashed, it is possible to flash the `application` over USB using the DFU protocol by running `rake flash` (equivalent to `rake dfu_application`.
|
|
To force the bootloader to start the DFU mode press the user button or short a pin, depending on the board.
|
|
Note: I use my own DFU bootloader instead of the embedded bootloader because I was not able to start the embedded USB DFU bootloader from the application.
|
|
|
|
The images can also be flash using SWD (Serial Wire Debug) in case the firmware gets stuck and does not provide USB functionalities.
|
|
For that you need an SWD adapter.
|
|
The `Makefile` uses a ST-Link V2 programmer along OpenOCD software (default), or Black Magic Probe.
|
|
To flash the `booltoader` using SWD run `rake swd_booloader` (this will also erase the application).
|
|
To flash the `application` using SWD run `rake swd_aplication` (or `rake swd`).
|
|
To erase all memory and unlock read/write protection, run `rake remove_protection`.
|
|
|
|
debug
|
|
-----
|
|
|
|
SWD also allows to debug the code running on the micro-controller using GDB.
|
|
To start the debugging session run `rake debug`.
|
|
|
|
USB
|
|
---
|
|
|
|
The firmware offers serial communication over USART1 and USB (using the CDC ACM device class).
|