search

bouffalolab / bouffalo_sdk

BouffaloSDK is the IOT and MCU software development kit provided by the Bouffalo Lab Team, supports all the series of Bouffalo chips. Also it is the combination of bl_mcu_sdk and bl_iot_sdk
Apache License 2.0
349 stars 121 forks source link

BL808 JTAG documentation #32

Closed btashton closed 1 year ago

btashton commented 1 year ago

There does not seem to be much in the way of documentation for using JTAG with the BL808 chip. I have been trying to use a RV Debugger Plus with a Ox64 board but am not able to examine any of the cores.

gamelaster commented 1 year ago

Hi @btashton is very likely you received prototype ox64 board, so the pinout of JTAG is not correct.

The correct pins for JTAG are 6,7,12,13.

12, 13 should be on JTAG header, 6, 7 on GPIO headers.

robertlipe commented 1 year ago

Thanx, Gaimee. Is this a "global" JTAG poirt that's shared between the three cores (TDO->TDI chained internally with software selecting them and handling the different personalities) or is there a physical JTAG connection per core as on some devices?

Are all board now in developer hands mismarked like this or is there a way we can tell if we have an affected board? Do we have working openocd or segger configs yet? (I really don't want to have to mess with ckllink on these and wch's different/proprietary jtag on those and real jtag on everything else)

These pin muxes can be awesome but man can they make this kind of stuff gnarly.

btashton commented 1 year ago

There are three different JTAG chains (the LP is a two wire debug). You can actually see the mappings in the datasheet ( it is not reference manual).

btashton commented 1 year ago

I am going to close this now that documentation for the CKLink has been provided. You can find my notes here: https://gist.github.com/btashton/6af120ff16d6beeccbbde74e6733535c

robertlipe commented 1 year ago

Very nice!

Is there a known open-source equivalent of this debug server (which I'm guessing is a openocd-like substance) for those on non-Intel OSes?

If this really is normal JTAG, why doesn't it work with the standard BL702 debugger code?

I just really am clammy to installing root binary-onlyt processes from alien sources like this...

On Tue, Nov 1, 2022 at 11:02 PM Brennan Ashton @.***> wrote:

I am going to close this now that documentation for the CKLink has been provided. You can find my notes here: https://gist.github.com/btashton/6af120ff16d6beeccbbde74e6733535c

— Reply to this email directly, view it on GitHub https://github.com/bouffalolab/bl_mcu_sdk/issues/32#issuecomment-1299533702, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD32EDELL2EHDIWGXLO3WGHRTPANCNFSM6AAAAAARSRB6QY . You are receiving this because you commented.Message ID: @.***>

davidcorrigan714 commented 1 year ago

Either this needs to be re-opened or the title changed to reflect something about the specific debugger that eventually was used. We very much still need JTAG documentation and something working with OpenOCD and not some random bespoke debugger for this chip to be really broadly useful.

btashton commented 1 year ago

I would recommend this https://btashton.github.io/bl808-notes/jtag.html And https://btashton.github.io/bl808-notes/devboards/ox64.html

However I stopped using the Ox64 because my early board seemed to have issues with with flash and sipeed got me a functional M1s. I will come back to the Ox64 when a new one arrives.

The CKlink was actually easy to use especially with t-head cores. And being able to flash my RV Debugger Plus made the cost not really an issue. I did get one of the real CKLink debuggers, but have not bothered to us it yet

gamelaster commented 1 year ago

@btashton if you have issues with flashing of Ox64 with 16Mb flash, it is because inproper configuration of SPI Flash in BLDevCube. I can share the configuration if needed (I'm AFK currently)

btashton commented 1 year ago

@btashton if you have issues with flashing of Ox64 with 16Mb flash, it is because inproper configuration of SPI Flash in BLDevCube. I can share the configuration if needed (I'm AFK currently)

Sure. I can give it a try, but seemed like something was not right with the timing parameters for the smaller flash.

gamelaster commented 1 year ago

@btashton Firstly, replace flashcfg_list.csv in utils/flash/bl808 folder. (flashcfg_list.csv) Then, open file chips/bl808/eflash_loader/eflash_loader_cfg.ini, and find flash_id entry. Ensure, that it is configured as following: image After, open Bouffalo Lab Dev Cube, select BL808, and navigate to MCU tab. Set M0 to group0, Image Addr 0x58000000 , and specify path to factory_test_bl808_m0.bin. Then Create & Download.

factory_test_bl808_m0.bin.tar.gz (don't forget to extract it)

After that, it should work fine :)

btashton commented 1 year ago

I will try sometime this week and update my notes. Thanks! I did have strange behavior even after flashing (code jumping to odd addresses) which is what made me suspicious something else was also going on.

gamelaster commented 1 year ago

No problem, let me know if it will work for you :)

gamelaster commented 1 year ago

@btashton sorry, I written you wrong docs, I updated ti with my factory test firmware. It outputs text into UART + toggling all GPIO pins.

davidcorrigan714 commented 1 year ago

The programmer I ordered got in a few days ago and I just got that factory_test bin loaded and working. The GPIOs are toggling and the UART is seeing a stream of Ping! and Pong! .

a-v-s commented 1 year ago

There are three different JTAG chains (the LP is a two wire debug). You can actually see the mappings in the datasheet ( it is not reference manual).

I am having trouble locating the mappings. As in my datasheet, for many pins, I see function 26 for M0 and function 27 for D0. Note my datasheet is version 1.1

NilsBe commented 1 year ago

@btashton Firstly, replace flashcfg_list.csv in utils/flash/bl808 folder. (flashcfg_list.csv) Then, open file chips/bl808/eflash_loader/eflash_loader_cfg.ini, and find flash_id entry. Ensure, that it is configured as following: image After, open Bouffalo Lab Dev Cube, select BL808, and navigate to MCU tab. Set M0 to group0, Image Addr 0x58000000 , and specify path to factory_test_bl808_m0.bin. Then Create & Download.

factory_test_bl808_m0.bin.tar.gz (don't forget to extract it)

After that, it should work fine :)

  • gamiee

Sorry, doesn't work in my case. Also, I would like to ask where I can find the source for factory_test.bl808_m0.bin

DavidVentura commented 1 year ago

I've also applied the recommendations from @gamelaster on the bflb_mcu_tool, replaced the CSV with the linked one and changed the values in FLASH_CFG so that they look like

[FLASH_CFG]
#flash_id = ef4016 # <- was the original value
flash_id = ef6015
#bit 7-4 flash_clock_type: 0:120M wifipll, 1:xtal, 2:128M cpupll, 3:80M wifipll, 4:bclk, 5:96M wifipll
#bit 3-0 flash_clock_div
#flash_clock_cfg = 0x41 # <- was the original value
flash_clock_cfg = 0x43

# everything below here didn't change
#0:0.5T delay, 1:1T delay, 2:1.5T delay, 3:2T delay
flash_clock_delay = 0
#0:NIO, 1:DO, 2:QO, 3:DIO, 4:QIO
flash_io_mode = 1
#flash_pin value:
#bit 7 flash pin set from efuse flash cfg
#bit 6-0 flash pin cfg: 0: internal swap io0 with io3, 2: internal no swap io0 with io3, 4: external gpi34-39,
flash_pin = 0x80
#empty for auto, otherwise specified flash para file path: eg: chips/bl808/efuse_bootheader/flash_para.bin
flash_para = chips/bl808/efuse_bootheader/flash_para.bin
decompress_write = true
file = chips/bl808/img_create_mcu/bootinfo_group0.bin chips/bl808/img_create_mcu/img_group0.bin
address = 0 2000

most importantly: I dumped the flash on a factory Ox64, which was writing:

 |  _ \             / _|/ _|    | |     | |     | |    
 | |_) | ___  _   _| |_| |_ __ _| | ___ | | __ _| |__  
 |  _ < / _ \| | | |  _|  _/ _` | |/ _ \| |/ _` | '_ \ 
 | |_) | (_) | |_| | | | || (_| | | (_) | | (_| | |_) |
 |____/ \___/ \__,_|_| |_| \__,_|_|\___/|_|\__,_|_.__/ 

Build:19:50:39,Nov 20 2022
Copyright (c) 2022 Bouffalolab team
dynamic memory init success,heap size = 93 Kbyte 
sig1:ffff32ff

then wrote it back with bflb-mcu-tool --chipname=bl808 --port=/dev/ttyACM0 --baudrate=2000000 --firmware flash-good.bin (both with the changes listed here and without)

afterwards, there's no more messages to UART. At least this rules out bad compiler setup. Logs from flashing attached

log.txt

gamelaster commented 1 year ago

@DavidVentura sadly, I figured out that it is some issue with XIP or cache. Firmware runs, but crashes very early, so older firmwares worked OK (most of times).

https://github.com/bouffalolab/bl_mcu_sdk/issues/92

DavidVentura commented 1 year ago

That's what I don't get -- I've dumped the old, good firmware that came with the board and reflashed it (both to the same and to different boards) and now it doesn't work anymore, so why would re-applying it make it break?

gamelaster commented 1 year ago

@DavidVentura how you dumped it? It is possible that you dumped the firmware also with boot header, but bflb-mcu-tool (at least, the older one), don't check for boot header, so it will have two boot headers.

NilsBe commented 1 year ago

I've also applied the recommendations from @gamelaster on the bflb_mcu_tool, replaced the CSV with the linked one and changed the values in FLASH_CFG so that they look like

[FLASH_CFG]
#flash_id = ef4016 # <- was the original value
flash_id = ef6015
#bit 7-4 flash_clock_type: 0:120M wifipll, 1:xtal, 2:128M cpupll, 3:80M wifipll, 4:bclk, 5:96M wifipll
#bit 3-0 flash_clock_div
#flash_clock_cfg = 0x41 # <- was the original value
flash_clock_cfg = 0x43

# everything below here didn't change
#0:0.5T delay, 1:1T delay, 2:1.5T delay, 3:2T delay
flash_clock_delay = 0
#0:NIO, 1:DO, 2:QO, 3:DIO, 4:QIO
flash_io_mode = 1
#flash_pin value:
#bit 7 flash pin set from efuse flash cfg
#bit 6-0 flash pin cfg: 0: internal swap io0 with io3, 2: internal no swap io0 with io3, 4: external gpi34-39,
flash_pin = 0x80
#empty for auto, otherwise specified flash para file path: eg: chips/bl808/efuse_bootheader/flash_para.bin
flash_para = chips/bl808/efuse_bootheader/flash_para.bin
decompress_write = true
file = chips/bl808/img_create_mcu/bootinfo_group0.bin chips/bl808/img_create_mcu/img_group0.bin
address = 0 2000

most importantly: I dumped the flash on a factory Ox64, which was writing:

 |  _ \             / _|/ _|    | |     | |     | |    
 | |_) | ___  _   _| |_| |_ __ _| | ___ | | __ _| |__  
 |  _ < / _ \| | | |  _|  _/ _` | |/ _ \| |/ _` | '_ \ 
 | |_) | (_) | |_| | | | || (_| | | (_) | | (_| | |_) |
 |____/ \___/ \__,_|_| |_| \__,_|_|\___/|_|\__,_|_.__/ 

Build:19:50:39,Nov 20 2022
Copyright (c) 2022 Bouffalolab team
dynamic memory init success,heap size = 93 Kbyte 
sig1:ffff32ff

then wrote it back with bflb-mcu-tool --chipname=bl808 --port=/dev/ttyACM0 --baudrate=2000000 --firmware flash-good.bin (both with the changes listed here and without)

afterwards, there's no more messages to UART. At least this rules out bad compiler setup. Logs from flashing attached

log.txt

That's exactly what I did. And in my case it worked. Of course I started the dump from 0x2000. Did you do that as well?

DavidVentura commented 1 year ago

I'd originally dumped it starting at 0x0, but have just now dumped it starting at 0x2000 and see no difference after flashing with bflb-mcu-tool

All steps that I took:

I've uploaded the content of both flash dumps from a good chip (start at 0x0 and 0x2000)

Can you try to flash them and see if you get the ping-pong firmware back? If not, can you provide me with a flash & command to verify it on my chips?

DavidVentura commented 1 year ago

@NilsBe did you have a chance to try this out?