Project Logs

Collapse

• Day 0 - The basics #1

  Attila Sukosd • 06/07/2016 at 18:07 • 2 comments

  The back story
  

  To start off the project, the first step was to crack open the drone, and look at how things were setup. I probably wouldn't have started fiddling with it if one of the MOSFETs on one of the motor ports would not have smoked.

  Unfortunately it seems that some people face this with their drones, as I've seen a couple of complains on the Micro Drone 3.0 Google+ group around it. Anyway, I've emailed Extreme Fliers about the problem, and they have promptly shipped a replacement PCB for free of charge! Thanks EF!! :-)

  To cut the story short, I ended up having a surplus PCB with more or less everything working except the driver for a single motor, which makes it the perfect candidate to reverse engineer.

  The grand plan
  

  To get started with the project, I had the following plan to see if it's even feasible:

  • Take a glance at the PCB and try to deduce components
  • Research and identify each individual component
  • Research if other drones also use these components
  • Try to figure out the wiring between the components (come up with some sort of a schematics at the end)
  • Identify a way to interface with the micro controller to be able to program (and debug if possible)
  • Try to backup original firmware (if possible)
  • Create a small firmware which confirms that my code runs on the MD3.0!

  The hardware
  

  After scraping off some glue off the PCB, and reading off the text from the different ICs, the 3 main components of the drone are:

  • STM32F031K4: An ARM Cortex-M0 microcontroller, with 16K flash and 4K ram
  • MPU-6050: A six-axis Gyro + Accelerometer with MEMS MotionTracking
  • XN297: 2.4Ghz RF chip for communicating with the transmitter

  + some LEDs, motor drivers, and etc.

  Research on other drones with similar hardware
  

  After googling for a bit, it turns out that there are at least a couple of drones that use the same (or quite similar) set of hardware components, including the Cheerson CX-10, so there is definitely hope of getting something up and running. Reading through the threads, and looking at the github projects, gave some encouragement that I'm not completely alone in trying to figure out stuff, so there would be some people to reach out to for some help.

  Generally I'm quite impressed with the RC geeks community at RCGroups, those guys really know what they're talking about! I've joined the site early 2007 when I wanted to work on an autonomous solar powered glider, but like it always is, life took over, and that project never materialized. The frame of the glider with it's 2 meter wing span does make a great lamp cover though... I still haven't give up hope on it completely... :-)

  Interfacing with the micro-controller
  

  To figure out how much effort would it be to get some code running on the STM32, I had to research a bit about how to connect to it. After looking at the PCB for a bit, I've noticed a number of TPs (test points) broken out on it.

  Since I've been through designing some electronics a couple of times already, I could assume that these TPs that are exposed are used for production testing + programming of the chips, since this is how I would have designed it too. However I couldn't see a clear set of headers that sometimes comes with electronics, which would expose a UART or a JTAG interface. I did notice some curious silkscreen on some of the TPs labelled SC, RST, SD, GND and some others which I couldn't really read no matter how hard I tried.

  Digging a bit through the STM32 datasheet and hardware application note, it turns out that most of these ARM chips have more or less dropped the JTAG interface in favor for a lower pin count SWD (Serial Wire Debug), which requires 3 pins:

  • GND - to have a common ground (as always)
  • Clock - the clock signal which drives the transmission (SC in our case)
  • Data - the bidirectional data signal (SD in our case)

  Now this was only a theory up to this point. I needed to get my hands dirty to see if my hypothesis was right.
  

  To get started with anything, I needed to find a way to program the chip. The usual way for this would be to...

  Read more »

View project log