[BK7231T] A simple BLE device project using WB2L. Comments and help welcome.

Very impressive documentation. Comprehensive and well written. I will have to find some time to analyze it.

Are you planning to support N platform as well (BK7231N)?

We are. I think we have `N' powered devices lying around as well so as soon as we hook it up we should be able to get something similar. In the meanwhile we are planning to use Beken's BLE profile api to get a full `transparent UART' and reverse engineer the lower level calls (setting registers, basically). We try to write about details, we found that it helps beginners ask the right questions.

Andy

jitsirakowsk wrote:

We are. I think we have `N' powered devices lying around as well so as soon as we hook it up we should be able to get something similar. In the meanwhile we are planning to use Beken's BLE profile api to get a full `transparent UART' and reverse engineer the lower level calls (setting registers, basically). We try to write about details, we found that it helps beginners ask the right questions.

Andy

Hi Andy,

That writeup looks very, very nice and thank you for sharing it with us!

Disclaimer - haven't read the paper yet so ignore the question if irrelevant.
Have you considered using OpenOCD to confirm the possible register changes??

There was a JTAG config by @xabean somewhere.

xabean wrote:

I got JTAG working, it's the same pins used for SPI programming, so I didn't need to rewire anything. Drop the below config into bk7321t.cfg, and run openocd -f bk7321t.cfg to start it up.

Code: text Expand Select all Copy to clipboard

source [find interface/raspberrypi2-native.cfg]

## https://docs.microsoft.com/en-us/windows/iot-core/learn-about-hardware/pinmappings/pinmappingsrpi
##
## CEN  -> (bcm)GPIO 22 / RPI3b pin 15
## SCLK -> (bcm)GPIO 11 / RPI3b pin 23
## CSN  -> (bcm)GPIO 08 / RPI3b pin 24
## SI   -> (bcm)GPIO 10 / RPI3b pin 19
## SO   -> (bcm)GPIO 9 / RPI3b pin 21


# Each of the JTAG lines need a (bcm) gpio number set:
#                     tck tms tdi tdo
bcm2835gpio_jtag_nums 11  8   10  9

#                     srst
bcm2835gpio_srst_num  22

# we only have CEN (aka chip enable, system reset)
reset_config srst_only

# CEN is normally pulled high, but sometimes it can help to force it high, not just low.
reset_config srst_push_pull

# on connect, deassert (reset to HIGH) the SRST pin
reset_config connect_deassert_srst

# we have no TRST pin, tell OpenOCD to imagine it's tied to SRST.
reset_config srst_pulls_trst

# use JTAG.
transport select jtag

# go slow.
adapter speed 100

# wait 200ms after releasing srst before we send JTAG commands over TMS,
# we will never reset into halt because we have no tRST pin :(
adapter srst delay 200

if { [info exists CHIPNAME] } {
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME bk7321t
}

if { [info exists ENDIAN] } {
   set _ENDIAN $ENDIAN
} else {
  # this defaults to a little endian
   set _ENDIAN little
}

if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   set _CPUTAPID 0x15968001
}

jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm966e -endian $_ENDIAN -chain-position $_TARGETNAME

Then you can read the flash chip ID over the OpenOCD telnet interface on port 4444,

Code: text Expand Select all Copy to clipboard

xabean@raspberrypi:~ $ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> mww 0x00803000 74
> mdw 0x00803010 1
0x00803010: 001c7015

> bk7321t.cpu arm reg                
System and User mode registers
      r0: 00000001       r1: 00000069       r2: 00090080       r3: 00100000 
      r4: 00408b5e       r5: 00000001       r6: 00405d80       r7: 00000010 
      r8: 08080808       r9: 09090909      r10: 10101010      r11: 11111111 
     r12: 0000000a   sp_usr: 00420870   lr_usr: 00016dfd       pc: 00016dc2 
    cpsr: 6000003f 

FIQ mode shadow registers
  r8_fiq: 00000000   r9_fiq: 00000000  r10_fiq: 00000000  r11_fiq: 00000000 
 r12_fiq: 00000000   sp_fiq: 00400fe0   lr_fiq: b51edf9b spsr_fiq: 00000010 

Supervisor mode shadow registers
  sp_svc: 004027a0   lr_svc: 00016dc6 spsr_svc: 6000003f 

Abort mode shadow registers
  sp_abt: 004007e0   lr_abt: df9ff7e5 spsr_abt: 00000010 

IRQ mode shadow registers
  sp_irq: 00401fd0   lr_irq: 00059ae8 spsr_irq: 6000001f 

Undefined instruction mode shadow registers
  sp_und: 004007e0   lr_und: bb0de3bc spsr_und: 00000010 

>>20654137
Hi! Thanks for the question and the info about JTAG. No, we have not done anything with it but OpenOCD with jtag would be fantastic. If I understand correctly this requires access to SPI pins and a few others. Not a major problem in itself, of course. I noticed in the original Makefile by Tuya that they have a setup using OpenOCD (and jlink) with the serial bootloader on the chip. This would speed things up tremendously as one would be able to use gdb and there would be no need for the second serial port to print to. By the way, has there been any effort to replace the bootloader with something better known?

Andy

Here is a guide for SPI flashing of BK7231. It can be used to reconstruct bootloader if it was overwritten:
https://www.elektroda.com/rtvforum/topic3931424.html
I will, however, note here that WB2L may not have easily accessible SPI pins. I remember there was a problem with that. I used SPI method succesfully for WB3S. You need to consult the module datasheet to be sure.

Yes, we have seen the guide (excellent work by the way) and judging by the datasheet for WB2L pins 20-23, as well as reset are exposed as test pins on the back of the pcb. The datasheet also explicitly says that these pins can be used to read and write flash, so it should be doable. In our case, there is a complication of having to desolder the module itself which is also glued to the mother-pcb it seems. It should be possible but naturally we are putting it off until we are done experimenting with the code (or have to rebuild the bootloader). It is getting more and more tempting though.

Hi everyone!

Here is a new version of the tutorial and the project. Not much new code, although we have reverse engineered three somewhat large functions in the link layer driver. There is a detailed guide on how it was done in case anyone wants to continue the work (we are planning to continue, as well, probably concentrating more on reverse engineering itself, and less on the description of the process). There are guides (albeit of varying quality) on several topics, from assembly to computer arithmetic (whatever the members of our little group asked about), a small glossary, a literature guide. There are even exercises, in case someone wants to practice!

We have also looked at the BLE subsystem on the `N' chip. It turned out that the register map is different and the registers themselves are also not the same (although similar; it seems the `N' chips use a newer BLE cell). The functions have different prototypes, as well, although the overall organization of the code is not that different. We have not started reverse engineering the corresponding BLE library yet but it is `on the agenda'. As always, comments, requests, and questions are welcome.

Andy

>>20742145 Hi Everyone! Just wanted to share updates for this project. It was used to teach a reverse engineering lab at a local college, some student projects have been incorporated. The manual is included, as before. While there are no additions to the BLE part of the project there is something that may be of general interest. We have written a disassembler (from scratch, in perl, don't ask...) and disassembled the libble.a and rwnx.a libraries for both the N and T chips. The disassembly is pretty structured and modifiable which makes it very suitable for experimentation (there are no hard coded offsets left as is common in any assembly code). BLE register names have been put into the code, as well. Each disassembled function comes with a comment section that shows its C prototype, names and types of local libraries, etc. The variables used by each library object are separated in a C file where their declarations are listed. We wrote a script to check that the recompiled binaries are for all purposes identical to the original ones (.text sections are the same, .(ro)data sections are the same and the relocations are the same). The ble project works with the newly rebuilt library as well. We will be teaching the lab again this semester and next (it's a year long course) so we hope to add more to the Bluetooth part of the project. The disassembler is included and contains both elf and dwarf parsers (although for DWARF v4 and earlier only) which can also be useful.

Interesting, keep us posted. What would be the practical applications of that? We didn't really touch internal drivers in OBK yet.

>>21848057 Our original goal was to reverse engineer the libraries and we noticed that the disassembly was a bit laborious so we wanted something intermediate between a full C source and the machine code. This does it. It is easy to insert printf statements, function calls, save registers, etc, if one knows a little bit of assembly (and the manual teaches enough of it for this purpose). While we have not done it yet, all of the KE kernel functions are relatively easy to reverse engineer. One issue we considered is porting the libraries to a newer version of gcc, and a recent FreeRTOS.

On the practical side, we would like to enable the wireless arbiter to be able to use BLE and WiFi on the same antenna, at the same time. This way you would be able to, say change the lighting according to the nearest BLE device, etc.

Andy