search

dirtyjtag / DirtyJTAG

JTAG probe firmware
MIT License
467 stars 70 forks source link

Baite ST-Link dongles #36

Closed jeanthom closed 5 years ago

jeanthom commented 5 years ago

Should follow original Baite pinout, needs to be tested.

ELF and BIN firmwares

jeanthom commented 5 years ago

Poke @psyborg55

psyborg55 commented 5 years ago

thanks! what about flashing method, DFU should work?

jeanthom commented 5 years ago

The firmware I attached are meant to be flashed using another SWD programmer, I don't think you can use it with DFU (the entry point for the program is at a different address).

psyborg55 commented 5 years ago

i had some virtual ubuntu 18.04 so i decided to build it myself, changed entry point address to the one of stlink2dfu and added trst/srst pins as b0/b6. "make bin PLATFORM=baite" did not work so i just removed bin from syntax and fw binaries were built. can you confirm this is fine?

jeanthom commented 5 years ago

There is no "bin" target in the Makefile. In order to build the .bin firmware you should use this command :

make PLATFORM=baite
psyborg55 commented 5 years ago

ok, this is what happens:

ubuntu@ubuntu:~/stlink-tool$ sudo ./stlink-tool '/home/ubuntu/Desktop/dirtyjtag.baite.bin' Firmware version : V2J32S7 Loader version : 14152 ST-Link ID : 3500XXXXXXXXXXXXXXXXXXXX Firmware encryption key : 075DXXXXXXXXXXXXXXXXXXXXXXXXXXXX Current mode : 1 Loaded firmware : /home/ubuntu/Desktop/dirtyjtag.baite.bin, size : 8564 bytes .........

probe succeed with some err msgs:

ubuntu@ubuntu:~/stlink/build/Release$ sudo ./st-info --probe [!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT [!] send_recv STLINK_GET_CURRENT_MODE [!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT [!] send_recv STLINK_DEBUG_ENTER [!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT [!] send_recv STLINK_GET_VERSION [!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT [!] send_recv STLINK_DEBUG_RESETSYS [!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT [!] send_recv STLINK_DEBUG_READCOREID [!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT [!] send_recv STLINK_JTAG_READDEBUG_32BIT Found 1 stlink programmers

but lsusb still returns 0483:3748 pid

jeanthom commented 5 years ago

Whenever you issue an lsusb command the PID/VID aren't queried from the peripherals, therefore it doesn't indicate the current PID/VID of your USB peripheral. In order to do this, you need to get your peripheral reenumerated, by getting into SE0 state (http://www.usbmadesimple.co.uk/ums_3.htm).

There are known issues with USB re-enumeration in DirtyJTAG, it seems that some USB hosts are more forgiving than others...

You may want to try applying those changes : https://github.com/jeanthom/DirtyJTAG/commit/6b27a8e394f2a5a61741669511cb866da764f82f

But if it doesn't work then you should use the goold old SWD programming method.

psyborg55 commented 5 years ago

doesn't work and i do not have other adapters. st-probe screws usb connection and even loading firmware again doesn't work until re-plugged device. does that have anything to do with libusb library? using version 1.0.22 of libusb.

how about uart flashing i see board has 4 pads which i assume are serial port?

psyborg55 commented 5 years ago

some update: LIBUSB_ERROR_TIMEOUT happens because of bad firmware (used same entry point for the firmware i'm trying to load as in stlinkv2dfu), got same message on windows too. after 'upgrading' firmware via st-link utility message goes away.

st-info --probe does not reveal much:

flash: 0 (pagesize: 0) sram: 0 chipid: 0x0000 descr: unknown device

but at least can confirm that everything's fine with usb libraries

jeanthom commented 5 years ago

Yup, there's nothing wrong with libusb there.

The issue here resides in the way ST's bootloader works. When you plug your dongle into a USB port, the STM32 will enter ST's bootloader, and will initiate USB communication with the host with ST's PID/VID.

What you're doing with st-info --probe is basically sending a command that will make the dongle exit from bootloader and load branch to 0x8004000 (the actual ST-Link firmware, after bootloader). At that point the ST-Link uses the same PID/VID as its bootloader so there's no need to re-enumerate the USB peripheral.

The problem I currently face is that the re-enumeration process that makes the dongle recognized with DirtyJTAG's PID/VID instead of ST's is not working reliably. If it was running correctly you would be able to see the DirtyJTAG dongle in place of the ST-Link in lsusb.

As I said earlier, if you have something that could act as a SWD programmer (like an STM32 dev board), use it to reprogram your Baite without bothering about ST's hacky bootloader.

psyborg55 commented 5 years ago

ok, just to add that i tried to load stlinkv2dfu.bin v1.2 downloaded from github and this confirmed the issue:

ubuntu@ubuntu:~/stlink-tool$ st-info --probe [!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE [!] send_recv STLINK_DFU_EXIT [!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE [!] send_recv STLINK_GET_CURRENT_MODE [!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE [!] send_recv STLINK_DEBUG_ENTER [!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE [!] send_recv STLINK_GET_VERSION [!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE [!] send_recv STLINK_DEBUG_RESETSYS [!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE [!] send_recv STLINK_DEBUG_READCOREID [!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE [!] send_recv STLINK_JTAG_READDEBUG_32BIT Found 1 stlink programmers

after this device disappears:

ubuntu@ubuntu:~/stlink-tool$ st-info --probe Found 0 stlink programmers

should i make any other modifications to firmware when flashing via uart? i'd try the method using stm32flash as described in black magic probe flashing on this link: https://wiki.cuvoodoo.info/doku.php?id=jtag

psyborg55 commented 5 years ago

flashed firmware with above method: 3.3V on pins 3V3, TCK, SWIM; 5V on 5V5; other pins are low

psyborg55 commented 5 years ago

can't tell if this will work or not... each time the detect command returns: warning: TDO seems to be stuck at 0

which libraries this dongle exactly needs, libusb only or libftdi/libftd2xx too?

psyborg55 commented 5 years ago

seems like making clean before rebuilding didn't really cleaned as expected, now rebuilt the firmware and no more 3.3V on TCK. if the device responds this looks like it's working:

jtag> cable dirtyjtag jtag> detect IR length: 5 Chain length: 1 Device Id: 00000000000000000000000000000001 (0x00000001) Unknown manufacturer! (00000000000) (/usr/local/share/urjtag/MANUFACTURERS) jtag>

jeanthom commented 5 years ago

Hi,

When facing "TDO stuck to 0" errors, you can try swapping TDI/TDO (DirtyJTAG pin convention is that you plug DJTAG's TDI to your TAP's TDI & DJTAG's TDO to your TAP's TDO IIRC).

Your IR length seems correct, however the device ID is weird.

Will have to rework my Makefile, the cleaning process isn't properly working it seems.

psyborg55 commented 5 years ago

device ID 0x00000001 from google search seems to be common for atheros chips. tried using this on actually bricked device (MT7260A) but once everything was connected and device powered on, first time running detect does not return anything and other attempts to detect always returned TDO seems to be stuck at 1

psyborg55 commented 5 years ago

Hi

I think you can merge this; tried to use it and some interaction with the CPU was possible:

jtag> cable dirtyjtag jtag> detect IR length: 5 Chain length: 1 Device Id: 00000000000000000000000000000001 (0x00000001) Unknown manufacturer! (00000000000) (/usr/local/share/urjtag/MANUFACTURERS) jtag> include atheros/ar2312/ar2312
ImpCode=00000000000000000000000000000001 00000001 EJTAG version: <= 2.0 EJTAG Implementation flags: R4k DMA MIPS64 Processor entered Debug Mode. jtag> detectflash 0x1f000000 ImpCode=10100000010000010100000000000000 A0414000 EJTAG version: unknown (5) EJTAG Implementation flags: R4k ASID_8 MIPS16 NoDMA MIPS32 Processor entered Debug Mode. dev ID=0000 man ID=0000 urj_flash_amd_detect: mid 0, did 0 error: flash: mid != 0x01

rest is up to the loading proper config i guess

jeanthom commented 5 years ago

Thank's for the feedback, I will merge it!

zoobab commented 5 years ago

I think the Dockerfile is missing the following line:

RUN make PLATFORM=baite
jeanthom commented 5 years ago

You're right! #40 will take care of that.

psyborg55 commented 5 years ago

hey @zoobab I just tried building versaloon for this module, but it's not recognized after flashing. any chance it could be supported? or is there a simple way to run dirtyjtag with openocd?

jeanthom commented 5 years ago

I tried writing an OpenOCD driver for DirtyJTAG but I had a hard time working with their codebase so I stopped working on it. I instead worked on helping zoobab to get versaloon working on Blue Pills.

How do you flash Versaloon on your board ?

psyborg55 commented 5 years ago

using cp2102 usb-uart adapter and running the commands respectively; sudo stm32flash -r bbckp.bin -g 0x80000000 /dev/ttyUSB0 sudo stm32flash -w Versaloon-STM32F103C8-Baite.bin -v -g 0x80000000 /dev/ttyUSB0

tried reading the contents afterwards and checking sums, they do match, so the flashing procedure is not an issue. used default settings for bluepill (renamed to baite), only changed TDI,TDO,TMS pins..

zoobab commented 5 years ago

@psyborg55 how do you build the Versaloon-STM32F103C8-Baite.bin? have you made changes somewhere on a branch or a fork?

psyborg55 commented 5 years ago

just renamed profile in makefile and board_defs.mk. changed PORT & PIN assignments for above mentioned pins. didn't work. even tried to include removed hw_cfg_st_link.h and do modifications there. no build so far allowed device to be recgonized with lsusb. maybe the issue is i'm building it on ubuntu 16.04?

psyborg55 commented 5 years ago

also, i see defines of various functions in this list:

define HW_HAS_USART 1

define HW_HAS_SPI 1

define HW_HAS_SDIO 0

define HW_HAS_EBI 0

define HW_HAS_IIC 1

define HW_HAS_GPIO 1

define HW_HAS_CAN 0

define HW_HAS_PWM 1

define HW_HAS_ADC 1

define HW_HAS_DAC 0

define HW_HAS_MICROWIRE 1

define HW_HAS_DUSI 1

define HW_HAS_JTAG 1

define HW_HAS_ISSP 1

define HW_HAS_C2 1

define HW_HAS_MSP430_JTAG 1

define HW_HAS_MSP430_SBW 0

define HW_HAS_LPCICP 1

define HW_HAS_SWD 1

define HW_HAS_SWIM 1

define HW_HAS_BDM 1

define HW_HAS_POWERCONTROL 1

define HW_HAS_CLKO 1

define HW_HAS_BEEPER 0

define HW_HAS_LEDARRAY 0

define HW_HAS_7COLOR_LED 0

is it enough to null them here so they don't occupy pins and interfere with desired operation mode?