今天有同事反饋出這樣一個(gè)在使用RISCV 調(diào)試時(shí)的問題:
Error:nodevicefound
Error:unabletoopenftdidevicewithvid0403,pid6014,description'ELITES-232DL',serial'*'atbuslocation'*'
這個(gè)錯(cuò)誤其實(shí)并不陌生,文檔也有一個(gè)相關(guān)的記錄.
目前易靈思的下載器主要使用的是FTDI的 FT232,FT2232和FT4232方案。下圖是FT2232和FT4232芯片的原理圖,F(xiàn)T2232有channel 0,1兩個(gè)通道,在下圖已經(jīng)標(biāo)出。FT4234有channel 0,1,2,3共4個(gè)通道;而ELITES-232DL使用的是FT232,它只有channel 0.所以在使用不同的下載噐方案時(shí),尤其是在對(duì)RISCV進(jìn)行debug時(shí)就是使用不同的配置參數(shù);否則就會(huì)報(bào)上面的錯(cuò)誤。
那么怎么區(qū)別下載器使用的是什么芯片方案呢?這個(gè)可以通過器件讀來的FD來實(shí)現(xiàn),在打開programmer之后,就可以看到相應(yīng)的ID.位置如下圖所示。
FTDI器件 | ID |
FT232 | 0403:6014 |
FT2232 | 0403:6010 |
FT4232 | 0403:6011 |
知道了上面的信息之后,我們就可以很清楚的知道我們的下載器使用的器件情況。
現(xiàn)在回上我們文章一開始就出現(xiàn)的問題。出現(xiàn)上面的報(bào)錯(cuò)時(shí)應(yīng)該怎么樣修改呢?這里還要分兩種情況,一種是hard jtag,另一種是soft的JTAG。區(qū)別在于修改的文件不同。
對(duì)于hard jtag,我們需要把embedded_swsoc_xxbspefinixEfxSapphireSocopenocdftdi.cfg(或者ftdi_ti.cfg,其中ftdi.cfg用于trion系列,而ftdi_ti.cfg 用于鈦金系列)修改成下載器讀出來的名字,這里包括ftdi_device_desc,ftdi_vid_pid及ftdi_channel三個(gè)參數(shù),只需要按照上面的說明配置即可。
比如以YLS_DL下載器為例,
它使用的是FT2232的方案。修改結(jié)果如圖。
對(duì)于soft jtag,老版本的EFinity修改的是c232hm_ddhsl_0.cfg文件,而在2023.1版本的RISCV中已經(jīng)沒有c232hm_ddhsl_0.cfg文件了。代之的是一個(gè)external.cfg文件。里面的內(nèi)部與上面的是一樣的。
-
DEBUG
+關(guān)注
關(guān)注
3文章
94瀏覽量
20103 -
RISC-V
+關(guān)注
關(guān)注
46文章
2397瀏覽量
47256
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
單片機(jī)Debug與仿真區(qū)別
RISCV 操作常見問題集 - v5
RISCV 操作常見問題集 - v4
RISCV的主流指令集有哪些?
在ubuntu 24.04下嘗試使用riscv64-linux-musleabi_for_x86_64-pc-linux-gnu工具鏈編譯cv1800大核出現(xiàn)報(bào)錯(cuò)的原因?
https_server編譯報(bào)錯(cuò)的原因?
為什么我的項(xiàng)目Debug運(yùn)行沒問題,編譯成Release包就報(bào)錯(cuò)?

ESP-Jumpstart例程中第5個(gè)工程:5_cloud連接報(bào)錯(cuò)是哪里的問題?
使用蜂鳥調(diào)試器,無法用cjtag協(xié)議調(diào)試CM32M433R芯片是怎么回事?
RISCV Debug連接報(bào)錯(cuò)問題-v1

RISCV soft JTAG調(diào)試_v1.2
使用stm32cubeprog連接FDcan設(shè)備總是報(bào)錯(cuò)的原因?怎么處理?
PostgreSQL數(shù)據(jù)庫連接報(bào)錯(cuò)故障分析

評(píng)論