jsmif
commented
7 months ago As an update, I suspect this initial error may have been due to being in a VM, and then when the device switches over into JTAG programming mode, the device exposes a new thing that isn't automatically connected to the VM (because VMWare asks where you want to connect it), and then it failed, but then it was in a broken state. I only noticed this because I went through the GUI reflash steps for a different board to see what they look like, and then I got prompts which I had learned to force to always connect to my VM.
FWIW I was able to flash a different board (CC26XR1) from the VM, via DSLite, once I had set up things to auto-reconnect. But the CC2652RB was still giving me trouble. So I took it to a physical linux system and it did successfully update the firmware. So I don't know if it's actually a virtual vs. physical thing, but the 2652RB definitely gave me more trouble than the other 2 boards. So if you have one you might want to double check if it gives you trouble too, and if so, dis-recommend it. But if not, feel free to close this ticket.
sultanqasim
On Ubuntu 20.04, the Uniflash install seems to work fine, however the DSLite load command to reflash the dev board fails as follows:
And then now every time I attempt the same command after that, I get:
If you have a CC2652RB dev board, can you double check that it works with Release v1.7 and (the latest) DSLite version 12.3.0.3041?
I got a similar IcePick error when I tried the GUI reflashing mechanism initially too. Also, when googling around for a solution, I saw some TI forums saying to use "FLASH-PROGRAMMER-2" from https://ti.com/tool/FLASH-PROGRAMMER to try to erase the board completely. However that didn't work.