Bitcraze Forums

I was up late debugging/setting up my cool new Crazyflie 2.0. I had another bug with radio connectivity before I did anything, and I tried to fix it by flashing newer firmware.

I think I may have flashed the non-PA firmware to the Crazyradio PA (but used the PA flags when building). It is now detectable by both my Windows 7 Host OS and the Crazyflie VM guest in Virtualbox, but neither will let the Crazyflie PC client see/use the radio, and querying with:
> lsusb -d 1915:7777 -v | grep bcdDevice

returns V 99.55

Which obviously isn't correct. Now when trying to flash the correct PA firmware binary downloaded from here:
https://github.com/bitcraze/crazyradio- ... e/releases

the flashing program fails. Here is the complete terminal printout:


itcraze@bitcraze-vm:~/Desktop/projects/crazyradio-firmware$ python3 usbtools/launchBootloader.py
Launch bootloader
....
Error!, bootloader not started
bitcraze@bitcraze-vm:~/Desktop/projects/crazyradio-firmware$


(It actually is started, I tell virtualbox to connect the device in bootloader mode back to the guest OS, run that again, it will say bootloader already started)


bitcraze@bitcraze-vm:~/Desktop/projects/crazyradio-firmware$ python3 usbtools/nrfbootload.py flash cradio-pa-0.53.bin
Found nRF24LU1 bootloader version 18.0
Flashing:
Flashing 5810 bytes...
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/usb/_interop.py", line 134, in as_array
return array.array('B', data)
TypeError: integer argument expected, got float

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "usbtools/nrfbootload.py", line 135, in <module>
if bl.write(fileData):
File "/home/bitcraze/projects/crazyradio-firmware/usbtools/NrfUsbBootloader.py", line 139, in write
if not self.writePage(data[i:(i+PAGE_SIZE)], (address+i)/PAGE_SIZE):
File "/home/bitcraze/projects/crazyradio-firmware/usbtools/NrfUsbBootloader.py", line 107, in writePage
self.handle.bulkWrite(0x01, (CMD_PAGE_ERASE, pageNum), 1000)
File "/usr/local/lib/python3.4/dist-packages/usb/legacy.py", line 148, in bulkWrite
return self.dev.write(endpoint, buffer, timeout)
File "/usr/local/lib/python3.4/dist-packages/usb/core.py", line 877, in write
_interop.as_array(data),
File "/usr/local/lib/python3.4/dist-packages/usb/_interop.py", line 139, in as_array
a.fromstring(data)
TypeError: 'tuple' does not support the buffer interface



I learned my lesson and will cut myself off before I get sleep deprived and try to play with low level stuff, but this is so cool and I'm thrilled it's all in Python. I have the SPI interface, do I need to lookup the procedure to do that or is there something else I can try first? It doesn't seem bricked in the conventional sense, but something is definitely wrong. What is going on here, is there a bug in 'nrfbootload.py' or is this unhandled because no one was stupid enough to flash the wrong firmware? Lol

I would like to add that it did say 'Verified' or whatever at the end of the flash, but I assume this is a checksum of flashed data or something, not a check to make sure it was the right data for some hardware.

Any help is appreciated, I am working in a class and have had the first shot at this drone and want to fix it before I hand it off to the next person. We will hopefully be doing dev the rest of the semester so I look forward to that once I get the drone working again and also resolve the previously mentioned (but will post new thread if needed) Crazyradio connectivity issues.

Hi,

If you can still launch the bootloader then you are not out of luck, it is still possible to flash the firmware!

The version you see if normal if you flashed the master firmware from the git repos: I always set the version to 99 after a release which allows me to work on the lib during development (ie. in that case a test for version >= 0.56 will work during development and when the release time come I just change 99.55 to 0.56). It also has the advantage to look "obviously isn't correct" so that people understand they are running a development firmware.

Your problem is that these usb tools are not compatible with Python3. They are set as executable so you should just run them like

Came back here to update. So I did not realize the crazyflie has to be turned on and present for the radio dongle to be detected by the Crazyflie client. After I found an error I must have turned it off to save battery and left it like that. It does seem unintuitive to me that the radio would not show up in the software at all. I would expect the radio to show up, but then upon connecting, fail to find a Crazyflie or something.

I was going to say everything is fine, except that version error, but if that is for development purposes, then there is nothing wrong! Sorry for wasting time. I had no idea there was a legitimate reason to return the wrong version. Yes I did get it from git, I did not realize you could just download the bin from somewhere LOL.

Edit: Thinking about it, it would not make sense that random error could produce a shifted firmware version AND be detected in both normal and bootloader mode. Interesting idea. Thanks for getting back to me, I look forward to doing some dev this semester!

I am glad your problem is solved!

The reason the radio does not show in the client when you scan is because the client does not list radios, it lists detected link to a copter and by which mean they have been detected (maybe that could be made more clear in the GUI). If you want to check that a radio is connected you can look in the about box in the debug tab, it lists the radio and its version.

Yes, I realized that a bit later. Thanks for the help!