search

ARMmbed / DAPLink

https://daplink.io
Apache License 2.0
2.23k stars 954 forks source link

Prebuilt binaries for common "STLink v2.1" workalike STM32F103CBT6 based debuggers. #662

Open linuxtim opened 4 years ago

linuxtim commented 4 years ago

Binaries are available at https://armmbed.github.io/DAPLink/ for many boards, but I think it would be very useful to increase the reach of DAPLink by making binaries available for commonly available STM32F103CBT6 based debuggers (e.g. the ones included in ST Nucleo64s, and many other third party work-alike "STLink V2.1" compatible boards - which use the same basic debugger schematic).

A quick look seems to suggest all the code is there already for this, but the vast majority of potential users lack the Keil license which is currently required to build it. Some binaries have been made available online by third parties but these are typically for old releases of DAPLink and/or are poorly documented.

0xc0170 commented 4 years ago

Is this project the one you are interested in: stm32f103xb_if ? I'll find out why it has not been included in the releases.

linuxtim commented 4 years ago

Without closely looking at the code, I think that's correct. These would basically be any board which implements the ST Link v2.x type interface with an stm32f103xBxx (including the ARM reference design - https://github.com/ARMmbed/mbed-HDK-Eagle-Projects/tree/master/DAPLink/Interface%20Schematics/STM32F103CBT6/v1.0.0 ). I believe all of the popular ST Nucleo 64 implement this design. They can be jumpered to target external boards as well as the onboard target - in this way they can be used as a standalone debugger.

My first look at the architecture of DAPLink suggests that it might require multiple binaries, so that the programmer could target multiple boards (e.g. I would like to use the onboard STM32F103CB programmer on a Nucleo-64 to target a Nordic nrf52832 board) as well as the STM32F401 which is onboard the Nucleo - but that it would be quite easy to switch between targets once the stm32f103 boot loader was programmed?

Does that sound correct?

RadioOperator commented 4 years ago

Hi, @linuxtim: DAPLink on STLINK clone with F103CB, refer to: https://github.com/bh3nvn/DAPLink253

CMSIS-DAP on STLINK & BluePill, refer to: https://github.com/RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO

0xc0170 commented 4 years ago

DAPLink on STLINK clone with F103CB, refer to: https://github.com/bh3nvn/DAPLink253

The first reference - 5 commits ahead - will this be upstream anytime?

RadioOperator commented 4 years ago

@0xc0170 I think he did not request to Pull into the DAPLink master, just in the his repo local. I have the BIN files.

tim-seoss commented 4 years ago

Thanks. These links are helpful, but they're illustrative of the main purpose of the bug - there is an 'official' place to look for DAPLink binaries - which is here: https://armmbed.github.io/DAPLink/ - but these boards aren't included in those builds. Instead there are myriad forked git repositories and forum posts with misc binaries of various versions around.

I'd guess the majority of ARM stand-alone debuggers in existence are STM32 based, and whilst I realise that many of the older ones can't run DAPLink due to insufficient flash, many more recent ones (the STLink v3 being an excellent example) would be quite capable of the task.

Having spoken to various other developers, those that have looked generally decided that it all looked a bit sketchy, and/or weren't able to figure out what to trust/use, and just went back to using STLink or JLink. To people outside the project it just looks opaque, and non-usable or non-viable.

tim-seoss commented 4 years ago

To expand on that @RadioOperator - I appreciate your work here it looks good, and I'll be trying it out later on today if possible.

More generally my outsider's perspective: it would be great if the DAPLink maintainers could either pick this work up, and provides binaries on the official site, or if they'd prefer, then signpost these third party resources to make them easier for find.

RadioOperator commented 4 years ago

@tim-seoss You are talking about DAPLink target user! For the C-code developers, we no need use DAPLink, we have one of CMSIS-DAP/JLink/STLink tools, good enough. DAPLink is important for IC supplier / System provider, they are selling some target-boards or Child-education system, then they need a cheap debugger solution / drag&drop functions. They combined DAPLink in their system, and they solve everything for end-user. So make a standalone DAPLink tools is wasting our time, we cannot make it works for "all different ICs" with bug-free, especially by one person's efforts. If some on-hand board/system does not come with DAPLink tools, just forget DAPLink, and try CMSIS-DAP or others. Please correct me if I'm wrong.

tim-seoss commented 4 years ago

For the C-code developers, we no need use DAPLink, we have one of CMSIS-DAP/JLink/STLink tools, good enough.

To be clear, I'm talking about developers for C etc.

I agree that now whilst developing people must rely on closed source tools like JLink/STLink (or perhaps sometimes the CMSIS-DAP provided for a dev board), and the advice I've received from other developers is that they often hit bugs in these tools which they cannot fix because they are closed source (of in the case of CMSIS-DAP the board may be using an old fork) - so this doesn't make them "good enough" - or at least they could be better.

Isn't one of the purposes of the DAPLink project to provide a viable open source alternative to these tools?

If it's just for end-user firmware upgrades, then many modern MCUs provide USB bootloader support modes anyway, so why would they need the expense of implementing DAPLink as well just for programming? Also wider adoption must be better for DAPLink in general, because then it will gain more contributors and real-world testing.

I do acknowledge that maybe I've misunderstood the aim of the project - if-so, then that might be a documentation bug! :-)

40Grit commented 4 years ago

I'd actually bet the Kinetis K20 circuit is the most common.

I'm not sure if STM hic's are maintained by ARM. ST seems to think there is value in continuing to keep stlink closed source.

Which makes me think maybe there is a reason ST was not named as part of the Mbed working group recently.

40Grit commented 4 years ago

...Considering all the Nuvoton and silicon labs activity in here recently

therealprof commented 4 years ago

@40Grit To be honest it doesn't make a whole lot of difference whether the implementation is OpenSource or not if a regular developer cannot compile it or contribute due to the requirement of a proprietary compiler. If I'm going to trust a binary blob I might as well trust a binary blob from ST or use an alternative protocol implementation from a third party which really does not help winning popularity contests...

RadioOperator commented 4 years ago

@tim-seoss I think DAPLink is just a Target IC specific dev-tools of CMSIS-DAP with additional functions, and those functions is better to have for us, but is Must for some educational system.

therealprof commented 4 years ago

@RadioOperator I don't follow what you're trying to say. People are actually building their own debug probes now for a variety of reasons. But ALAS it is not possible to run official DAPLink firmware on them due to the mismatch of available binaries/hardware which is a shame. I think this project should strive to make the technology as available as possible and providing binaries for the somewhat easy to handle and readily available STM32F103 seems like a good step in that direction.

RadioOperator commented 4 years ago

Open source project, sometimes means AS-IS, no supporting, fast-changing, and not bug-free. If you found ST-LINK's bugs, just report to ST, easy to get updated FW version.

therealprof commented 4 years ago

@RadioOperator I'm sorry but we do have a fundamentally different understanding of Open Source. None of the projects I've worked on in the last 25 years had such low requirements.

If you found ST-LINK's bugs, just report to ST, easy to get updated FW version.

Yeah, just don't hold your breath while you wait or depend on that or you might be in for a bad surprise...

RadioOperator commented 4 years ago

@therealprof I think those DAPLink bin code, the responsibility is on the Target system suppliers. For example, NXP using DAPLink, we always could download the updated DAPLink firmware for their specific board from NXP site. I know that, to maintains a group of bin codes, is a hard job. Because the real world is too many different things. "your fw is not work on MY board......". Anyway better to have some Bin code somewhere.

40Grit commented 4 years ago

If anybody had the time to port it to RTX5 it could be built woth AC6 which comes with Mbed Studio free.

Alternatively someone could take the time to port it to GCC.

Embedded Planet has placed an intern on the effort but this is one of many tasks assigned to them.

For the time being we are making blind commits and having ARM's CI build for us. We then test on the target hic manually.

That is what we did for our "Flidor" debug adapter which uses the K20 circuit. We are working on adding SWO support for the K20 circuit as well.

RadioOperator commented 4 years ago

@tim-seoss Hi, If you need the bin code for STLINK clone to try it, I can email you.

tim-seoss commented 4 years ago

Hi, If you need the bin code for STLINK clone to try it, I can email you.

@RadioOperator That would be helpful thanks in the short term (actually this is for an STLink v2-1 onboard an ST Nucleo, not a clone). My email address is in my github profile.

But longer term, it'd be great if the DAPLink team made these available automatically...

protobits commented 3 years ago

Hi, I see that a build for stm32f103xb is available for v254 now. But this is not documented anywhere (even no mention in release notes). What is the expected pinout when using this pin? I can infer from the code but this should be documented somewhere. Does this aim to a specific STM32F103 device/reference circuit?

linuxtim commented 3 years ago

@v01d I haven't checked, but I'd guess it's for one of the stm32f103 designs here: https://github.com/ARMmbed/mbed-HDK-Eagle-Projects/tree/master/DAPLink/Probes

From what I can remember this was largely compatible with the ST Link v2 schematic. For the on-board stm32f103 based ST Link on Nucleo boards, there is a slight difference in that the stlink stm32f103 is configured to output a clock signal on one of its pins which is used as the clock input to the target MCU (and keeps UARTs in sync etc.).

Unless the DAPLink code also enables that, then you're restricted to either soldering a crystal to the target part of the board (there's an unpopulated space for one), or using the internal oscillator on the target.

mbrossard commented 3 years ago

Hi, I would like to restart this thread.

The develop branch can now be compiled with GCC. I have done a few tests on a NUCLEO-F401RE board that should be relevant for other ST-Link v2-1 platforms. First of all, it works: MSD, CDC, HID.

One topic that has not been addressed is the stm32f102xb_bl bootloader, because current binaries assume a pair stm32f102xb_bl / stm32f102xb_if, and stm32f102xb_bl, as all other *_bl.bin, is not distributed.

Now for the hard part how do you load it:

I have hacked all three solutions, and it feels like 1) and 2b) are more interesting, but none seem completely right.

What do you think?

(*) The challenges are tied to the ST-Link DFU loader:

Krakonos commented 2 years ago

Hi! first of all, thanks for the work done on this issue and GCC support in general.

1) I have one question to this: one of the arguments here was too many firmware combinations. I'm only interested in using the DAPLink firmware as CMSIS-DAP adapter on a custom debugger adapter. For this use-case, specific target support is not necessary (or even wanted). Is it possible to at least include the support for the bare HIC without specific target support (via drag and drop etc.)?

2) I tried compiling the develop branch per the documentation in the branch. It compiles, thouhg using:

progen generate -t make_gcc_arm -p stm32f103xb_if -b

eventually errors out with:

Invoking: MCU Linker
arm-none-eabi-gcc  -o build/stm32f103xb_if.elf  build/flash.o build/gpio.o build/read_uid.o build/sdk.o build/stm32f1xx_hal.o build/stm32f1xx_hal_cortex.o build/stm32f1xx_hal_dma.o build/stm32f1xx_hal_flash.o build/stm32f1xx_hal_flash_ex.o build/stm32f1xx_hal_gpio.o build/stm32f1xx_hal_gpio_ex.o build/stm32f1xx_hal_rcc.o build/stm32f1xx_hal_rcc_ex.o build/stm32f1xx_hal_tim.o build/stm32f1xx_hal_tim_ex.o build/stm32f1xx_hal_uart.o build/stm32f1xx_hal_usart.o build/system_stm32f1xx.o build/uart.o build/usb_config.o build/usbd_STM32F103.o build/usbd_user_cdc_acm.o build/usbd_bulk.o build/usbd_cdc_acm.o build/usbd_core.o build/usbd_core_cdc.o build/usbd_core_hid.o build/usbd_core_msc.o build/usbd_core_webusb.o build/usbd_core_winusb.o build/usbd_hid.o build/usbd_msc.o build/usbd_user_hid.o build/target_reset_Kseries.o build/target_reset_Lseries.o build/target_reset_mimxrt.o build/target_reset_nrf51.o build/target_reset_nrf52.o build/target_reset_rapid_iot.o build/target_reset_realtek_rtl8195am.o build/target_reset_rza.o build/target_reset_ti.o build/target_reset_tz.o build/target_reset_wiznet.o build/settings.o build/settings_rom.o build/file_stream.o build/flash_decoder.o build/flash_intf.o build/flash_manager.o build/iap_flash_intf.o build/intelhex.o build/vfs_manager.o build/vfs_user.o build/virtual_fs.o build/RTX_Config.o build/os_systick.o build/rtx_delay.o build/rtx_evr.o build/rtx_kernel.o build/rtx_lib.o build/rtx_memory.o build/rtx_mempool.o build/rtx_msgqueue.o build/rtx_mutex.o build/rtx_system.o build/rtx_thread.o build/rtx_timer.o build/HardFault_Handler.o build/bootloader_update.o build/circ_buf.o build/cortex_m.o build/crc32.o build/daplink.o build/error.o build/flash_hal.o build/info.o build/main_interface.o build/sdk_stub.o build/swd_host.o build/swd_host_ca.o build/target_flash.o build/util.o build/validation.o build/DAP.o build/DAP_queue.o build/DAP_vendor.o build/JTAG_DP.o build/SWO.o build/SW_DP.o build/target_board.o build/target_family.o  build/startup_stm32f103xb.o build/irq_cm3.o  -lm  -lgcc  -lc  -lnosys   --specs=nano.specs  --specs=nosys.specs  -Wl,-check-sections  -Wl,-fatal-warnings  -Wl,--gc-sections  -Wl,--no-wchar-size-warning  -Wl,--print-memory-usage  -mcpu=cortex-m3 -mthumb -Wl,-Map=build/stm32f103xb_if.map,--cref -T../../../source/daplink/daplink.ld 
/home/krakonos/kgcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld:../../../source/daplink/daplink.ld:24: ignoring invalid character `#' in expression
/home/krakonos/kgcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld:../../../source/daplink/daplink.ld:24: syntax error

Indeed, the is #include ... statement on line 24, but GCC docs says the linker script should use the INCLUDE file syntax instead. Is the build system supposed to run that file though regular C preprocessor first? Anyone knows what the deal is there?

Once this is solved, I'm inclined to use approach i. outlined above. I feel like it's good enough for general usage, and recovery should only be necessary during development and in that case, SWD is a reasonable requirement. Fighting with the ST-Link DFU makes no sense to me.

elfmimi commented 2 years ago

@Krakonos build steps do involve preprocessing ldscript. see here it could be that you are using old project_generator. latest version is 0.11.1 .

to change application memory layout of 'if' firmware, edit these two lines.

#define DAPLINK_ROM_IF_START            0x08000000
#define DAPLINK_ROM_IF_SIZE             0x0001FC00
Krakonos commented 2 years ago

Weird. My project-generator is 0.11.1:

krakonos@muskox ~ $ project_generator --version
0.11.1

But my ./projectfiles/make_gcc_arm/stm32f103xb_if/Makefile contains:

LD_SCRIPT = ../../../source/daplink/daplink.ld
[...]
LD_OPTIONS +=  -mcpu=$(CPU) -m$(INSTRUCTION_MODE) -Wl,-Map=$(OBJ_FOLDER)$(TARGET).map,--cref -T$(LD_SCRIPT)

as if preprocess_linker_file was false. Not sure what's going on, will play with that a bit more. Perhaps we should take that to a different issue as well if it turns out to be non-trivial problem.

tim-seoss commented 2 years ago

Thanks for the work on this! I think either of "2a" or "2b" sound reasonable at first glance, and would be similar to the approach that Segger use for their Nucleo-compatible firmware (see "Converting ST-LINK On-Board Into a J-Link" via your favour means of web search).

Unless the generic stm32f103 version was also configured to pass-along the clock signal to the target, then (some?) Nucleo boards would have the clock issue I mentioned in https://github.com/ARMmbed/DAPLink/issues/662#issuecomment-735254142 .