Hi. I've experimented with too many environments and too many flashers and think I now have a corrupted BL706 eval board. I'm on MacOS. It seems strange there are interface options for Segger and serial and not the provided board built using Bouffalo's own chips! I would LIKE to load code and debug over the provided BL702 debugger, as I'll need JTAG debugging, but if code download over serial is fast and reliable enough, I'm OK with that. (I'm also typing a lot in the hopes of getting this RV706 RISC-V Development Board with Bluetooth, LCD Display, and JTAG some Google rank.)
I'll soon need to work with the IoT version instead of the MCU version, but I'm taking your example LVG code now.. I have relied heavily on https://lupyuen.github.io/articles/bl706, but I know the MacOS bldevcube has had problems in the past, so I've tried to work around it, too. I understand that many names and directories have changed, and I've tried to adapt.
The code is built with
make APP=lvgl \
BOARD=bl706_avb \
SUPPORT_LVGL=y
This gives me a an elf and bin for running, and an asm and map for correlation. First, we'll try speaking directly to OpenOCD at a very low level.
I am able to reliably start an OpenOCD session via
➜ bl_iot_sdk git:(master) ✗ riscv-openocd -d2 -f flash_tool/utils/openocd/if_rv_dbg_plus.cfg -f flash_tool/utils/openocd/tgt_702.cfg
I'm able to successfully communicate to port 4444 via NC and 3333 via GDB.
Info : clock speed 4000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x20000e05 (mfg: 0x702 (<unknown>), part: 0x0000, ver: 0x2)
Info : datacount=1 progbufsize=2
Info : Disabling abstract command reads from CSRs.
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=32, misa=0x40801125
Info : starting gdb server for riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : JTAG tap: riscv.cpu tap/device found: 0x20000e05 (mfg: 0x702 (<unknown>), part: 0x0000, ver: 0x2)
reset-assert-pre
reset-deassert-post
Info : Disabling abstract command writes to CSRs.
reset-init
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
I may very well be getting tripped up on a single memory address having three addresses (base physical from JTAG side, 0x23000000 if it's code and 0x42000000 if it's instruction) but I decided to choose 0x2000 as that was used both in LupYeun's series and in a series of late night tweets. So this proceeds without error:
nc localhost 4444 < cmds
��������Open On-Chip Debugger
> halt
> load_image lvgl_main.bin 0x2000
> reg pc 0x22020000
pc (/32): 0x23020000
> resume
> # WaitCmd replaced with sleep 500 to wait a half seconds
> sleep 500
> mwb 0x4202c000 0x0
> mwb 0x4202bff0 0x48
> mwb 0x4202bff1 0x52
> mwb 0x4202bff2 0x44
> mwb 0x4202bff3 0x59
> mdb 0x4202bff0 0x4
0x4202bff0: 48 52 44 59
> # WaitCmd
> sleep 500
> mdw 0x4202bff4 0x3
0x4202bff4: 3bd27076 ab9432d4 7edb2457
> sleep 500
I think that burst of noise at the beginning is just bit rates syncing up and junk being flushed on the connection. It's consistent. It's a lot slower than I'd think a JTAG transfer should be at 35 seconds, but that's not a deal-breaker. The deal breaker is that the code didn't get loaded. Looking at the first several opcodes of the *.bin, it's the traditional RISC-V "make the stack and GP sane, relocate myself, call main; panic" loop but I can't tell that we've relocated and I don't see that the load actually changed memory. I think it has to do with cache synchronization between I & D caches and the JTAGer having a dirty image.
Displaying ...0x0000 (the relocated address) or 0x2000 (the offset of the load) for any of the segments at 0x2100.0000, 0x22, or 0x23 bears no fruit.
> mdb 0x21000000 0x20
mdb 0x21000000 0x20
0x21000000: 97 81 02 21 93 81 01 48 73 70 04 30 97 82 00 00 93 82 42 c3 93 e2 32 00 73 90 52 30 93 02 00 00
> mdb 0x21002000 0x20
mdb 0x21002000 0x20
0x21002000: b2 97 c2 06 37 a9 02 42 b6 97 62 07 ba 97 2e 84 13 05 49 f8 81 45 3e c8 ef c0 90 0f 0a 87 93 06
> mdb 0x22000000 0x20
mdb 0x22000000 0x20
0x22000000: ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de
> mdb 0x22002000 0x20
mdb 0x22002000 0x20
0x22002000: ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de ef be ad de
> mdb 0x23000000 0x20
mdb 0x23000000 0x20
0x23000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mdb 0x23002000 0x20
mdb 0x23002000 0x20
0x23002000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Now for convenience, I have an overkill .gdbinit that connects to the server, grabs the version with a symbol table, and defines some (OK, almost everything) memory ranges.
cat .gdbinit
target extended-remote localhost:3333
file /Users/robertl/src/bl_mcu_sdk_/out/examples/lvgl/lvgl_main.elf
mem 0x22000000 0x22008000 rw
mem 0x22008000 0x22014000 rw
mem 0x42008000 0x42014000 rw
mem 0x22014000 0x22020000 rw
mem 0x42014000 0x42020000 rw
mem 0x22020000 0x22030000 rw
mem 0x42020000 0x42030000 rw
mem 0x22030000 0x2204C000 rw
mem 0x42030000 0x4204C000 rw
mem 0x23000000 0x23400000 ro
GDB successfully connects and returns sane-looking results for a SiFive 32-bitter:
0x21007c70 in ?? ()
(gdb) info registers
ra 0x21007d40 0x21007d40
sp 0x42026d00 0x42026d00
gp 0x42028480 0x42028480
tp 0x2567c03b 0x2567c03b
t0 0xb 11
[ ... ]
pc 0x21007c70 0x21007c70
It's troublesome that $pc if off in space, but I can hand assemble code, run it, and see it taking effect on registers, so I'm pretty sure the basic JTAG setup is OK. I just can't tame the load operation.
What is the most scriptable (not a GUI) way to reliable transfer and execute over USB with the provided Sipeed/Bouffalo JTAG adapter?
That's a mouthful. Let's look at the serial side.
There are several programs around that try to implement the BL602/4 upload process, but I can't find any that implement the BL70x protocol, so I'll limit myself to BLDevFlasherCube 1.6.8 for MacOS.
We set the interface to UART since this is not a Segger. We don't expect the serial ports exposed by the Sipeed JTAG probe (/dev/tty.usbserial1200 and /dev/tty.usbserial1201) to work. Actually, for debugging reproduciliity, let's physically remove those and go with /dev/tty.usbmodem0000000200001 which only appears after the board has had a Boot + Reset Salute. Fortunately, we can see the debugging fine. I think, however, that I've corrupted my setup enough in all my experimentation that I can't work my way back out.
BUG: We can select the chip type, but it doesn't 'stick'; the next time you view that setting, it's reverted back to BL602.
Under View, there are completely separate images depending on whether you comoplied with two different SDKs. That doesn't make much sense. That should be hidden to the developer. Maybe there's an ELF note or a symbol that stores this informatino or something...
In the leftmost column, we select Interface = UART (explained earlier, COM port = /dev/tty.usbmodembignumber), UART rate of 230400 as a conservative start, an Xtal of 32M (it's soldered to the board. Do I need to know this?) and Chip Erase = False. Refresh seems a bit silly since the app should register an observer on device notification and offer to change the type. This is just one more thing for users to mess up.
I originally started with the IOT settings and found it frustrating there was no "reset to defaults" and it was possible to mix up bins and cfgs of different types, I eventually settled on:
/Applications/BLDevCube.app/Contents/MacOS/chips/bl702/conf/mcu.toml
/Applications/BLDevCube.app/Contents/MacOS/chips/bl702/builtin_imgs/boot2_iap_v5.3/boot2_iap_debug.bin
/Users/robertl/src/bl_mcu_sdk/out/examples/lvgl/lvgl_bl702.bin
and /Applications/BLDevCube.app/Contents/MacOS/chips/bl702/builtin_imgs/mfg/bl702_mfg_stdfw.bin
These were mostly guesses.
BUG: The button ordering and labeling is strange. 'Log' and ''OpenUart' seem related. The UART is always opened. The last button is just whether it's channeled to log, right? So can they be the same button?
"Create Download" implied that's the action that adds the ELF loader to user's executable. On screenshots, it's "Create & Download" sometimes. If the creation thing is something you're trying to hid, don't show it here at all. Also, move it out from between the two related buttons. Dismissive obtions (like cancel) go to the left and action buttons (like "upload") go to the far right.
This screen used to actually put the device into download mode and spin. Now, it just crashes before trying, even if I deselect all the partitions to upload:
[04:56:29.556] - ========= Interface is Uart =========
[04:56:29.557] - eflash loader bin is eflash_loader_32m.bin
[04:56:29.558] - ========= chip flash id: c84015 =========
[04:56:29.560] - create partition.bin, pt_new is True
Traceback (most recent call last):
File “core/bflb_iot_tool.py”, line 1213, in flasher_download_thread
File “core/bflb_iot_tool.py”, line 954, in flasher_download_cfg_ini_gen
File “libs/bflb_pt_creater.py”, line 90, in create_pt_table
KeyError: ‘pt_entry’
Whether or not partition table is selected, that's the crash.
Let's try the MCU view.
All the settings are the same, with the same rationale. Image Addr ix 0x2000 and BootInfo Addr is 0. With "Flash" set as the boot source:
[05:00:48.801] - Version: bflb_eflash_loader_v2.3.0
[05:00:48.801] - Program Start
[05:00:48.801] - ========= eflash loader cmd arguments =========
[05:00:48.801] - None
[05:00:48.801] - Config file: /Applications/BLDevCube.app/Contents/MacOS/chips/bl702/eflash_loader/eflash_loader_cfg.ini
[05:00:48.802] - serial port is /dev/tty.usbmodem0000000200001
[05:00:48.802] - cpu_reset=False
[05:00:48.803] - chiptype: bl702
[05:00:48.803] - ========= Interface is uart =========
[05:00:48.803] - com speed: 230400
[05:00:48.803] - Eflash load helper file: /Applications/BLDevCube.app/Contents/MacOS/chips/bl702/eflash_loader/eflash_loader_32m.bin
[05:00:48.803] - Eflash load helper file: /Applications/BLDevCube.app/Contents/MacOS/chips/bl702/eflash_loader/eflash_loader_32m.bin
[05:00:48.803] - ========= load eflash_loader.bin =========
[05:00:48.803] - Load eflash_loader.bin via uart
[05:00:48.804] - ========= image load =========
[05:00:49.069] - tx rx and power off, press the machine!
[05:00:49.070] - cutoff time is 0.05
[05:00:49.126] - power on tx and rx
[05:00:50.073] - reset cnt: 0, reset hold: 0.05, shake hand delay: 0.1
[05:00:50.074] - clean buf
[05:00:50.077] - send sync
[05:00:50.285] - ack is b’4f4b464c0201’
[05:00:50.322] - shake hand success
[05:00:50.335] - get_boot_info
[05:00:50.347] - data read is b’0100020700000000931d00002b0000800000c1b376949424’
[05:00:50.347] - ========= ChipID: 0000c1b376949424 =========
[05:00:50.347] - last boot info: None
[05:00:50.347] - sign is 0 encrypt is 0
[05:00:50.348] - segcnt is 1
[05:00:50.374] - segdata_len is 58928
[05:00:50.410] - 4080/58928
[05:00:50.448] - 8160/58928
[05:00:50.484] - 12240/58928
[05:00:50.522] - 16320/58928
[05:00:50.558] - 20400/58928
[05:00:50.592] - 24480/58928
[05:00:50.630] - 28560/58928
[05:00:50.668] - 32640/58928
[05:00:50.705] - 36720/58928
[05:00:50.744] - 40800/58928
[05:00:50.778] - 44880/58928
[05:00:50.817] - 48960/58928
[05:00:50.858] - 53040/58928
[05:00:50.895] - 57120/58928
[05:00:50.920] - 58928/58928
[05:00:50.932] - Run img
[05:00:51.049] - Load helper bin time cost(ms): 2245.376708984375
[05:00:51.155] - Flash load shake hand
[05:00:51.163] - default set DTR high
[05:00:51.269] - clean buf
[05:00:51.270] - send sync
[05:00:51.477] - ack is b’4f4b’
[05:00:51.513] - Read mac addr
[05:00:51.514] - flash set para
[05:00:51.514] - ========= flash read jedec ID =========
[05:00:51.515] - Read flash jedec ID
[05:00:51.515] - readdata:
[05:00:51.515] - b’ef401780’
[05:00:51.515] - Finished
[05:00:51.516] - {“ErrorCode”: “003D”,”ErrorMsg”:”BFLB FLASH MATCH TYPE FAIL”}
[05:00:51.516] - Burn Retry
[05:00:51.516] - 0
[05:00:51.516] - Burn return with retry fail
This seems like it should have been detected before actually writing to the flash. (This makes me wonder if this is what's corrupted my board....)
Incidientally, the height of the progress bar varies from about 2/3 of the button height to about 3x the button height when 'show advanced options' is enabled.
So instead of choosing Flash, let's try the "run from RAM" case:
I don't know why the action button changed from Create Download to Create Program.
I originally had a problem that the Bind, Save Image, Browse buttons on the right weren't displayed. There are vertical overflow scrollbars enabled, but none for the horizontal axis. On a big screen, that's no big deal but in the mobile era, we can't assume that apps have infinite real estate now. Widening the window works around this.
[05:17:20.898] - {‘xtal_type’: ‘XTAL_32M’, ‘pll_clk’: ‘144M’, ‘encrypt_type’: ‘None’, ‘key_sel’: ‘0’, ‘cache_way_disable’: ‘None’, ‘sign_type’: ‘None’, ‘crc_ignore’: ‘False’, ‘hash_ignore’: ‘False’, ‘encrypt_key’: ‘’, ‘aes_iv’: ‘’, ‘public_key_cfg’: ‘’, ‘private_key_cfg’: ‘’, ‘device_tree’: ‘’, ‘page_type’: ‘mcu’, ‘flash_clk_type’: ‘XCLK’, ‘boot_src’: ‘UART/USB’, ‘img_type’: ‘SingleCPU’, ‘img_addr’: ‘0x2000’, ‘bootinfo_addr’: ‘0x0’, ‘img_file’: ‘/Users/robertl/src/bl_mcu_sdk/out/examples/lvgl/lvgl_bl702.bin’, ‘dl_device’: ‘Uart’, ‘dl_comport’: ‘/dev/tty.usbmodem0000000200001’, ‘dl_comspeed’: ‘230400’, ‘dl_jlinkspeed’: ‘1000’, ‘dl_chiperase’: ‘False’, ‘dl_xtal’: ‘32M’}
[05:17:20.906] - EFUSE_CFG
[05:17:20.907] - BOOTHEADER_CFG
[05:17:20.912] - Create bootheader using /Applications/BLDevCube.app/Contents/MacOS/chips/bl702/img_create_mcu/efuse_bootheader_cfg.ini
[05:17:20.912] - Updating data according to </Applications/BLDevCube.app/Contents/MacOS/chips/bl702/img_create_mcu/efuse_bootheader_cfg.ini[BOOTHEADER_CFG]>
[05:17:20.914] - Created file len:176
[05:17:20.917] - Image create path: /Applications/BLDevCube.app/Contents/MacOS/chips/bl702/img_create_mcu
[05:17:20.917] - Config file: /Applications/BLDevCube.app/Contents/MacOS/chips/bl702/img_create_mcu/img_create_cfg.ini
[05:17:20.919] - Image hash is b’26905fb1bf7d36ea300b314728d2858ccc5ff0ed5b07e0c96fba6c27efebd04f’
[05:17:20.919] - Header crc: b’e1233822’
[05:17:20.919] - Write if img
[05:17:20.920] - image create success
[05:17:20.921] - ========= eflash loader config =========
[05:17:20.922] - ========= image load =========
[05:17:21.189] - tx rx and power off, press the machine!
[05:17:21.190] - cutoff time is 0.05
[05:17:21.245] - power on tx and rx
[05:17:22.194] - reset cnt: 0, reset hold: 0.05, shake hand delay: 0.1
[05:17:22.195] - clean buf
[05:17:22.198] - send sync
[05:17:22.408] - ack is b’4f4b464c0201’
[05:17:22.445] - shake hand success
[05:17:22.457] - get_boot_info
[05:17:22.469] - data read is b’0100020700000000931d00002b0000800000c1b376949424’
[05:17:22.469] - ========= ChipID: 0000c1b376949424 =========
[05:17:22.469] - last boot info: None
[05:17:22.469] - sign is 0 encrypt is 0
[05:17:22.469] - [Errno 2] No such file or directory: ‘chips/bl702/img_create_mcu/img_if.bin’
Traceback (most recent call last):
File “libs/bflb_img_loader.py”, line 655, in img_load_process
File “libs/bflb_img_loader.py”, line 485, in img_load_main_process
FileNotFoundError: [Errno 2] No such file or directory: ‘chips/bl702/img_create_mcu/img_if.bin’
I can see there's an img_if.bin in the app itself:
/Applications/BLDevCube.app/Contents/MacOS/chips/bl702/img_create_mcu/img_if.bin
but I don't know that anything I've done prevents the app from finding its own internal resources.
I found the ISP Protocol document at ['https://github.com/bouffalolab/bl_docs/blob/main/BL602_ISP/en/BL 602_ISP_protocol.pdf'](''https://github.com/bouffalolab/bl_docs/blob/main/BL602_ISP/en/BL 602_ISP_protocol.pdf') helpful, but there are still gaps between what's appropriate between 60x vs. 70x, between the different chain types, the relative youth of the respective programs, and the reality of just pushing a single ".exe" to the board vs. having to push multiple downloads - and how you choose which ones - and vs building an entire filesystem image with embedded filesystems (app resources, wifi configs, device trees, etc.) and such within this space.
So that's the status of my journey so far. Whether via JTAG or via serial and whether communicating directly with OpenOCD or using BLDevCube, I'm failing. Can someone experienced with this board and on MacOS help find a way to run code wither from RAM (for development) or flash (for a product) and push it with no human intervention on the host?
Thank you for any help you can offer. Even if you can offer a factory image so that I can restore the board back to a useful state, that would help get me unstuck.
