cc2531 won't be recognized by chipid.

[imdos]

I have bought a serie of CC2531 chips and tried to flash through flash_cc2531, but got stuck on recognition. I haven't tried to flash it and did a fall-back to CC-Debugger and the smartRF flash on Windows.

Everytime I try with the other chip I received I get the following:
ID = ffff.

With the right chip I receive the correct output: ID = b524.

The output from dmesg. With the working one: [ 6651.753985] usb 1-1.4: New USB device found, idVendor=0451, idProduct=16a8, bcdDevice= 0.09

With the failing one: [ 6781.541867] usb 1-1.3: New USB device found, idVendor=0451, idProduct=16ae, bcdDevice=45.00

[eric-void]

I've the same issue. Found a solution?

[imdos]

Yes, just flashed it with smartFR and the debugger without problems. Haven't bothered further to be honest.

[FF-Fox]

I had the same issue, this was the dmesg output:

[    3.353374] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    3.505494] usb 1-1.2: New USB device found, idVendor=0451, idProduct=16ae, bcdDevice=45.00
[    3.520837] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.531805] usb 1-1.2: Product: CC2531 USB Dongle

I couldn't get it to work with flash_cc2531 no matter what. Since I didn't have a CCdebugger and didn't want to wait for one to arrive, I took a different approach. I did have an arduino Nano laying around, on a breadboard. So I just swapped the jumper cables from the rpi to the breadboard and used CCLoader. This is the result of dmesg after the flash:

[    3.353358] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    3.508948] usb 1-1.2: New USB device found, idVendor=0451, idProduct=16a8, bcdDevice= 0.09
[    3.524062] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.534956] usb 1-1.2: Product: TI CC2531 USB CDC

And now it works with Zigbee2MQTT.

So, not really a solution for this problem, but another workaround if you don't have a CCdebugger but an arduino at your disposal.

[ago19800]

Hi I flashed with ccloader it seems to me all went well, but when I connect cc2531 to the raspberry is not recognized, advice? Thanks

[konyee]

I had same issue. Workaround: remove cc_delay_calibrate() from cc_init() an set cc_delay_mult=80. make it. after cc_chipid you should read ID=b522. Tested with rpi3b

[AlmightyFrog]

Not sure If suggestion of @konyee did help me or not. I had issue that ID by cc_chipid was always ffff.

After changing @konyee sugestion I got at least different readings. Mostly ID = b522, but sometimes also ID = 0088 and ID = 0000.

I just anyhow tried cc_write and it seemed to work flash correctly (at least it told verify successful). Also device is now recognized as USB ACM device and as per zigbee2mqtt it contains firmware of zStack with revision 20190608 which is just what I tried to flash.

[ago19800]

I had same issue. Workaround: remove cc_delay_calibrate() from cc_init() an set cc_delay_mult=80. make it. after cc_chipid you should read ID=b522. Tested with rpi3b

Sorry I didn't understand what to do. Can you explain me better Thanks

[stheine]

I had same issue. Workaround: remove cc_delay_calibrate() from cc_init() an set cc_delay_mult=80. make it. after cc_chipid you should read ID=b522. Tested with rpi3b

Thanks for that info. In My case I had to set cc_delay_mult=90 until cc_chipid finally responded with b522, but then I successfully flashed.

[stheine]

@ago19800

Sorry I didn't understand what to do. Can you explain me better

After cloning the repo, edit CCDebugger.c, modify the line 177

static int cc_delay_mult=50;

into

static int cc_delay_mult=80;

and the line 83

  cc_delay_calibrate();

into

//  cc_delay_calibrate();

save the file and call make to rebuild the binaries. call cc_chipid and see if it responds with b522. If not, you might have to repeat the above, setting the new value from 80 to 90 or any other number (in my case, the calculated value was 29, so I tried the values 30/40/50/60/70/80/90 until it finally worked). after each modification of the number, don't forget to call make to rebuild the binaries.

[ago19800]

@ago19800

Sorry I didn't understand what to do. Can you explain me better

After cloning the repo, edit CCDebugger.c, modify the line 177

static int cc_delay_mult=50;

into

static int cc_delay_mult=80;

and the line 83

  cc_delay_calibrate();

into

//  cc_delay_calibrate();

save the file and call make to rebuild the binaries. call cc_chipid and see if it responds with b522. If not, you might have to repeat the above, setting the new value from 80 to 90 or any other number (in my case, the calculated value was 29, so I tried the values 30/40/50/60/70/80/90 until it finally worked). after each modification of the number, don't forget to call make to rebuild the binaries.

Thanks it works :)

[ago19800]

![Uploading IMG_20191125_151138_373.jpg…]()

[ThePatcher80]

and how i do that? don't forget to call make to rebuild the binaries.

[ago19800]

and how i do that? don't forget to call make to rebuild the binaries.

You have to give only make. Stop

[JonSilver]

I had same issue. Workaround: remove cc_delay_calibrate() from cc_init() an set cc_delay_mult=80. make it. after cc_chipid you should read ID=b522. Tested with rpi3b

This fix worked for me as well. I have 2 CC2531 USB boards with an external SMA antenna, and 2 with a PCB trace antenna. Before the fix, the SMA antenna boards were recognised fine, and could be programmed and verified. But the PCB trace antenna boards could not, having chip ID ffff.

After the fix, all the boards could be recognised, erased, written and verified.

@jmichault Can this fix not just be incorporated into the code so users don't need to hack and make?

[jmichault]

The last release has increased delays for better stability and a new command line option to force the multiplier delay : -m . Can you try this ? For example: ./cc_write -m 100 FILE_TO_FLASH.hex

[kornykorn]

I'm having the same issue on a pi 3b+ (with openhabian, also tried with raspbian).

Using the standard- settings, I receive ID 1fff, 3fff, 7fff or something simillar (xfff). I changed the code like suggested (removed the calibrate-call) and tried delay-mult values from 0 to 300 - without succes. low values lead to random IDs (most of the time eding with one or 2 times f, like xxff), mid-range values (roughly 20 to 150) to ID's like initially, and high values to ffff.

I also re-checked the wiring a couple of times, but this looks all good (soldered wires, roughly 30cm long).

Does anybody have an Idea?

Thanks!

EDIT, 17.1.2019: Found the issue, I had a broken wire. Now everything works like expected (Pi 3B+, Openhabian)

[grigio]

Tried https://github.com/jmichault/flash_cc2531/issues/9#issuecomment-558128187 with Raspberry Pi Model B Rev 2 but I always get ID = 0000.

[    2.262963] usb 1-1.2: Product: CC2531 USB Dongle
[    2.262973] usb 1-1.2: Manufacturer: Texas Instrument

[grigio]

For me the problem of ID = 0000. was the Raspberry Pi Model B Rev 2.

I've used the esp8266 and it worked immediatly with the same wiring with this path https://www.zigbee2mqtt.io/information/alternative_flashing_methods.html#via-arduino-unoesp8266-with-ccloader-3hrs

[oscarlinux]

@ago19800

Sorry I didn't understand what to do. Can you explain me better

After cloning the repo, edit CCDebugger.c, modify the line 177

static int cc_delay_mult=50;

into

static int cc_delay_mult=80;

and the line 83

  cc_delay_calibrate();

into

//  cc_delay_calibrate();

save the file and call make to rebuild the binaries. call cc_chipid and see if it responds with b522. If not, you might have to repeat the above, setting the new value from 80 to 90 or any other number (in my case, the calculated value was 29, so I tried the values 30/40/50/60/70/80/90 until it finally worked). after each modification of the number, don't forget to call make to rebuild the binaries.

Thanks this worked for me!

[tykarol]

I went around this problem using the "-m" parameter:

./cc_checkid -m 90
./cc_erase -m 90
./cc_write -m 90 xxx.hex

Maybe it will help someone else :)

[gladius7]

When entering the command: ./cc_chipid   gives me ./cc_chipid: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory though git clone https://github.com/jmichault/flash_cc2531.git set and transition I do cd flash_cc2531 Can anyone help?

[magostinelli]

@gladius7 sudo apt-get install wiringpi

[Equidamoid]

Had the same problem, cc_chipid was giving either 0000 or ffff. Proposed changes in CCDebugger.c did nothing.

Solved by bending the pins on the board and using combination of slightly mangled dupont connectors and pieces of paper for isolation.

First flashing gave 5 errors, second one succeeded.

[ljan]

@tykarol this should be in the tutorial! Thanks a lot

[gtb08177]

Solved by bending the pins on the board and using combination of slightly mangled dupont connectors and pieces of paper for isolation.

Hey @Equidamoid , I am seeing the same as you - could you go into a little bit more detail on the bending of pins and paper isolation? My depont cables seem to fit nicely but curious to the isolation piece.

Thanks

[Equidamoid]

Hey @gtb08177,

Can't find any photos right now. The idea is to remove the plastic sleeves, slightly compress the connectors from sides so they hold the thinner pins better. The connectors still will not fit together though, so I bent the required pins outwards a bit. They were still too close and touched each other sometimes so I had to stick some pieces of paper in between.

On Sun, 28 Jun 2020, 23:23 gtb08177, notifications@github.com wrote:

Solved by bending the pins on the board and using combination of slightly mangled dupont connectors and pieces of paper for isolation.

Hey @Equidamoid https://github.com/Equidamoid , I am seeing the same as you - could you go into a little bit more detail on the bending of pins and paper isolation? My depont cables seem to fit nicely but curious to the isolation piece.

Thanks

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jmichault/flash_cc2531/issues/9#issuecomment-650823690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACEWACCPGCSSM4246CSS5LRY6YEJANCNFSM4ITETRIA .

[moskovskiy82]

Increasing the value to 90 from default 80 helped!!! Thanx. I believe this should be included in the zigbee2mqtt page

usb 1-1.3: New USB device found, idVendor=0451, idProduct=16ae, bcdDevice=45.00

[AbaloneIron]

And don't be a dumb-ass like me. If you have an older Raspberry Pi, and don't have 40 pin bus, the defaults won't work. Do a "gpio readall" to see what you are working with, move some connections around to valid gpio's and use some of the switches that are available to the command. This worked for me when I got connected to my satisfaction: ./cc_chipid -r 2 -c 5 -d 4

Hope this makes sense.

[DrDOIS]

I had the same issues, getting IDs like 1fff, 3fff and 7fff. In the end the issue was my assumption about the order of pins, which I counted like those of a MC (counter clockwise). Make sure you count them like on the Raspberry (There is even a 10 at Pin 10 which I read as IO).

[Kamilake]

Thank you very much! I completely solved the problem. Set the value of cc_delay_mult to 500.

[lslomczynski]

Hello everyone!

Just wanted to say:

• Thank you for providing your solutions!
• For mine CC2531 with external antenna the proper value of cc_delay_mult was 110 :-)

[lnarolski]

In my case programming started working after changing from Raspberry Pi 4B to Raspberry Pi 3B and using the solution above (i had to set cc_delay_mult to 90)

[geertmeersman]

For the ones with a Raspberry Pi 4: Install the latest version of wiringpi => cd /tmp wget https://project-downloads.drogon.net/wiringpi-latest.deb sudo dpkg -i wiringpi-latest.deb

[wang70880]

Previously I also failed to get the correct ID. After several trials and errors, I found that I connected the debug port in the wrong direction. Hope this can help someone.

[Jtef]

I managed to successfully connect after I updated wiringpi as @geertmeersman indicated for Raspberry Pi 4. Cheers!

[theshooter1844]

And don't be a dumb-ass like me. If you have an older Raspberry Pi, and don't have 40 pin bus, the defaults won't work. Do a "gpio readall" to see what you are working with, move some connections around to valid gpio's and use some of the switches that are available to the command. This worked for me when I got connected to my satisfaction: ./cc_chipid -r 2 -c 5 -d 4

Hope this makes sense.

Thank you so much. This saved me hours. I can confirm that RPi Model B Rev 2 doesn't use all the GPIO pins. With "gpio readall" I found out what pins were working, used the same ones: ./cc_chipid -r 2 -c 5 -d 4 connecting on the GPIO to pin13 (RST), pin18 (DC) and pin16 (DD). And got it finally to "flash OK".

[ghost]

0000 and ffff with pi3 and default wires

[philipp2310]

0000 and ffff with pi3 and default wires

to be honest I would say, you just short the pins with your setup

[topche]

I have some issue here. I did change static int cc_delay_mult=110; and // cc_delay_calibrate(); make it again and still have ID=0000

check the wiring and it is fine:

https://photos.app.goo.gl/vmNmipNFFUEqo5KV8

any ideas ?

[jmichault]

On your photos, i have the impression you have connected 1,5,6 and 7 instead of 1,3,4 and 7 ?

broche GPIO	broche CC
39 ( GND )	1 ( GND )
36 ( wPi 27, BCM16 )	3 ( DC )
38 ( wPi 28, BCM20 )	4 ( DD )
35 ( wPi 24, BCM19 )	7 ( reset )

[topche]

On your photos, i have the impression you have connected 1,5,6 and 7 instead of 1,3,4 and 7 ?

broche GPIO broche CC 39 ( GND ) 1 ( GND ) 36 ( wPi 27, BCM16 ) 3 ( DC ) 38 ( wPi 28, BCM20 ) 4 ( DD ) 35 ( wPi 24, BCM19 ) 7 ( reset )

You have correct impression :)

I lost my patience and did it with NodeMCU the flashing. Was success. All works now.

[duceduc]

Finally got it working. I was about to throw in the towel. My issue was the power. Followed the guide on zigbee2mqtt site suggesting an option to power the CC2531 board using the rpi zero gpio pin. After changing so many mult #s. It always show 000. Then, I plug the CC2531 board in an outlet for power and it finally output b524.

Success:

[gumslone]

I successfully received the chip id with this command:

./cc_chipid -m 100

with simple ./cc_chipid I always received fffff

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[NeOdYmS]

I had same issue. Workaround: remove cc_delay_calibrate() from cc_init() an set cc_delay_mult=80. make it. after cc_chipid you should read ID=b522. Tested with rpi3b

It worked for me I edited CCDebugger.c

juste removed cc_delay_calibrate(); line

and did a $ make

Thanks a lot 🙏

[Oddiwahn]

Worked for me on an OrangePI zero. This helped me: https://jmichault.github.io/flash_cc2531-dok/de/

What I did:

1. get WiringPI for the OrangePI http://www.orangepi.org/Docs/WiringPi.html
2. I connected RESET to PIN 3, DC to PIN 5 and DD to PIN 7
3. I had to run ./cc_chipid which gave me "fffff"
4. Then I ran ./cc_chipid -r 0 -c 1 -d 2 -m 1 which gave me "b524"
5. repeating step 4 resulted in "ffff" again, I had to run step 3 frist, then step 4 worked
6. Also I ran step 3 before erasing and flashing (also with arguments -r 0 -c 1 -d 2 -m 1)

Chris

[ahlininv]

Absolute and strongest thanx for @duceduc https://github.com/jmichault/flash_cc2531/issues/9#issuecomment-843671505

I've never heard that we have to plug the stick in usb When you are not connected you have 0000 if timeout is small and linear growing up to ffff when you make timeout greater. When you plug it in - you get ID right

[slavb18]

My device ID = b523.

Worked using ./cc_write -m 500 CC2531ZNP-Prod.hex, may be it can help someone