Last version NRF firmware, radio error
Re: Last version NRF firmware, radio error
About not being able to do 'make cload'. Are both of M2 and M2 LEDs slowely blinking once you start it?
About the receiving and answering, what do you mean exactly? Do you connect with the crazyflie through the CFclient or do you do OA update with the cfloader?
About the receiving and answering, what do you mean exactly? Do you connect with the crazyflie through the CFclient or do you do OA update with the cfloader?
Re: Last version NRF firmware, radio error
Re first question, yes, both LEDs are slowly blinking.
Re second question, what I am trying to do is an OA firmware update via the cfloader. To do so, I enter bootloader mode, were both LEDs (M2 and M3) are blinking in blue. Then, I try to flash he firmware via and the terminal output is always
The strange thing is that during this 10 seconds the M4 green LED is constantly blinking which, as far as I know, it means that data is being received by the crazyflie.
This led me to think that maybe the problem was in the bootloader so I tried reflashing it both via dfu-util
and via SWD with the command
Although both operations finish without errors, none of them solved the problem. However, if I try any of the previous solutions (DFU or SWD) with another board,everything works as expected and I am able to flash both the nrf51 and the stm32 firmwares OA.
At this point, and since the other board works as expected, I am starting to think that I have some faulty hardware.
Some other tests that I ran and that might help in diagnosing the issue are:
- After flashing the firmware on the stm32, if I perform a scan searching for crazyflies the M4 LED turns red for a fraction of a second, but the green LED in the radio never lights up.
- Flashing the stm32 firmware in DFU mode or via SWD does not change the behavior of the crazyflie. Although both procedures succeed, flashing it by any of the two methods always results in the same behavior.
- After flashing the firmware, I am able to detect the crazyflie with the client if I connect it via USB to the PC. However, the cazyflie is unresponsive (the orientation viewer in the client never gets updated)
- When powering the crazyflie the M1 LED on the never lights up. The M4 LED blinks in red and green and then turns off and the M3 and M2 LEDs present a solid blue.
Any other ideas that I might have overlooked? Or am I right in thinking it might just be a hardware issue?
Again, thanks for your help.
Re second question, what I am trying to do is an OA firmware update via the cfloader. To do so, I enter bootloader mode, were both LEDs (M2 and M3) are blinking in blue. Then, I try to flash he firmware via
Code: Select all
bin/cfloader flash cf2.bin stm32-fw
Code: Select all
Restart the Crazyflie you want to bootload in the next
10 seconds ...
Cannot connect the bootloader!
This led me to think that maybe the problem was in the bootloader so I tried reflashing it both via dfu-util
Code: Select all
sudo dfu-util -d 0483:df11 -a 0 -s 0x08000000 -D cf2loader-1.0.bin
Code: Select all
make flash
At this point, and since the other board works as expected, I am starting to think that I have some faulty hardware.
Some other tests that I ran and that might help in diagnosing the issue are:
- After flashing the firmware on the stm32, if I perform a scan searching for crazyflies the M4 LED turns red for a fraction of a second, but the green LED in the radio never lights up.
- Flashing the stm32 firmware in DFU mode or via SWD does not change the behavior of the crazyflie. Although both procedures succeed, flashing it by any of the two methods always results in the same behavior.
- After flashing the firmware, I am able to detect the crazyflie with the client if I connect it via USB to the PC. However, the cazyflie is unresponsive (the orientation viewer in the client never gets updated)
- When powering the crazyflie the M1 LED on the never lights up. The M4 LED blinks in red and green and then turns off and the M3 and M2 LEDs present a solid blue.
Any other ideas that I might have overlooked? Or am I right in thinking it might just be a hardware issue?
Again, thanks for your help.
Re: Last version NRF firmware, radio error
We discussed your issue here at the office, but the symptoms are not something that we experienced before and we can not reproduce your problem. It might be a hardware issue but we are not sure. You can try to reflash the bootloader of both the NRF and STM, and the regular firmware again (don't use dfu). Maybe reset the eeprom might help? https://wiki.bitcraze.io/doc:crazyflie: ... set_eeprom
Since you have a debugger adapter already, you can try out on-chip debugging and poke around in the firmware and see where it goes wrong. you can see for instructions how to do that here https://wiki.bitcraze.io/projects:crazy ... _debugging.
Sorry we can't help you out further on this. Give us an update if you find something new about your situation.
Since you have a debugger adapter already, you can try out on-chip debugging and poke around in the firmware and see where it goes wrong. you can see for instructions how to do that here https://wiki.bitcraze.io/projects:crazy ... _debugging.
Sorry we can't help you out further on this. Give us an update if you find something new about your situation.
Re: Last version NRF firmware, radio error
I think I might have an idea what is going on. When the CF2.1 came out we added an identification string in the nRF51 mbs and to the STM32 OTP. The STM32 OTP is persistant but the nRF51 is just a string in the flash of the MBS so that was erased when you did "make factory_reset". As the radio PA is different on the CF2.0 and the CF2.1 your CF now things it is a CF2.0 and does not activate the PA the right way, thus you basically loose radio communication.
To recover from this, build the MBS FW with "make PLATFORM=CF21" and flash it with you debugger.
To recover from this, build the MBS FW with "make PLATFORM=CF21" and flash it with you debugger.
Re: Last version NRF firmware, radio error
I seem to have the exact same problem.
Against all advice I have reflashed everything (I think) all bootloaders and firmware. I've also tried to do all of this with the flags for CF21 I could find. All flashing seems to have gone perfectly fine. The units start as expected, flashes 5 times to indicate proper startup. I can connect via USB, I've reset the eeprom to the default address. All works, except for connection via bluetooth or radio.
Any help would be appreciated!
Against all advice I have reflashed everything (I think) all bootloaders and firmware. I've also tried to do all of this with the flags for CF21 I could find. All flashing seems to have gone perfectly fine. The units start as expected, flashes 5 times to indicate proper startup. I can connect via USB, I've reset the eeprom to the default address. All works, except for connection via bluetooth or radio.
Any help would be appreciated!
Re: Last version NRF firmware, radio error
Then it is most likely the MBS that has the wrong identification string. Can you try flashing this again? Make sure to build from a clean state and with PLATFORM=CF21. "make clean all PLATFORM=CF21" should do it.
-
- Beginner
- Posts: 1
- Joined: Fri Dec 04, 2020 10:18 am
Re: Last version NRF firmware, radio error
Damm even I am having a similar kind of issue, I have searched all over the internet and even have posted on number of threads on different forum, no solution seems to work. I am really frustrated, can anyone of you here help me resolve this issue, I am very much tired now.
Re: Last version NRF firmware, radio error
Please start a new forum thread and more carefully explain your situation.