Hi all,
I'm an engineer and my son's Karma stopped talking to the controller a few months ago. I was not able to deal with it for some time but I thought I would take my chances to bring it back to life.
I am starting this thread to log progress and report findings... I'm also hoping that maybe a more experienced fellow engineer might drop any ideas to help out.
The fault we are seeing is that the gimbal would not power on and the drone will not talk to the controller -- pairing is impossible. There is no other fault visible and the camera & gimbal work fine if connected to a handheld stabilizer.
I'm beginning to write this on my third second session on the drone -- so I do have some ideas of what is going on but allow me to document the steps so far at first.
Karma controller
The controller runs on an AMLogic chipset. Others have shown how to get the controller firmware downloaded to a PC. Look around this forum for more information. We'll also look inside the controller firmeare
Karma architecture - Initial inspection
Inside the drone there is a smaller STM32 ARM MCU and a more powerful TI DSP (DM368) running Linux. The smaller MCU handles the sensors and flight operations while the larger DSP handles the video coding from the camera.
- There are connectors that are marked "DEBUG" for both the STM and the DM CPUs (YEAH!!)
- Most of the fine-pitch components are potted. Although this is a good thing, it means there won't be any direct probing or component (re)soldering.
First debug attempt
The first attempted action was to get a cheap USB logic probe and connect to the signals, especially those marked as "Debug". The are UARTs running on 3.3V 115200, as also shown on my vintage Tek 465 oscilloscope. When the UART pins were identified, the next step was to connect a USB-to-UART module to each connector, to get a console for each CPU.
What seems to work....
The STM was working just fine and reports that it can talk to all of the sensors - except for the gimbal... It can't detect it. An interactive shell (nsh) is available and there are applications to run to test sensor status etc.
And what doesn't...
As you can see from the screenshots, the issue is that DM368 does not boot....(left terminal window). It reaches the user bootloader (UBL) but doesn't load the application code.... Is it some bad block in NAND, a misconfigured DDR, something else??
I'm an engineer and my son's Karma stopped talking to the controller a few months ago. I was not able to deal with it for some time but I thought I would take my chances to bring it back to life.
I am starting this thread to log progress and report findings... I'm also hoping that maybe a more experienced fellow engineer might drop any ideas to help out.
The fault we are seeing is that the gimbal would not power on and the drone will not talk to the controller -- pairing is impossible. There is no other fault visible and the camera & gimbal work fine if connected to a handheld stabilizer.
I'm beginning to write this on my third second session on the drone -- so I do have some ideas of what is going on but allow me to document the steps so far at first.
Karma controller
The controller runs on an AMLogic chipset. Others have shown how to get the controller firmware downloaded to a PC. Look around this forum for more information. We'll also look inside the controller firmeare
Karma architecture - Initial inspection
Inside the drone there is a smaller STM32 ARM MCU and a more powerful TI DSP (DM368) running Linux. The smaller MCU handles the sensors and flight operations while the larger DSP handles the video coding from the camera.
- There are connectors that are marked "DEBUG" for both the STM and the DM CPUs (YEAH!!)
- Most of the fine-pitch components are potted. Although this is a good thing, it means there won't be any direct probing or component (re)soldering.
First debug attempt
The first attempted action was to get a cheap USB logic probe and connect to the signals, especially those marked as "Debug". The are UARTs running on 3.3V 115200, as also shown on my vintage Tek 465 oscilloscope. When the UART pins were identified, the next step was to connect a USB-to-UART module to each connector, to get a console for each CPU.
What seems to work....
The STM was working just fine and reports that it can talk to all of the sensors - except for the gimbal... It can't detect it. An interactive shell (nsh) is available and there are applications to run to test sensor status etc.
And what doesn't...
As you can see from the screenshots, the issue is that DM368 does not boot....(left terminal window). It reaches the user bootloader (UBL) but doesn't load the application code.... Is it some bad block in NAND, a misconfigured DDR, something else??
