BYK801 Findings

[swiftgeek]

Describes build I'm using in particular. Different build/fw revision may manifest different behavior

Compiler

Most likely Keil uVision2, since at the time of this board being shipped sinowealth didn't provide packages for newer uVision. JET51A_Keil_V1.8.10.3.zip is the last available sinowealth package for UV2.

Bootloader (ISP FW)

• Extends beyond 1KiB ISP area (0x7C00-0x7FFF) defined by MCU, to cover last 4KiB of flash (0x7000-0x7FFF). BYK916 similarly has 4KiB bootloader at end of flash.
• Reset vector (3 bytes at 0x00) seems to immediately jump to ISP FW (0x7000), so with default firmware looking for ISP pin straps (MCU defined, OP_ISPPIN/OP_ISP) is pointless. Furthermore, ISP pinstrap entrypoint defined by MCU (OP_ISPPIN, 0x7C00) doesn't even appear to be functional in BYK801, as it lands us in the middle of random USB routine!
  • Actually after running host bootloader software once, bootloader seems to have copied contents of 0x6FFB-0x6FFD into 0x0000-0x0002, then filled 0x6FFB-0x6FFD with 0x00. This changed reset vector from 02 70 00 to 02 3b cc
• There appears to be no HID sequence to jump back to ISP FW, as LJMP to 0x7F00 is nowhere to be found.
  • IRQs in pspec fixed this, jump to ISP FW appears in main FW. 0x7F00 entrypoint appears to be functional. 0x7F00 offset is firmware defined (BYK916 has similar entrypoint at 0xFF00)
  • After testing with host bootloader software, it's clear that HID sequence works and USB VID:PID in bootloader is 0603:1020
• ISP FW seems to be waiting for particular state on P0.2 and P0.3 pins, which is likely to correspond to USB D+ and D- pins. Likely follows "USB ISP Boot Circuit" from SH61F83.
• When special P0.2 P0.3 condition is not detected, ISP FW will jump to 0x3BCC entrypoint (defined by ISP FW) in main FW. But when the condition is met, it will first erase 1KiB sector starting from 0x3B00, which would include main FW entrypoint.

Interrupts

• Keil seems to optimize code size so hard, that it places unrelated functions in place of disabled interrupt handlers
• Following interrupts are clearly used due to RETI use:
  • IRQ0
  • IRQ3
  • IRQ5 - TIMER2 perhaps?
  • IRQ8
  • IRQ9
  • IRQ10
  • IRQ11 - USB/EUSB