SWD-CAN bus bridge by STM32

[BUTTHEAD]

Hi! I want to design SWD-CAN bridge to program and debug STM32 devices via CAN. The bootloader is not suitable because it can upgrade firmware to CPU, but not allow tracking. I need something like ST-LINK, but with CAN interface.
My idea: the board have, simplifying, 2 CPU: 1 - main CPU, which do base program, and 2 - CPU, which can reprogram main CPU and wath for additional information (safety function). CPU#2 receive frames via CAN bus by predefined protocol, hold its in memory , check for errors, and then (if no errors found), load it to CPU#1 via SWD. User can look for program using STM Studio or something else. There are no need in printf (something).
But I did not find nor description of SWD for Cortex M3, nor code examples of making SWD master.

[ataradov]

Here is example of one MCU programming anther MCU https://github.com/ataradov/embedded-swd

It is for Microchip parts, so you would have to change stuff in the dap_target.c to match your STM device. The DAP part will be universal.

There is not a single document that describes everything about SWD. The low level protocol (physical signalling and the DAP part) is described in the ARM documentation. This will give you access to the MCU as  master on the bus.

After that you need to access the flash controller to perform the actual programming. And this is covered by the ST user manuals for specific devices.

[BUTTHEAD]

Thanks a lot!

The low level protocol (physical signalling and the DAP part) is described in the ARM documentation.

I have found this document:
ARM® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2
https://static.docs.arm.com/ihi0031/c/IHI0031C_debug_interface_as.pdf
It is good start?

t is for Microchip parts, so you would have to change stuff in the dap_target.c

I am look this code, and find that, for example

Code: [Select]

#define DHCSR                  0xe000edf0And, according this:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/CEGCJAHJ.html
The DHCSR:
is a 32-bit read/write register
address is 0xE000EDF0
Is this defines common for all Cortex M3 based parts?

Code: [Select]

dap_write_word(DHCSR, 0xa05f0003);Debug Key. 0xA05F must be written whenever this register is written.
Set C_HALT, C_DEBUGEN

[ataradov]

ARM® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2
It is good start?

Yes, this will contain most of the stuff you need.

The DHCSR:
is a 32-bit read/write register
address is 0xE000EDF0
Is this defines common for all Cortex M3 based parts?

Yes, DHCSR, DEMCR and AIRCR are common for all parts, and the values written should be the same too.

[BUTTHEAD]

And some more questions:

Code: [Select]

dap_write_word(NVMCTRL_CTRLB, 0);Is it command for flash controller to enable write operation?
And what is

Code: [Select]

#define DSU_DID                0x41002118?
Is I need for beginning find the same registers on desired MCU?

Code: [Select]

  uart_puts("\r\nDSU_DID = ");
  uint32_t dsu_did = dap_read_word(0x41002118/*DSU_DID*/);
  uart_puthex(dsu_did, 8);
  uart_puts("\r\n");

Here something on address 0x41002118 read and put to uart. In same way it can be readed any adress (variable or hardware register)?

Also I am not properly understand, how to access to SWD port.

[ataradov]

And some more questions:
Is it command for flash controller to enable write operation?
And what is DSU_DID?
Is I need for beginning find the same registers on desired MCU?

This is the MCU-specific stuff. This part will be completely different for ST. DSU_DID is a device identification register, and CTRLB configures some stuff for the flash controller in the Microchip SAM D21.

Here something on address 0x41002118 read and put to uart. In same way it can be readed any adress (variable or hardware register)?

Yes. dap_read_word() and dap_write_word() let you read/write any location inside the MCU memory map. You can toggle the pins, send UART characters, and generally do whatever CPU core can normally do. Debugger in this case just takes over the core (hence all those commands to halt the core).

Also I am not properly understand, how to access to SWD port.

What exactly do you mean by "access"?

[BUTTHEAD]

Code: [Select]

What exactly do you mean by "access"?
How to toggle this pins on master device by specification? Is it software implementation of SWD state machine?

[ataradov]

How to toggle this pins on master device by specification? Is it software implementation of SWD state machine?

Yes, it is purely software thing. That's exactly what code in dap.c does. You can take it as is. All you need to do is re-implement functions for toggling the actual pins for your master in dap_config.h.

[BUTTHEAD]

According ST reference manual:

38.8.3 SW-DP state machine (reset, idle states, ID code)
The State Machine of the SW-DP has an internal ID code which identifies the SW-DP. It
follows the JEP-106 standard. This ID code is the default Arm® one and is set to
0x2BA01477 (corresponding to Cortex®-M4 with FPU r0p1).
Note: Note that the SW-DP state machine is inactive until the target reads this ID code.
• The SW-DP state machine is in RESET STATE either after power-on reset, or after the
DP has switched from JTAG to SWD or after the line is high for more than 50 cycles
• The SW-DP state machine is in IDLE STATE if the line is low for at least two cycles
after RESET state.
• After RESET state, it is mandatory to first enter into an IDLE state AND to perform a
READ access of the DP-SW ID CODE register. Otherwise, the target will issue a
FAULT acknowledge response on another transactions.

And, according Debug Interface Architecture:

3.4.2 IDCODE, the JTAG TAP ID register
Purpose JTAG-DP TAP identification. The IDCODE value enables a debugger to identify the Debug Port to
which it is connected. JTAG-DP implementations have different IDCODE values, so that a
debugger can distinguish between them.

So, is I need to implement reading this register in function dap_target_select()?
Secondary,

Yes. dap_read_word() and dap_write_word() let you read/write any location inside the MCU memory map. You can toggle the pins, send UART characters, and generally do whatever CPU core can normally do. Debugger in this case just takes over the core (hence all those commands to halt the core).

If I need to only watch by some variable, it is no need to halt core, or I must do this anyway?

[ataradov]

No, this is already done in the dap_reset_link().

You don't have to halt the core if you don't actually program the flash. You can read/write any registers you like while the core is running. You need to stop the core if you are writing the flash to avoid potential code execution from the same area you are about to write.

[BUTTHEAD]

I found it. As I understand, the

Code: [Select]

dap_swj_sequence((7 + 2 + 7 + 1) * 8, buf);need to the DP has switched from JTAG to SWD. Correct?

[ataradov]

I found it. As I understand, the

Code: [Select]

dap_swj_sequence((7 + 2 + 7 + 1) * 8, buf);need to the DP has switched from JTAG to SWD. Correct?

Yes, exactly. It is a standard sequence mentioned somewhere in ARM documents.