DEV Community: Rajeev Bharol

Mystery of addresses on ARM SWD port

Rajeev Bharol — Sat, 24 Apr 2021 06:55:21 +0000

Serial Wire Debug (SWD) is a two-wire protocol for accessing the
ARM debug interface. It is part of the ARM Debug Interface Specification v5. In may projects you may need to program or debug the ARM chip over the SWD interface. For me, the most confusing part was understanding the addressing. This article is written to help those may be in same situation as me.

On SWD interface is a Debug port (DP) that is the gateway to the inside of the processor. It provides access to many Access Ports (APs). Access ports are specific to the processor and can be more than one. I will not go into details of various APs. I just want to demystify the addressing for DP and APs in this post.

The 8 bit header in a SWD transaction packet looks like:

----------------------------------------------------------
| Start | AP/DP | R/W | ADDR[0:1] | Parity | Stop | Park |
----------------------------------------------------------

The header has two bits reserved for addressing. Anybody trying to write any application to use SWD would be stuck at this step for a while trying to figure what can I do with two bit address! Many examples on the internet will talk about DP addresses to be 0x00, 0x04, 0x08 and 0x0C which is correct but how can you have these 8 bit addresses with two bits? Answer is in ARM debug architecture document here. The lower two bits of the address [Bits A1:A0] are always 00. Those when used with these two bits in the SWD transaction packet i.e., [Bits A3:A2] gives us one full nibble:

A3 A2 A1 A0
0  0  0  0    = 0x0
0  1  0  0    = 0x4
1  0  0  0    = 0x8
1  1  0  0    = 0xC

But where does that upper nibble '0' of 0x00, 0x04, 0x08 and 0x0C come from to make the addresses 0x00, 0x04, 0x08 and 0x0C? That comes from Select register's DP BANKSELECT field. Confused yet? It is confusing.

There is a 32 bit "Select" Register in DP which has three useful fields:

Bits [31:24] -> Access port ID
Bits [23:8]  -> Reserved, not used
Bits [7:4]   -> AP Bank select
Bits [3:0]   -> DP Bank Select

These 4 bits (bits 3:0) in DP Bank select field make the upper nibble of the DP register address. On power up the values of these bits is always 0 on DP architecture rev 0 (on other revs it can be non zeros and addresses changes accordingly) so the register addresses at power up are:
Bits [3:0] of DP Bank Select + [A3 A2 A1 A0]

That makes up the Debug Port address:
0x00
0x04
0x08
0x0C

This explains how the Debug Port addresses are created. There is one more twist to it. In the SWD packet header you will see the address bits marked as A[2:3]. Bit 2 is written first because LSB is sent on the bus first. If desired address is say, 0x08, these two bits will be written and sent as 01 (not 10)

Same logic of addressing applies to Access Port addresses when we are trying to access the Access port registers. From bits A3 and A2 in the SWD packet we make to the lower nibble of the address. A1 and A0 are always zeros so we get

A3 A2 A1 A0
0  0  0  0    = 0x0
0  1  0  0    = 0x4
1  0  0  0    = 0x8
1  1  0  0    = 0xC

Similar to Debug port addressing, Upper nibble of the address comes from the AP Bank select field of the Select register. These are bits [7:4] of the select register. Suppose we want to access register 0x14 in Access port #0. we will write 0x01 to Bits [7:4] in the DP select register so the upper nibble of the address now is 0x1. The DP will combine this with Bits A3:A0 to create address 0x14. So effectively it is a two step process to access the AP. I hope it helps those looking for this information.

Executing code from RAM on STM32 ARM Microcontrollers

Rajeev Bharol — Wed, 21 Apr 2021 21:23:03 +0000

While working on a project using STM32F4* ARM core processor, I had a situation where I had to run the code from internal flash of the STM32F4. In almost all example applications you will find that this processor holds the executable code in the flash and executes from the internal flash. Internal flash is fast enough and large enough for most projects. However in certain cases you may need to execute from RAM and world wide web search may not get you much help. In this article I will show how to execute your code from RAM on an ARM core processor but the logic would apply to any. Assumption made here is that the code is sitting in the internal flash which needs to execute from the RAM.

First case
Let us work on a the case when you want to run only a single routine or a small module in RAM. This can be a case, for example, when you want to execute some compute extensive code in faster internal RAM which executes faster than Flash. Here is the trick to do it:

First, use attribute keyword to put the function a section "code_in_ram". Name of the section doesn't matter but use of the attribute to create a new section does.

__attribute__ ((long_call, section (".code_in_ram"))) void foo(void)                            
{                                                                                
  // Do something here
}

Second step would be to add one line in the linker script in data section, as shown below:

  _sidata = LOADADDR(.data);                                                          
  .data :                                                                        
  {                                                                              
    . = ALIGN(8);                                                                
    _sdata = .;
    *(.data)                                                                     
    *(.data*)                                                                    
    *(.code_in_ram) <--- Insert here                                                          
    . = ALIGN(4);                                                                
    _edata = .; 
  } >RAM AT> FLASH

With these two changes, the function foo would be linked in the RAM and your init code already in place in the startup *.s file shall take care of copying this code into the RAM. You don't need to know but the init code looks like:

  movs  r1, #0                                                                   
  b  LoopCopyDataInit                                                            

CopyDataInit:                                                                    
  ldr  r3, =_sidata                                                              
  ldr  r3, [r3, r1]                                                              
  str  r3, [r0, r1]                                                              
  adds  r1, r1, #4                                                               

LoopCopyDataInit:                                                                
  ldr  r0, =_sdata                                                               
  ldr  r3, =_edata                                                               
  adds  r2, r0, r1                                                               
  cmp  r2, r3                                                                    
  bcc  CopyDataInit

How does it help? We are now telling the linker that the code in the section "code_in_ram" is supposed to be mapped to RAM but it is sitting in FLASH. Linker just follows what is in this script. After that the initialization code does the magic. Since the initialization code already has the logic in place to copy data section variables into RAM, we just piggy back the init code to copy the executable code "code_in_ram" in to the RAM. Init code is in the startup file (usually an assembly file starting with the name Startup and with .s extension).

Second case
This is the case when your entire source code is small enough to fit in the internal RAM and you want to execute it from RAM. This leaves most of your internal flash for other uses. This is an example of the Linker file and your linker file would look the same. Do not copy this linker snippet. It is here for illustration. Work on your linker script. Find where your text section is defined. It should look similar to the following:

  .text :                                                                       
  {                                                                             
    . = ALIGN(4);                                                               
    *(.text)  <-- Remove this
    *(.text*) <-- Remove this
    . = ALIGN(4);                                                               
    _etext = .; 

  } >FLASH

There may be another section in the same linker file which would look like. If you want to move every thing out of Flash, remove rodata as well.

  .rodata :                                                                     
  {                                                                             
    . = ALIGN(4);                                                               
    *(.rodata)  <-- Remove this
    *(.rodata*) <-- Remove this
    . = ALIGN(4);                                                               
  } >FLASH

Now look for the data section which looks like as follows: Move the text and rodata sections that you just commented out above to this section as shown below. Do not change anything else. This will make your entire code execute from RAM (Please note that tiny initialization code would still need to execute from flash before it jumps to RAM code)

  _sidata = LOADADDR(.data);                                                          
  .data :                                                                        
  {                                                                              
    . = ALIGN(8);                                                                
    _sdata = .;
    *(.data)                                                                     
    *(.data*)
    *(.rodata)  <--- Move it here in .data section
    *(.rodata*) <--- Move it here
    *(.text)    <--- Move it here
    *(.text*)   <--- Move it here
    . = ALIGN(4);                                                                
    _edata = .; 
  } >RAM AT> FLASH

What we did here is same as in first case above, except that instead of copying one part of the code in RAM we are copying the entire text section (executable code) in the RAM. You can confirm that the addresses of all your code are mapped to RAM address in the map file generated by the linker and/or in the debugger.