• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 55 subscribers
  • Views 532 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352P: ROM bootloader download failure using Linux host

Shuyang Zhong
Expert 4890 points
Part Number: CC1352P


A customer is using the sblUART demo from the TI15.4 Linux gateway SDK to download program to CC1352. The host is ARM Cortex-A53, the example has been successfully cross-compiled and runned on the host, but sometimes the download progress cannot finish.

I am able to reproduce this issue with a Raspberry Pi 3 which has an A53 core. I have captured the RX and TX waveforms with a Saleae logic analyzer, and found that just before the download failed, the host sent a packet which content is {0x7E 0x80 0x01 0x02 0x92 0x7E} after a data frame, and CC1352 returns an ACK, then the host sent a GET_STATUS command with no reply from the CC1352. After that, the host tried several times to resend the packet {0x7E 0x80 0x01 0x02 0x92 0x7E} but with no reply as well.

What I'm not understanding is what does the packet {0x7E 0x80 0x01 0x02 0x92 0x7E} mean? That is not a command listed in the TRM, and if it is a data fragment, the length does not look right. Would you please help? Thanks.

BR,

Shuyang

  • 0
    TI__Mastermind 20412 points

    Hi Shuyang,

    I have assigned this thread to an expert, they should get back to you soon. 

    Regards,

    Siddanth

  • 0
    TI__Guru* 82431 points

    Hi Shuyang,

    That's interesting.

    1) What version of the Linux GW SDK are you using?

    2) When you say that sometimes the download process does not finish, can you quantify? E.g. 2 out of 5 attempts fail.

    3) Did they test with one or several boards? 

    4) Are they using a LaunchPad or a custom board?

    5) Can you check whether this command is also sent in success cases? (The {0x7E 0x80 0x01 0x02 0x92 0x7E} command).

    Cheers,

    Marie H

  • 0 in reply to Marie H
    TI__Expert 4890 points

    1) What version of the Linux GW SDK are you using?

        => 3.30.01.02

    2) When you say that sometimes the download process does not finish, can you quantify? E.g. 2 out of 5 attempts fail.

        => 3 - 4 out of 10 times

    3) Did they test with one or several boards? 

        => One CC1352 LaunchPad, but the board is fine with beaglebone as host

    4) Are they using a LaunchPad or a custom board?

        => Customer is using a custom board, but I can produce the issue on a Raspberry Pi + LaunchPad

    5) Can you check whether this command is also sent in success cases? (The {0x7E 0x80 0x01 0x02 0x92 0x7E} command).

        => No, it is not found on a successful case. Also I did more test and found the same packet sent to CC1352 when failure happened during erasing.

    BR,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru* 82431 points

    Hi Shuyang,

    Could you send me the full log?

    Cheers,

    Marie H

  • 0 in reply to Marie H
    TI__Expert 4890 points

    Sure, please find as attached, thanks!

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/156/Raspi_5F00_download_5F00_failed_5F00_0x7E.sal

    BR, 

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru* 82431 points

    Hi Shuyang,

    Sorry this is taking some time. We're investigating internally what's going on.

    Cheers,

    Marie H

  • 0 in reply to Marie H
    TI__Expert 4890 points

    Thanks Marie, please let me know if any further information is needed.

    BR,

    Shuyang

  • +1 in reply to Shuyang Zhong
    TI__Guru* 82431 points

    Hi Shuyang,

    Looking at the command in question, {0x7E 0x80 0x01 0x02 0x92 0x7E}, it looks like a HDLC format packet.

    Can you check whether the host device is using HDLC over the UART? 

    (You may be able to use the following command to view all processes: ps -A )

    Cheers,

    Marie H

  • 0 in reply to Marie H
    TI__Expert 4890 points

    Hi Marie,

      

    Weirdly, I cannot reproduce the issue with the same board after a Chinese new year vacation...

    I'm not using HDLC over UART, at least not intentionally. I used ps -A to print the running processes as below, and did not find a process related to HDLC, what is the name of the process? Since the issue cannot be reproduced under the current environment, I guess it is expected HDLC is not shown in the list.

    I will try again later to see if the issue will appear again. Thanks for the support!

      

    pi@raspberrypi:~ $ ps -A
    PID TTY TIME CMD
    1 ? 00:00:06 systemd
    2 ? 00:00:00 kthreadd
    3 ? 00:00:00 rcu_gp
    4 ? 00:00:00 rcu_par_gp
    8 ? 00:00:00 mm_percpu_wq
    9 ? 00:00:00 ksoftirqd/0
    10 ? 00:00:00 rcu_sched
    11 ? 00:00:00 migration/0
    12 ? 00:00:00 cpuhp/0
    13 ? 00:00:00 cpuhp/1
    14 ? 00:00:00 migration/1
    15 ? 00:00:00 ksoftirqd/1
    17 ? 00:00:00 kworker/1:0H-kblockd
    18 ? 00:00:00 cpuhp/2
    19 ? 00:00:00 migration/2
    20 ? 00:00:00 ksoftirqd/2
    23 ? 00:00:00 cpuhp/3
    24 ? 00:00:00 migration/3
    25 ? 00:00:00 ksoftirqd/3
    28 ? 00:00:00 kdevtmpfs
    29 ? 00:00:00 netns
    32 ? 00:00:00 kauditd
    33 ? 00:00:00 khungtaskd
    34 ? 00:00:00 oom_reaper
    35 ? 00:00:00 writeback
    36 ? 00:00:00 kcompactd0
    54 ? 00:00:00 kblockd
    55 ? 00:00:00 blkcg_punt_bio
    56 ? 00:00:00 watchdogd
    58 ? 00:00:03 kworker/3:1-mm_percpu_wq
    59 ? 00:00:00 rpciod
    60 ? 00:00:00 kworker/u9:0-hci0
    61 ? 00:00:00 xprtiod
    62 ? 00:00:00 kswapd0
    63 ? 00:00:00 nfsiod
    64 ? 00:00:00 iscsi_eh
    65 ? 00:00:00 dwc_otg
    66 ? 00:00:00 DWC Notificatio
    68 ? 00:00:00 vchiq-slot/0
    69 ? 00:00:00 vchiq-recy/0
    70 ? 00:00:00 vchiq-sync/0
    71 ? 00:00:00 vchiq-keep/0
    72 ? 00:00:00 SMIO
    75 ? 00:00:00 mmc_complete
    76 ? 00:00:00 kworker/1:1H-kblockd
    77 ? 00:00:00 kworker/0:1H-mmc_complete
    78 ? 00:00:00 kworker/3:1H-kblockd
    80 ? 00:00:00 jbd2/mmcblk0p2-
    81 ? 00:00:00 ext4-rsv-conver
    82 ? 00:00:00 ipv6_addrconf
    100 ? 00:00:00 kworker/2:2H-kblockd
    102 ? 00:00:01 systemd-journal
    170 ? 00:00:00 systemd-udevd
    191 ? 00:00:00 SMIO
    209 ? 00:00:00 mmal-vchiq
    210 ? 00:00:00 mmal-vchiq
    214 ? 00:00:00 mmal-vchiq
    217 ? 00:00:00 mmal-vchiq
    271 ? 00:00:00 cfg80211
    282 ? 00:00:00 brcmf_wq/mmc1:0
    283 ? 00:00:00 brcmf_wdog/mmc1
    336 ? 00:00:00 systemd-timesyn
    371 ? 00:00:00 cron
    376 ? 00:00:00 systemd-logind
    378 ? 00:00:00 avahi-daemon
    380 ? 00:00:00 thd
    381 ? 00:00:00 alsactl
    385 ? 00:00:00 dbus-daemon
    389 ? 00:00:00 NetworkManager
    392 ? 00:00:00 rsyslogd
    408 ? 00:00:02 rngd
    427 ? 00:00:00 avahi-daemon
    460 ? 00:00:00 wpa_supplicant
    468 ? 00:00:00 dhclient
    493 ? 00:00:00 polkitd
    494 ? 00:00:00 wpa_supplicant
    504 ? 00:00:00 hciattach
    505 ? 00:00:00 kworker/u9:2-hci0
    507 ? 00:00:00 bluetoothd
    593 tty1 00:00:00 agetty
    594 ttyS0 00:00:00 agetty
    595 ? 00:00:00 named
    602 ? 00:00:00 sshd
    663 ? 00:00:00 sshd
    666 ? 00:00:00 systemd
    667 ? 00:00:00 (sd-pam)
    681 ? 00:00:00 sshd
    682 pts/0 00:00:00 bash
    708 ? 00:00:05 kworker/1:2-events_power_efficient
    720 ? 00:00:00 kworker/2:1H
    795 ? 00:00:00 kworker/3:0H
    1124 ? 00:00:00 kworker/2:2-events
    1235 ? 00:00:00 kworker/0:0H
    1377 ? 00:00:07 kworker/0:1-events
    1378 ? 00:00:00 kworker/3:2-mm_percpu_wq
    1380 ? 00:00:00 kworker/2:0-events
    1381 ? 00:00:00 kworker/u8:0-brcmf_wq/mmc1:0001:1
    1383 ? 00:00:00 kworker/0:2-events
    1386 ? 00:00:00 kworker/u8:1-brcmf_wq/mmc1:0001:1
    1390 ? 00:00:00 kworker/1:0-events
    1394 ? 00:00:00 kworker/1:3-mm_percpu_wq
    1407 ? 00:00:00 kworker/2:1-events
    1408 ? 00:00:00 kworker/0:0-events
    1409 ? 00:00:00 sshd
    1415 ? 00:00:00 sshd
    1416 pts/1 00:00:00 bash
    1429 ? 00:00:00 kworker/3:0
    1430 ? 00:00:00 kworker/u8:2-events_unbound
    1431 pts/1 00:00:00 ps

      

    BR,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru* 82431 points

    Hi Shuyang,

    That's strange. Can the customer still reproduce on their device?

    I'm not sure what kind of HDLC process could be going on. The Linux GW SDK example is not invoking it. Not sure if something else on the Raspberry Pi is using the UART for something?

    Cheers,

    Marie

  • 0 in reply to Marie H
    TI__Expert 4890 points

    Hi Marie,

    The HDLC packets may come from the Thread border router application, which I set up on the same Raspberry Pi before. The border router service may run in background and send HDLC packets to UART. I just recalled the border router has been cleaned up before the last test was run.

    I checked with the customer and their problem is different, no HDLC packets were seen on their board, the CC2652 just does not respond to host's command sometimes. I will work with the customer to locate the exact behavior on their board, and create a seperate post for discussion, thanks.

    Best regards,

    Shuyang

  • 0 in reply to Shuyang Zhong
    TI__Guru* 82431 points

    Hi Shuyang,

    Thank you for the update. I will close this thread and await that you post a new one.

    Cheers,

    Marie H