brmlab

User Tools

Site Tools

You are here: Hackerspace Prague » Projects » ARM hardware debugging
project:arm_debugging:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
project:arm_debugging:start [2019/12/01 23:56] – [JTAG/SWD external clock] SWCLK/TCK can supply crystal oscillator abyssalproject:arm_debugging:start [2021/06/05 19:29] (current) – [Example: Unbricking (restoring) Proxmark bootloader] Flash bootloader and fullimage from same build abyssal
Line 303: Line 303:
 This is happening mostly on cheap clones of proxmark3 Easy. This is happening mostly on cheap clones of proxmark3 Easy.
  
 +To debug Proxmark on newer OpenOCD >= 0.10.0, you may set fast memory access and fast DCC downloads:
  
 +<code>
 +openocd -c "adapter_khz 4000" -f interface/jlink.cfg -c "gdb_memory_map disable" -f target/at91sam7x256.cfg -c "init; arm7_9 fast_memory_access enable; arm7_9 dcc_downloads enable"
 +</code>
  
 +Seems that flashing bootloader may not be enough, flash bootloader.elf and fullimage.elf from the same build in a single session (e.g. use ''file'' command in gdb), since mixing different branches may still result in bricked proxmark. Some bootloaders can't load fullimages built from other branches.
 ===== J-link connected to Proxmark ===== ===== J-link connected to Proxmark =====
  
 {{ :project:proxmark-jlink.jpg?800 | }} {{ :project:proxmark-jlink.jpg?800 | }}
  
 +===== SystemView for J-link - visualization of interrupts or other functions =====
 +
 +There is an instrumentation possible with changes to code to show how your functions and interrupts behave - [[https://wiki.segger.com/Use_SystemView_without_RTOS | sample code]]
 +
 +Here is an example showing "tail chaining" of interrupts where interrupts are behind one another, and also "late arriving", where Systick interrupts USB interrupt (marked as IST #93 starting at position 2195):
 +
 +{{:project:arm_debugging:systemview_20200318_113539.png?800|}}
 +
 +If you add extra functions, it may measure your functions as well:
 +
 +{{:project:arm_debugging:systemview_20200318_100652.png?800|}}
 +
 +As a side note, ST-link on STM32 discovery boards can be reflashed to JLink (works only on discovery boards, not on separate ST-links).
 +
 +===== ARM ETM trace - recording executed instructions =====
 +
 +ARM processors (Cortex M1+ and others) have built-in a nifty feature that you can record all instructions executed. This requires quite costly hardware (expect 2000 EUR price - JTrace, Lauterbach and uLink), but it can be handy in debugging DMA and interrupts.
 +
 +An example ETM trace:
 +
 +{{:project:arm_debugging:ozone_error_shutdown_highlighted.png?800|}}
 +
 +===== ARM ITM trace - recording samples of executed instructions, interrupts =====
 +
 +You can get code profile like this with ITM (screenshow from ''orbtop''):
 +
 +{{:project:arm_debugging:orbtop_trezor_lots_of_segwit_inputs.png|}}
  
 +To get this working, [[https://github.com/hiviah/ITM-howto-JLink-STLink|follow this howto]]. It shows steps to be used with JLink/JTrace or STLink to get it moving.
 ====== Flyswatter connected to Proxmark ====== ====== Flyswatter connected to Proxmark ======
  
Line 475: Line 507:
  
 It seems that when you desolder clocks (e.g. from crystal oscillator) the SWD/JTAG clock (SWCLK/TCK) can supply the clock to the chip which can be useful e.g. when you need glitch clock, but still would need operation via SWD/JTAG. Tested on [[https://brmlab.cz/project/chipwhisperer/start#glitching_stm32_external_board_through_ufo-board_interface | STM32F429 discovery board]]. It seems that when you desolder clocks (e.g. from crystal oscillator) the SWD/JTAG clock (SWCLK/TCK) can supply the clock to the chip which can be useful e.g. when you need glitch clock, but still would need operation via SWD/JTAG. Tested on [[https://brmlab.cz/project/chipwhisperer/start#glitching_stm32_external_board_through_ufo-board_interface | STM32F429 discovery board]].
 +
 +Doesn't seem to work with Black Magic probe without clock.
 +
 +===== Black Magic Probe =====
 +
 +[[https://github.com/blacksphere/blackmagic/wiki | Black Magic Probe]] (BMP) a replacement either for STLink firmware or usable as firmware on various ARMs to debug other ARMs.
 +
 +Pinout on the debug board is only findable in sources under src/platforms.
 +
 +Interesting features:
 +
 +  1. you can catch hardware ARM interrupts, e.g. "monitor vector_catch enable mm" (catches memory faults)
 +  2. SWD and JTAG boundary scan of devices
 +  3. you can use multiple devices connected
 +
 +
 +Differences from OpenOCD+GDB:
 +
 +  1. you can't use OpenOCD flashing or other OpenOCD commands (this is since BMP created USB-UART device and not a network device)
 +  2. commands used are different, e.g. BMP has "run"/"start" while OpenOCD+GDB has "monitor reset init"/"monitor reset halt"/"monitor reset", connecting to device is different (refer to BMP wiki)
 +
 +BMP creates /dev/ttyACM* interface that can be used without OpenOCD as extended-remote target (see BMP wiki).
 +
 +Some interesting features compared to old OpenOCD+gdb should be tracing support, but after discussions on the BMP discord channel it **doesn't fucking work** with BMP:
 +
 +  * https://github.com/blacksphere/blackmagic/wiki/Serial-Wire-Debug-TRACESWO-support (this shit doesn't work no matter what the docs say, confirmed from the main developer)
 +  * https://github.com/orbcode/orbuculum (you need the specific FPGA to make this work, or spend time porting it to different FPGA
 +
 +Note that you have to disable memory protections in order to read some memory (**set mem inaccessible-by-default off**), even then some parts that are accessible via STLink are not with BMP.
 +
 +==== Building and flashing Black Magic Probe on STLink v2 device ====
 +
 +In the build directory:
 +
 +<code>
 +make PROBE_HOST=stlink ST_BOOTLOADER=1
 +</code>
 +
 +Get the stlink-tool and build it in a directory different from blackmagic sources:
 +
 +<code>
 +git clone https://github.com/jeanthom/stlink-tool
 +cd stlink-tool
 +git submodule init
 +git submodule update
 +make
 +</code>
 +
 +Flash the built BMP with STLink bootloader (you may need to replug the STLink):
 +
 +<code>
 +./stlink-tool /path/to/src/blackmagic.bin
 +</code>
 +
 +After each replug of STLink, you need to run ''stlink-tool'' without arguments to activate it:
 +
 +<code>
 +./stlink-tool
 +</code>
 +
 +After this, ''/dev/ttyACM*'' appears. You can use script like this to a) symlink the devices and b) run the stlink-tool automatically. Automatic run means you can't upgrade until you disable it. Here are the udev rules:
 +
 +<code>
 +# Black Magic Probe
 +# there are two connections, one for GDB and one for uart debugging
 +  SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic GDB Server", SYMLINK+="ttyBmpGdb"
 +  SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic UART Port", SYMLINK+="ttyBmpTarg"
 +# Automatic running of stlink-tool, not recommended, uncomment following line and fill in the path to stlink-tool if you need it
 +#SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", ACTION=="add", RUN+="<path-to>/stlink-tool"
 +</code>
 +
 +Beware of ModemManager, sometimes even ignoring it in udev rules won't help (maybe since the device is changing USB VID:PID and descriptors? not sure)
 +
 +==== Useful GDB script for better visualization ====
 +
 +If you are reversing low-level assembler interface, catching interrupts, or doing some low-level work, this is a good interface for GDB: https://github.com/cyrus-and/gdb-dashboard
 +
 +Qt Creator can still be used though, but you might need to send the **target extended-remote /dev/ttyACM0** or **target extended-remote /dev/ttyBmpGdb** manually.
 +
 +Preview of the GDB dashboard:
 +
 +{{:project:arm_debugging:screenshot_20191219_001842.png?800|}}
 +==== Invocation inside GDB ====
 +
 +First of all, you need to use /dev/ttyACM (or the symlink /dev/ttyBmpGdb if you used udev rules above), secondly you need to scan for you target, then attach it and finally run/start/continue it.
 +
 +<code>
 +>>> target extended-remote /dev/ttyBmpGdb
 +Remote debugging using /dev/ttyBmpGdb
 +>>> monitor help
 +General commands:
 + version -- Display firmware version info
 + help -- Display help for monitor commands
 + jtag_scan -- Scan JTAG chain for devices
 + swdp_scan -- Scan SW-DP for devices
 + targets -- Display list of available targets
 + morse -- Display morse error message
 + halt_timeout -- Timeout (ms) to wait until Cortex-M is halted: (Default 2000)
 + connect_srst -- Configure connect under SRST: (enable|disable)
 + hard_srst -- Force a pulse on the hard SRST line - disconnects target
 + traceswo -- Start trace capture, NRZ mode: (baudrate)
 +>>> monitor swdp_scan
 +Target voltage: unknown
 +Available Targets:
 +No. Att Driver
 + 1      STM32F42x M3/M4
 +>>> attach 1
 +>>> monitor vector_catch enable mm ## example how to set breakpoint on memory fault interrupt
 +>>> continue
 +</code>
 +
 +==== Reflashing BMP back STLink v2 (possibly may work with v2.1) ====
 +
 +You either need to find the original STLink firmware somewhere (or have dumped it before) and use ''stlink-tool'' to flash it back or use [[https://www.st.com/en/development-tools/stsw-link007.html | STLink Upgrade Tool]]. If it doesn't find your device, replug it physically and try again.
 +
 +Note on v2 vs v2.1 from BMP developer:
 +
 +//To reflash ST-Link v2, un- and replug to get into the St bootloader. Stlinkv2-1 needs a warm reset to enter the bootloader, but mostly STLinkUpgrade.jar will not recognize the chip. Try with some old version of STLinkUpgrade.jar.//
 +
 +//B.t.w,BMP with git can now run some things from the command line, when PC-hosted, e.g. "blackmagic_hosted file.bin" will erase and flash file.bin at 0x08000000 . PC-hosted is not fast, maybe [[https://github.com/blacksphere/blackmagic/issues/570 | #570]] can improve by using high level commands.//
 +
 +==== Cheap Chinese STLink v2 clones ====
 +
 +Some of them can be reflashed to BMP, some can't (stlink-tool reports error). There are more versions, so the pinout on the outside and also on the board depends on the specific clone type.
 +
 +An example how to [[http://blog.linuxbits.io/2016/02/15/cheap-chinese-st-link-v-2-programmer-converted-to-black-magic-probe-debugger/ | use one cheap clone to flash other]]. The cloned STLink is STM32F1 and it has [[http://blog.linuxbits.io/wp-content/uploads/2016/02/P1160474_clipped2.jpg | SWD pins routed out on the board]]
 +
 +Original STLink (flashed with BMP with ST bootloader) using to program BMP on the cheap clone (haven't yet figure out how to restore ST bootloader, since I don't have the executable image containing the bootloader):
 +
 +{{:project:arm_debugging:stlink_clone_bmp.png|}}
 +
 +
 +==== BMP PC-hosted with BMP HW target ====
 +
 +For BMP built with ''PROBE_HOST=pc-hosted'' you can connect to an external physical BMP with:
 +
 +<code>
 +./src/blackmagic_hosted -s /dev/ttyACM0
 +</code>
 +
 +It will create port 2000 listening for GDB connection and you can use the classic BMP commands like scan and attach:
 +
 +<code>
 +>>> target extended-remote :2000
 +Remote debugging using :2000
 +>>> monitor swdp_scan
 +Target voltage: unknown
 +Available Targets:
 +No. Att Driver
 + 1      STM32F1 medium density M3/M4
 +>>> attach 1
 +Attaching to program: blackmagic-stlink-v2/src/blackmagic, Remote target
 +0x0800effc in st_usbfs_ep_read_packet (dev=<optimized out>, addr=<optimized out>, buf=<optimized out>, len=<optimized out>) at ../common/st_usbfs_core.c:230
 +230 USB_SET_EP_RX_STAT(addr, USB_EP_RX_STAT_VALID);
 +
 +</code>
 +
 +
 +==== BMP PC-hosted with unmodified STLink v2 target (requires firmware >= V2J32xx) ====
 +
 +Upgrade STLink fw first with the STLinkUpgrade tool mentioned before.
 +
 +With this firmware you can use external unmodified STLink with BMP (''PROBE_HOST=pc-stlinkv2''):
 +
 +<code>
 +./src/blackmagic_stlinkv2
 +</code>
 +
 +It will create port 2000 listening for GDB connection and you can use the classic BMP commands like scan and attach:
 +
 +<code>
 +>>> target extended-remote :2000
 +Remote debugging using :2000
 +>>> monitor swdp_scan
 +Target voltage: unknown
 +Available Targets:
 +No. Att Driver
 + 1      STM32F1 medium density M3/M4
 +>>> attach 1
 +Attaching to program: blackmagic-stlink-v2/src/blackmagic, Remote target
 +0x0800effc in st_usbfs_ep_read_packet (dev=<optimized out>, addr=<optimized out>, buf=<optimized out>, len=<optimized out>) at ../common/st_usbfs_core.c:230
 +230 USB_SET_EP_RX_STAT(addr, USB_EP_RX_STAT_VALID);
 +
 +</code>
 +
 +
 +===== Other useful tools that are specific to STM32 chips  =====
 +
 +  * [[https://www.st.com/en/development-tools/stm32cubemx.html | STM32CubeMX]] - GUI for designing MCU/board settings, shows you the options, pinout of chips, can generate code to set the configuration.
 +  * [[https://www.st.com/en/development-tools/stm32cubeprog.html | STM32CubeProg]] - GUI/CLI programmer, can change things like read/write protect, option bytes, memory contents, etc. You need Oracle Java >= 8 for this, otherwise the GUI part won't work (use JAVA_HOME env var to set the Oracle java dir, then run the program). CLI seems to work without Oracle Java.
 +  * [[https://www.st.com/en/development-tools/stsw-link007.html | STLink Upgrade Tool]] - upgrade for STLink. I think it's also part of STM32CubeMX
project/arm_debugging/start.1575244603.txt.gz · Last modified: 2019/12/01 23:56 by abyssal