You are unzipping the file first.
Don’t you think the flash will fail if I will NOT unzip the files?
Or will I see the FW version as I showed in my logs?
Anyway,
some magic happened… Yesterday (and also today) I was trying to switch between 2 usb ports and I wasn’t able to get any zigbee activity. But at the end, I just in case, decided to try to put it in additional, other (3 from 4) usb port and it started to work just perfect!
Pairing fine within long distance as well no problem.
According to the docs, you specify the port in the config file. The default is /dev/ttyACM0
# Required: serial settings
serial:
# Required: location of CC2531 USB sniffer
port: /dev/ttyACM0
Step 1 of the configuration instructions explains how to confirm which port the CC2531 is connected to and is the recommended procedure for identifying the port (as opposed to playing ‘port-roulette’).
FWIW, if you have more than one USB-connected device, Linux may re-map the ports on startup (there are ways to mitigate this behavior) … and that may cause you to play ‘port-roulette’ again.
If I had a problem with the port I would never get the FW version…
If you’re claiming you never had a problem with the port then your post marked as solution is misleading because it claims that changing ports fixed the problem.
Read my post.
I changed PHYSICAL USB PORT.
And yes, after I changed usb port the mapping is still remain /dev/ttyACM0 …
That’s how I understood it; you plugged the CC2531 into the available PHYSICAL ports until you found one that resolved the issue.
If you have only one device connected to the USB bus, that gambit will work (the first physically connected device is assigned ttyACM0). It won’t if there are several devices connected due to the way ports are dynamically mapped at startup.
Nope, you’re wrong.
It is logical enumeration.
Try connecting regular usb flash and check how it detected (for example sdb). Remove it, and put in other usb port. Check again how your usb appears now.
And regarding my issue, the port (logical) was configured just fine. Mostly probably that particular usb ports got not enough electrical power to feed the stick.
It’s what I’m saying but, apparently, not effectively. Regardless, there’s something peculiar about the notion that a (physical) USB port that can successfully transfer the CC2531’s entire firmware but then stumble with the operation of pairing devices. Odd.
Probably there’s enough power to read the FW from the chip but not enough to power zigbee interface…
That’s an interesting theory, implying there’s sufficient voltage (to allow the circuitry to minimally function) but insufficient current (to drive all of the circuitry when in full operation). Given that USB ports are sourced by a common power bus, the deficiency would affect more than one port. You did mention that two ports were affected whereas the other two were not. Perhaps the other two are connected to a separate bus.
yes, exactly, checked now in the schematics and looks like different buses…
Maybe your CC2531 is faulty?
e.g. perhaps the RF frontend is damaged and the zigbee processor thinks its listening but in reality will never receive a signal.
This is consistent the above.
The cc2351 is powered up and its microcontroller is operating and communicating via USB, but not able to communicate via 2.4ghz zigbee…
Also this said I have had much difficulty pairing some new devices with z2m 1.5.1.
Once moved to other physical usb port all working perfect so far.
1 Like
Excellent!
Is it a difference between USB2 and USB3?
Actually they all usb3.
The only difference I can tell, the usb port that works for me is “yellow” type, means always on…
So quite likely a power management issue - what is the computer you are using? And OS?
I’m with NUCi3 and ubuntu18
I had a similar issue and a 50cm usb extension worked for me.