LAUNCHXL-CC1352R1: Gateway Server Startup Errors in Project Zero Tutorial

Hi Nayman,

What LAUNCHXL-CC1352R1 ZNP firmware version are you using?  Are there any other USB devices connected?  Have you verified it is connected and operating properly using Z-Tool?  You may want to power cycle the LaunchPad with the reset button while the host gateway tries to connect.  I've never verified BeagleBone Green usage but it shouldn't be a concern since the specs are similar.

Regards,
Ryan

Hi Ryan,

I am using Zigbee 3.0 Gateway 1.0.1 and I flashed the CC1352R1LP_GW_ZNP_UART.hex onto the launchpad. After clearing and flashing via Uniflash, Verifying says that the load was successful

Also for the debian image, I am using Stretch IoT (from this website https://elinux.org/Beagleboard:BeagleBoneBlack_Debian) as recommended because the link on the tutorial page didn't have Stretch IoT (Buster IoT instead).

As of now, I only have the launchpad connected to the BBGG which is connected to my computer, nothing else is connected to the launchpad or BBGG. How do you power cycle the LaunchPad? The start_local.sh script seems to do software resets since I see the green power LED periodically turn on and off but I can try doing a hardware reset when the script runs.

Do you have any pointers/links for Z-Tool? I've never used it before

Thanks,

Nayman

There is a reset button at the top of the LaunchPad, next to the micro USB connector on the XDS110 side.  You may also try a hard disconnect like what worked in this E2E thread.  And here is another relevant E2E thread that might help.  Also, Z-Tool is available as part of the Z-Stack software download and you can view the help file inside the GUI tool or check other E2E threads.

Regards,
Ryan

Sorry for the late reply. I have ZTool installed and it does not recognize any devices (with the Launchpad plugged in) even after power cycling / resetting the board. However, I am able flash images after UniFlash detects my launchpad. Do I need to change the baudrate in the serial devices settings (I see 2 comports linked to XDS110 in Windows Device Manager - one for application/user and one for data)? How should I proceed with the ZTool v2.0?

Best,

Nayman

Hi Toby,

Thanks for the response - I tried adjusting the settings with the baudrate + matching up the comport (User/Application) in Device Manager and I'm surprised ZTool still doesn't register anything. Dumb question but should I be using UART to USB connector? I just have the USB to microUSB cable.

Best,

Nayman

Connecting the launchpad and computer with USB cable should work (all the necessary hardware is within the debugger portion of the launchpad).

After adjusting the baudrate, you may need to scan for new devices in ZTool (Tools --> Scan for Devices).
Let us know if this works.

After scanning I still don't see the device, here is a screenshot of my current setup.

Can you check which chip revision do you use in Flash Programmer 2?

This is what I see after installing Flash Programmer 2

The chip revision looks OK. Which Z-Tool version do you use? I use Z-Rool v2.0.6 from simplelink_cc13x2_26x2_sdk_4_40_00_44 and it works fine.

I am also using Z-Tool v2.0.6, I think it was installed from a general installer Z-stack v3.0.2

That's strange that you cannot make this work. Can you take a picture to show me your LAUNCHXL-CC1352R1? Can you try this on another desktop to see if it works?

Yeah this is actually the 2nd Windows 10 desktop that I am currently trying since my first machine had the same problem.

Here is my LAUNCHXL-CC1352R1. Green LED is on

The problem is TXD/RXD jumpers on your LAUNCHXL-CC1352R1 are removed. Please mount them back and it should work.

I thought that miniUSB sufficed for connecting the launchpad to the desktop? The kit also only came with female to female jumpers

No, TXD/RXD jumpers on LAUNCHXL-CC1352R1 are mandatory to be closed.

Ah thanks! putting the covers back on allowed Z-Tool to detect it. I then tried to connect it to the BBGG host and the same initial phase 1 failure persists so I am back to debugging with Z-Tool. Any pointers from here? I can send a SYS_PING and it looks like I can receive something 

Do you open a new terminal accessing the host (eg PuTTY for BeagleBone Black) to run out-of-box gateway?

cd ~/source/out/Precompiled/servers
sudo ./zigbeeHAgw

yeah, looks like the problem connecting Launchpad from BB is still there after running those commands

Make sure you use the following settings in NPI_gateway.cfg

[DEVICE]
deviceKey=0 ; UART
#deviceKey=1 ; SPI

devPath="/dev/ttyACM0" ; UART/CDC
#devPath="/dev/ttyO4" ; UART

[UART]
speed=115200 ; speed
flowcontrol=0 ; 1=enabled 0=disable

Ah I noticed that the default was devPath="dev/tty04" for SPI instead of UART. I've changed it to ttyACM0 to match the connected launchpad as you suggested. Everything else matches - do I need to rebuild or something? Editing the file and re-running doesn't produce a different result.

No need to rebuild anything. Just revise the NPI_gateway.cfg and restart gateway to make it work.

Hm, still no difference  

My NPI_gateway.cfg looks like this:

[PORT]
port=2533

[DEVICE]
deviceKey=0 ; UART
#deviceKey=1 ; SPI
#deviceKey=2 ; I2C

#devPath="/dev/ttyUSB2";
#devPath="/dev/ttyO4" ; UART/CDC
devPath="/dev/ttyACM0" ; UART/CDC
#devPath="/dev/ttyO4" ; SPI
#devPath="/dev/i2c-2" ; I2C

[GPIO_SRDY.GPIO]
value="/sys/class/gpio/gpio132/value"
direction="/sys/class/gpio/gpio132/direction"
active_high_low=1 ; (Active Low=0, Active High=1)

[GPIO_SRDY.LEVEL_SHIFTER]
value="/sys/class/gpio/gpio137/value"
direction="/sys/class/gpio/gpio137/direction"
active_high_low=1 ; (Active Low=0, Active High=1)

[GPIO_MRDY.GPIO]
value="/sys/class/gpio/gpio135/value"
direction="/sys/class/gpio/gpio135/direction"
active_high_low=1 ; (Active Low=0, Active High=1)

[GPIO_MRDY.LEVEL_SHIFTER]
value="/sys/class/gpio/gpio136/value"
direction="/sys/class/gpio/gpio136/direction"
active_high_low=1 ; (Active Low=0, Active High=1)

[GPIO_RESET.GPIO]
value="/sys/class/gpio/gpio134/value"
direction="/sys/class/gpio/gpio134/direction"
active_high_low=1 ; (Active Low=0, Active High=1)

[GPIO_RESET.LEVEL_SHIFTER]
value="/sys/class/gpio/gpio136/value"
direction="/sys/class/gpio/gpio136/direction"
active_high_low=1 ; (Active Low=0, Active High=1)

[UART]
speed=115200 ; speed
flowcontrol=0 ; 1=enabled 0=disable

And when I cat /dev/ttyACM* I can verify that the launchpad is connected since ACM0 and ACM1 show up

Checking NpiLnxLog.txt gives:

[Wed Mar 17 06:18:03 202] Could not open device. Error: 02010300

Try to restart your BBB to test again. If it still doesn't work, can you show me your latest console log?

Ok, unplugged BB and made new Putty session, seems to be the same. By console log do you mean NpiLnxLog.txt?

[Wed Mar 17 06:39:34 202] Could not open device. Error: 02010300
[Wed Mar 17 06:39:39 202] Could not open device. Error: 02010300
[Wed Mar 17 06:39:43 202] Could not open device. Error: 02010300
[Wed Mar 17 06:39:48 202] Could not open device. Error: 02010300
[Wed Mar 17 06:39:53 202] Could not open device. Error: 02010300
[Wed Mar 17 06:39:57 202] Could not open device. Error: 02010300
[Wed Mar 17 06:40:02 202] Could not open device. Error: 02010300
[Wed Mar 17 06:40:06 202] Could not open device. Error: 02010300
[Wed Mar 17 06:42:14 202] Could not open device. Error: 02010300
[Wed Mar 17 06:42:19 202] Could not open device. Error: 02010300
[Wed Mar 17 06:43:12 202] Could not open device. Error: 02010300
[Wed Mar 17 06:46:22 202] Could not open device. Error: 02010300
[Wed Mar 17 06:46:27 202] Could not open device. Error: 02010300
[Wed Mar 17 06:46:31 202] Could not open device. Error: 02010300
[Wed Mar 17 06:46:36 202] Could not open device. Error: 02010300
[Wed Mar 17 06:46:47 202] Could not open device. Error: 02010300
[Wed Mar 17 06:46:52 202] Could not open device. Error: 02010300

verifying launchpad is plugged in:

debian@beaglebone:~/source/out/Precompiled/servers$ ls -l /dev/ttyACM*
crw-rw---- 1 root dialout 166, 0 Mar 17 06:46 /dev/ttyACM0
crw-rw---- 1 root dialout 166, 1 Mar 17 06:46 /dev/ttyACM1

Do you run zigbeeHAgw first?

yeah before I check the logs

What do you see on your terminal where you run zigbeeHAgw?

Startup Phase 1 still failing:

Executing reset from external scripts
===================================================
starting NPI, cmd ' ./NPI_lnx_arm_server NPI_Gateway.cfg -v 0x0000010E ' on Wed Mar 17 07:21:18 UTC 2021
[07:21:18.752,159] [NPISRVR/MAIN] UNMSKBL:
[07:21:18.752,637] [NPISRVR/MAIN] UNMSKBL:  ************************************************
[07:21:18.752,670] [NPISRVR/MAIN] UNMSKBL:  *  NPI Server v1.0.2d                          *
[07:21:18.752,694] [NPISRVR/MAIN] UNMSKBL:  ************************************************
[07:21:18.752,717] [NPISRVR/MAIN] UNMSKBL:
[07:21:18.760,951] [NPISRVR/MAIN] ERROR  : Could not initialize SoC... exiting
Startup phase 1 failed
making sure there are no lingering servers...
there are 0 NPI servers
there are 0 ZLS servers
there are 0 GATEWAY servers
there are 0 NWKMGR servers
there are 0 OTA servers
(total 0)
done

Can you take a picture to show me how you connect LAUNCHXL-CC1352R1 to your BBB?

Do you run prebuilt zigbeeHAgw or you run zigbeeHAgw that you build by yourself?

I am trying to follow this guide closely: https://dev.ti.com/tirex/content/simplelink_academy_cc13x2_26x2sdk_3_40_02_01/modules/zigbee/zigbee_05_zigbee_linux_gateway/zigbee_05_zigbee_linux_gateway.html

so ./setup.sh seems to build everything correctly since I can see an out folder instead of ERROR_OUT__ folder (I had that before but was able to re-build successfully). I have not re-built since and have been using the same sigbeeHAgw executable

Try touse the following steps to check if ZNP works properly on LAUNCHXL-CC1352R1 connecting to BBB first.

1. Open a BBB terminal and use "cat /dev/ttyACM0" to receive output from ttyACM0

2. Open another BBB terminal and use "echo -ne '\xFE\x00\x21\x01\x20' > /dev/ttyACM0" to send ping command to ttyACM0.

3. Check if there is anything output on terminal one.

Thanks for all the help by the way, I appreciate it

After sending bytes in Terminal 2 I do not see any output in the first terminal (running cat to listen as you suggest), even if ttyACM0 and ttyACM1 are valid devices.

• If you do not see any output in the first terminal after sending command in terminal 1, it seems that ZNP doesn’t work properly. Can you connect your LAUNCHXL-CC1352R1 back to your desktop and use Z-Tool again to test if it works?

Z-Tool seems to detect it fine:

Can you try to give power to your BeagleBone from 12V DC Adapter instead of USB power to see if it works?

My Beaglebone Green Gateway kit did not come with a 12V DC Adapter unfortunately and I don't have any spare ones on hand (except 5V but I don't want to damage the board by providing different voltage). Any other ideas?

Run out of idea...

This appears to be an issue with the BeagleBone Green hardware powering and identifying the LAUNCHXL-CC1352R1, not operation of the ZIGBEE-LINUX-SENSOR-TO-CLOUD software itself.  Perhaps a BeagleBone or Linux forum can support the detection of connected USB devices.

Regards,
Ryan

I agree with Ryan and that’s why I suggest using 12V DC Adapter to test again.