search

sifive / freedom-e-sdk

Open Source Software for Developing on the Freedom E Platform - Deprecated
Other
579 stars 209 forks source link

Error: Unsupported DTM version: 14 #302

Open whitesong3000 opened 5 years ago

whitesong3000 commented 5 years ago

Hi, When usning SiFiveTools->Flash MCS file to Arty FPGA in Freedom studio,I encounterd error:Unsupported DTM verdion:14. The detailed log: 2019-07-05 13:48:17.811000: Running Command: C:\Jason\sifive\software\freedomstudio\SiFive\riscv-openocd\riscv-openocd-0.10.0-2019.05.1\bin\openocd.exe -f C:\Jason\sifive\software\freedomstudio\SiFive\xc3sprog\xc3sprog-0.1.2-2019.04.1\openocd_100t.cfg -c "flash protect 0 0 last off" -c "program {C:\Jason\sifive\fpga\sifive_coreip_E24_AHB_rtl_eval_v19_05_rc0_release\arty_a7_100t-sifive\e24_arty.mcs} verify 0x40000000" -c exit Open On-Chip Debugger 0.10.0+dev (SiFive OpenOCD 0.10.0-2019.05.1) Licensed under GNU GPL v2 For bug reports: https://github.com/sifive/freedom-tools/issues adapter speed: 10000 kHz Info : auto-selecting first available session transport "jtag". To override use 'transport select '. Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling" Info : clock speed 10000 kHz Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive, Inc.), part: 0x0000, ver: 0x2) Error: Unsupported DTM version: 14 Info : Listening on port 3333 for gdb connections Error: Target not examined yet

Error: Unsupported DTM version: 14

nategraff-sifive commented 5 years ago

@sifivekevin Any thoughts?

sifivekevin commented 5 years ago

@SiFiveGregS This looks like the "wrong flasher bit file" problem, but it looks right to me. Any thoughts?

GregSavin commented 5 years ago

This is a longshot, but I don't suppose there is a cJTAG adapter attached to the Olimex? (Probably not, I think the resulting error messages would be less nuanced, and earlier in the process)

GregSavin commented 5 years ago

Occasionally I've seen odd things happen that end up being traced back to a rogue leftover "openocd" process running. So that's another thing to check. Rare, but I see it once a month or so. I'm guessing that some non-functional zombie state is possible somehow when a host wakes up from Windows hibernation or something. If I could replicate the establishment of a zombie OpenOCD, I'd try to debug it.