Skip to content

Latest commit

 

History

History
82 lines (71 loc) · 4.05 KB

TODO.md

File metadata and controls

82 lines (71 loc) · 4.05 KB
Raw

Reverse Engineering TODO

For the most part the Reverse Engineering subtask has served its purpose. At this point a developer should be able to continue onto firmware tasks based on previous work and datasheets. There are two reasons why the Reverse Engineering effort might be further continued at this point:

  1. In hopes of finding other unused or hidden features (i.e. USB communications protocol that could allow for adding custom Jingles without needing to update firmware).
  2. For the sake of completeness (i.e. mapping out all functions, IRQs, callbacks, etc.). Might be educational to see how all of this was implemented.

I am considering both of these to be low priority and most likely will not put much effort into further Reverse Engineering.

Notes

Below are less verbose notes on items I would like to dig into. These are a bit terse and may not be worded well. Please ask if you have any questions:

  1. Jingle Sim related

    1. Details on CT32B0 ISR based on simulation results?
    2. Details on each function call

  2. Clean, clean, clean

    1. gdbCmdFile, gdbCustomCmds, gdbOldRef
    2. PINT3 dump
    3. Cleaning other ISRs and looping paths so that they make sense when I come back after I have forgotten everything.
    4. Make sure all known functions have details in .h file

  3. Is AD6 battery gauge/power?

    1. Try putting dead (or nearly dead) battery in and checking
      1. But maybe GPIOs, etc. need to be set differently?

  4. Make TODOs for maybe in the future getting more details on following IRQs

    1. PINT0
    2. PINT1
    3. I2C0
    4. USART0

  5. Dev Board comms with Radio Chip via UART

    1. Monitor PIO1_5 and (anything else we can watch?) to check for change after sending same messages?

  6. Monitor GPIO1_5 when RF dongle is plugged in or not

    1. Scope with official FW?

  7. Consider latest firmware update from Valve (new firmware to enable BLE for new Steam Link app)

    1. Look at what has changed?
    2. Will new tooling help to decompose the new firmware faster?
    3. Is this a distraction not worth digging into right now?
      1. Majority of functional behavior from vcf_wired_controller_d0g_57bf5c10.bin should remain unchanged (even if underlying assembly changes).
      2. Once functionality is fully understood, applying that understanding to newer firmware may be quicker than "starting over" with new firmware?

  8. Understand USART/Radio communications protocol?

    1. Try to reverse engineer protocol to leverage comms with dongle??

  9. List more details about hardware Luna_maiboard_V000456-00_rev3.md

    1. Add links to datasheets
    2. Other processors (i.e. wireless comms chip, gyro, haptics chip)
    3. See if we can get information on each pin (focus on LPC chip)
    4. What is ADC connected to (specifically Channel 6)
      1. This may help with understanding some of these GPIOs...
    5. Find out more on these GPIOs (i.e. Ohm it out, test using custom firmware)
      1. PIO1_10
      2. PIO1_7
      3. PIO0_19
      4. PIO0_2
      5. PIO1_28
      6. PIO0_7
      7. PIO0_22 (AD6) What does this read...?
      8. PIO1_28 and PIO1_4 (USART/Radio chip related?)
      9. PIO1_5 (USART/Radio chip related. PINT2).
        1. What is state of this? Changes if we send messages via UART?
        2. What does trace lead to (ohm it out...)
    6. Add Chart/Table to label how hardware peripherals are used?
      1. CT16B1 = driving Steam Controller LED
      2. CT16B0 = used as timer for a delay during init. (That it?)
      3. SSP0 = CS ?? = Left Haptics, CS ?? = Right Haptics

  10. Decompose EEPROM dumps

    1. Captured from two different controllers to isolate some differences
    2. Change settings to isolate other differences

  11. Can we (continue to) make pinkySim logging better

    1. More automation or second steps for cleaning .c log file?

  12. Look into wireless chip

    1. Is same one on dongle?
      1. If so can I use dongle as dev board?
        1. If not should I order a dev board (https://www.nordicsemi.com/eng/Products/nRF51-Dongle)