CCS failed to connect after Ubuntu update

[vsiles]

Hi,

this morning, following an Ubuntu update, I can't manage to connect to my LS1021atwr board anymore.

Here is ccs log:

No clients denied (bin) 49 % config cc cmsisdap Identified CMSIS-DAP SERNUM: 20000203C5231E0638DFC1FE Firmware version: 0203 0: CMSIS-DAP (cmsisdap) CC software ver. {0.3} (bin) 50 % ccs::config_server 0 10000 rddi_CMSIS_DAP_DetectNumberOfDevices failed : 0x100d (bin) 51 % 

On a second atempt, I get

rddi_CMSIS_DAP_Connect failed : 0x100b

I checked th udev rule for cmsis_dap and they are still here.

What could be the cause of these errors ? Any idea on a posible fix ?

Best,

Vincent

[vsiles]

Then I'm sorry but I don't have this image anymore. Thank you for all the support !

[addiyi]

I want the exact image you use. Because, it is possible to have an issue in ccs, but I'm not able to reproduce :smileyhappy:.

Adrian

[addiyi]

Not able to reproduce this issue. Could send me the RCW/Uboot binary?

Adrian

[vsiles]

I'm sorry but I can't, I don't have any backup of this binary. The one I am using right now is working, with the exact same RCW. Do you want this newer version ?

[addiyi]

Even with all cores in boot hold-off in RCW, the connection must work. Below is the test done on my twr board.

(bin) 52 % config cc cmsisdap

Identified CMSIS-DAP SERNUM: 20000203C5091E5938F5C1A1

Firmware version: 0203

0: CMSIS-DAP (cmsisdap) CC software ver. {0.3}

(bin) 53 % ccs::config_chain {ls1020a cmsisdap}

(bin) 54 % ::ccs::all_run_mode

CortexA7: Reset Mode

CortexA7: Reset Mode

Could you add your RCW?

Adrian

[vsiles]

Sure,

here is my RCW:

#PBL preamble and RCW header
aa55aa55 01ee0100
#enable IFC, disable QSPI and DSPI
0608000a 00000000 00000000 00000000
30000000 00007900 60640a00 21046000     # cpu0 on hold + secure boot enabled
00000000 00000000 00000000 20000000
00080000 881b7340 00000000 00000000

and if that's relevant, I am using an unmodified board/freescale/ls1021atwr/ls102xa_pbi.cfg

[vsiles]

my current setting was booting the board with BOOT_HO blocking cpu0. In order to check if the board was damaged, I rebooted from the SD card with a "normal" boot, and it went fine. And now, I can use ccs again.

Maybe some internal state was corrupted and rebooting the board with a "normal" system fixed it ?

Thank you very much for your advices and your time

[addiyi · Accepted solution]

Switches looks fine. Try to use directly ccs::config_chain {ls1020a cmsisdap} after config cc cmsisdap.

Adrian

[vsiles]

In case it helps:

I tried the procedure with SW2.8 set to 1: ccs::config_server 0 1000 answer 'no devices found'

with SW2.8 set to 0: ccs::config_server 0 10000 answer 'rddi_CMSIS_DAP_Connect failed : 0x100b'

The only cable plugged in (except power) is the usb / serial cable

SW2 status: 0 0 1 0 1 1 1 0

SW3 status: 0 1 1 0 0 0 0 1

I boot from SD card using the uboot sd/ifc target of uboot

[addiyi]

You could do the followings checks:

$ ls -lrt /dev/usb

total 0

crw------- 1 root root 180, 96 Jun 17 11:15 hiddev0

$ ls -lrt /dev/hidraw0

crw------- 1 root root 251, 0 Jun 17 11:15 /dev/hidraw0

$ dmesg

....

[3040048.991228] generic-usb 0003:0D28:0204.000B: hiddev0,hidraw0: USB HID v1.00 Device [MBED MBED CMSIS-DAP] on usb-0000:00:1d.0-2/input3

Change udev rules if CMSIS-DAP is recognized only when running CCS as root(sudo) and not as user:

$ sudo emacs /etc/udev/rules.d/mbed.rules

$ SUBSYSTEM=="usb", ATTR{idVendor}=="0d28", ATTR{idProduct}=="0204", MODE:="666"

$ sudo udevadm trigger

Also make sure that "vendor id" and "product id" should match between output from dmesg and udev rules.

For Example:

$dmesg | grep CMSIS

generic-usb 0003:0D28:0204.0001: hiddev96,hidraw0: USB HID ----------------

$ more /etc/udev/rules.d/mbed.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="0d28", ATTR{idProduct}=="0204", MODE:="666"

Adrian

[vsiles]

No such luck: everything is configured as you explained, and I still get the rddi_CMSIS_DAP_Connect failed: 0x100b

[addiyi]

"rddi_CMSIS_DAP_Connect failed: 0x100b" means: Connection to target failed. Please make sure jtag is not used and SW2.8 is 0.

Adrian

[vsiles]

I didn't touch the switch for a long time, but to be sure I unplugged the cable, move the switch to 1 and then to 0 again, and replug the cable. Same behavior.

Googling the error messages leads to quite a few post about printer failing to work because of some usb issues, but the fix seems always to patch cups, and I didn't had a cups update this morning, only libc and samba. Maybe something is interfering with the usb driver ?

[vsiles]

If had a look at dmesg while inserting the USB plug and here is what I get:

May 26 14:38:38 vsiles-Desktop kernel: [17238.769272] usb 1-3.1: new full-speed USB device number 9 using xhci_hcd
May 26 14:38:38 vsiles-Desktop kernel: [17238.860433] usb 1-3.1: New USB device found, idVendor=0d28, idProduct=0204
May 26 14:38:38 vsiles-Desktop kernel: [17238.860436] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 26 14:38:38 vsiles-Desktop kernel: [17238.860437] usb 1-3.1: Product: MBED CMSIS-DAP
May 26 14:38:38 vsiles-Desktop kernel: [17238.860438] usb 1-3.1: Manufacturer: MBED
May 26 14:38:38 vsiles-Desktop kernel: [17238.860439] usb 1-3.1: SerialNumber: 20000203C5231E0638DFC1FE
May 26 14:38:38 vsiles-Desktop kernel: [17238.861178] usb-storage 1-3.1:1.0: USB Mass Storage device detected
May 26 14:38:38 vsiles-Desktop kernel: [17238.861263] scsi host11: usb-storage 1-3.1:1.0
May 26 14:38:38 vsiles-Desktop kernel: [17238.861716] cdc_acm 1-3.1:1.1: ttyACM0: USB ACM device
May 26 14:38:38 vsiles-Desktop kernel: [17238.864976] hid-generic 0003:0D28:0204.0008: hiddev0,hidraw0: USB HID v1.00 Device [MBED MBED CMSIS-DAP] on usb-0000:00:14.0-3.1/input3
May 26 14:38:38 vsiles-Desktop mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.1"
May 26 14:38:38 vsiles-Desktop mtp-probe: bus: 1, device: 9 was not an MTP device
May 26 14:38:39 vsiles-Desktop kernel: [17239.862574] scsi 11:0:0:0: Direct-Access    MBED    microcontroller  1.0  PQ: 0 ANSI: 2
May 26 14:38:39 vsiles-Desktop kernel: [17239.862989] sd 11:0:0:0: Attached scsi generic sg3 type 0
May 26 14:38:39 vsiles-Desktop kernel: [17239.863353] sd 11:0:0:0: [sdc] 304 512-byte logical blocks: (155 kB/152 KiB)
May 26 14:38:39 vsiles-Desktop kernel: [17239.863544] sd 11:0:0:0: [sdc] Write Protect is off
May 26 14:38:39 vsiles-Desktop kernel: [17239.863548] sd 11:0:0:0: [sdc] Mode Sense: 03 00 00 00
May 26 14:38:39 vsiles-Desktop kernel: [17239.863757] sd 11:0:0:0: [sdc] No Caching mode page found
May 26 14:38:39 vsiles-Desktop kernel: [17239.863760] sd 11:0:0:0: [sdc] Assuming drive cache: write through
May 26 14:38:39 vsiles-Desktop kernel: [17239.874375]  sdc:
May 26 14:38:39 vsiles-Desktop kernel: [17239.875473] sd 11:0:0:0: [sdc] Attached SCSI removable disk
May 26 14:38:39 vsiles-Desktop udisksd[2952]: Mounted /dev/sdc at /media/vsiles/MBED on behalf of uid 1000

As soon as I enter a command is ccs, I get:

May 26 14:38:51 vsiles-Desktop kernel: [17251.899754] usb 1-3.1: usbfs: interface 0 claimed by usb-storage while 'ccs' sets config #1
May 26 14:38:51 vsiles-Desktop kernel: [17251.903352] usb 1-3.1: usbfs: interface 0 claimed by usb-storage while 'ccs' sets config #1

This might be the issue ?

[addiyi]

I get the same messages in dmseg. rddi_CMSIS_DAP_Connect failed: 0x100b, I get only when sw2.8 = 1.

Maybe indeed is something interfering with the usb driver. Did you try a system reboot?

Adrian

[vsiles]

I just tried to reboot without success. After checking my log for the past few days, I already got some of the "claimed" error messages a couple days ago and everything was fine.

However I got an update from usb 1.3-1 to 1.3-2 which might explain the issue ?

[addiyi]

I'm not sure this could be the reason, because "config cc cmsisdap" works and return the serial number and firmware version from the device.

Do you have other board with cmsis-dap to try on it?

Adrian

[vsiles]

Unfortunately no, I don't have another board.

This morning I saw that I got new updates from the same package as yesterday. I just tried again after a reboot and nothing changed :/

Vincent

[vsiles]

Dear addiyi​, I just tried to unplug everything, plug everything back and made a new attempt.

Now the ccs::config_server 0 10000 succeed, but the ccs::config_chain {ls1021a cmsisdap} fails with

LS1020A: Reported SoC topology is inconsistent with real topology.

Maybe this will help to understand what's going on. In the meantime, I'll try to find a new usb cable, maybe the issue is there.

[addiyi]

The correct config chain is: ccs::config_chain {ls1020a cmsisdap}

Adrian