Programming internal SRAM over SWD

This documentation describe how to programming ARM Cortex M3 internal SRAM over SWD(Serial Wire Debug) interface. For this purpose, something we too know.

SWD communication protocol. We need to know Low level timing requirement, that is foundation to exchange command and data between debugger and target MCU.
Read/write data from/to internal SRAM. We need to know how to program firmware into desired address, like SRAM(0x20000000). That needs us to know SW-DAP registers usage. Pass address and data over those registers and then into internal SRAM.
Make code running from SRAM. We need to change vector table entry from internal flash to SRAM; And SP and PC also needed change to SRAM location. That need us to know the cortex M3 debug and system registers usage.
We choose Silabs SiM3U167 as target MCU in this implementation. We implement a high level protocol with python script, it calls Silabs provided DLL file interface to access Silabs USB Debug Adapter. Also, we provide a firmware running from C8051F380, it contains a full implementation on both low level communicating timing and high level programming SRAM protocol.


swd_programing_sram-master.zip (5.99 MB, 下载次数: 185) 2015-8-22 17:47 上传 点击文件名下载附件

https://www.xiaopingtou.cn/data/attach/1912/k45wtilxjfpun4k2qau1rbzospg0z7mj.jpg MBED-HDK SWD Interface

未命名-1.gif (10.71 KB, 下载次数: 0)

下载附件

2015-8-22 18:30 上传

IBDAP-CMSIS-DAP IO模拟SWD时序

Armstart's CMSIS-DAP firmware implementation in gcc and makefile.

IBDAP-CMSIS-DAP-master.zip (133.93 KB, 下载次数: 130) 2015-8-22 21:15 上传 点击文件名下载附件

swddude -- A SWD programmer for ARM Cortex microcontrollers.

需要提供底层驱动

swddude-master.zip (55.88 KB, 下载次数: 107) 2015-8-22 21:18 上传 点击文件名下载附件

1. #ifndef SWD_H
   
2. #define SWD_H
   
3. 
   
4. /*
   
5. * Abstract base class for SWD interface drivers.
   
6. */
   
7. 
   
8. #include "libs/error/error_stack.h"
   
9. 
   
10. #include <stdint.h>
    
11. 
    
12. /*
    
13. * SWDDriver provides a low-level interface to SWD interface devices.
    
14. * Each function maps directly to a SWD protocol concept.  The ARM ADIv5
    
15. * specification explains the SWD protocol in more detail; it's available
    
16. * behind a clickwrap license on ARM's site.
    
17. *
    
18. * Client software should rarely interact with SWDDriver directly.  Instead,
    
19. * wrap it in another object that provides a higher-level more pleasant
    
20. * interface with support for things like retries and named registers.
    
21. */
    
22. class SWDDriver {
    
23. public:
    
24.     /*
    
25.      * Creates an instance of the driver.  Because the constructor can't
    
26.      * return any meaningful error condition, implementations should only do
    
27.      * things that can't fail -- such as copying in constructor arguments
    
28.      * and initializing memory.
    
29.      */
    
30.     SWDDriver() {}
    
31. 
    
32.     /*
    
33.      * Destroys this driver instance.  Because the destructor can't return
    
34.      * any meaningful error condition, any resource cleanup here is
    
35.      * last-resort.  Clients should call the close() function to clean up
    
36.      * resources in a way that can report errors.  Destructor
    
37.      * implementations may optionally log attempts to destroy a driver
    
38.      * instance without calling close(), as this indicates a programming
    
39.      * error.
    
40.      */
    
41.     virtual ~SWDDriver() {}
    
42. 
    
43.     /*
    
44.      * Initialize the SWD link to the target, per the "Connection and line
    
45.      * reset sequence" defined by the ARM ADI v5.  This has two parts:
    
46.      *   1. 50 clocks with the SWDIO line held high by the master.
    
47.      *   2. A read of the IDCODE register in the DP.
    
48.      *
    
49.      * Because this function reads IDCODE behind the scenes, it can
    
50.      * optionally return it to the application through the pointer argument.
    
51.      *
    
52.      * If this function returns successfully, it indicates that the
    
53.      * interface is functioning, and that an attached microprocessor has
    
54.      * responded to us.  The state of the target is unknown -- in
    
55.      * particular, the contents of the Debug Access Port's SELECT and
    
56.      * CTRL/STAT registers are undefined.
    
57.      *
    
58.      * Return values:
    
59.      *  Err::success - initialization complete, target responded, IDCODE
    
60.      *                 valid.
    
61.      *  Err::failure - initialization failed or target failed to respond.
    
62.      */
    
63.     virtual Err::Error initialize(uint32_t * idcode_out = 0) = 0;
    
64. 
    
65.     /*
    
66.      * Asserts the target's reset line continuously until a call to
    
67.      * leave_reset.
    
68.      *
    
69.      * Return values:
    
70.      *  Err::success - reset asserted.
    
71.      *  Err::failure - communications with interface failed.
    
72.      */
    
73.     virtual Err::Error enter_reset() = 0;
    
74. 
    
75.     /*
    
76.      * Deasserts the target's reset line, allowing it to run.
    
77.      *
    
78.      * Return values:
    
79.      *  Err::success - reset deasserted.
    
80.      *  Err::failure - communications with interface failed.
    
81.      */
    
82.     virtual Err::Error leave_reset() = 0;
    
83. 
    
84.     /*
    
85.      * Reads a 32-bit register from either the Debug Access Port (when
    
86.      * debug_port is true) or the Access Port bank named in the DAP's SELECT
    
87.      * register (when debug_port is false).
    
88.      *
    
89.      * Access Port reads are delayed: each read returns the result of the
    
90.      * previous operation.  To kick off a read without retrieving the
    
91.      * results of the last one, pass a data pointer of zero; the result
    
92.      * won't be written.  To retrieve the results of the last Access Port
    
93.      * read without starting a new one, read the Debug Access Port's RDBUFF
    
94.      * register instead.  
    
95.      *
    
96.      * Note that some registers can only be accessed in particular states of
    
97.      * the CTRL/STAT register, and some registers can't be read at all.
    
98.      *
    
99.      * Refer to the ARM ADIv5 spec for more information.
    
100.      *
     
101.      * Implementation note: drivers should implement this function such that
     
102.      * it will work regardless of mode.  In particular, it must not assume
     
103.      * that Overrun Detection is enabled in the DAP.
     
104.      *
     
105.      * Return values:
     
106.      *  Err::success   - read completed, data valid.
     
107.      *  Err::try_again - target returned SWD WAIT response, read not
     
108.      *                   completed.
     
109.      *  Err::failure   - read failed, either in the interface or due to SWD
     
110.      *                   FAULT.
     
111.      */
     
112.     virtual Err::Error read(unsigned   address,
     
113.                             bool       debug_port,
     
114.                             uint32_t * data) = 0;
     
115. 
     
116.     /*
     
117.      * Writes a 32-bit value into a register in either the Debug Access Port
     
118.      * (when debug_port is true) or the Access Port bank named in the DAP's
     
119.      * SELECT register (when debug_port is false).
     
120.      *
     
121.      * Access Port writes may take time to complete.  For a MEM-AP, monitor
     
122.      * the status of the TrInProg (transaction in progress) bit of the
     
123.      * Access Port's CSW register to detect when another write may be
     
124.      * issued.
     
125.      *
     
126.      * Note that some registers can only be accessed in particular states of
     
127.      * the CTRL/STAT register, and some registers can't be written at all.
     
128.      *
     
129.      * Refer to the ARM ADIv5 spec for more information.
     
130.      *
     
131.      * Implementation note: drivers should implement this function such that
     
132.      * it will work regardless of mode.  In particular, it must not assume
     
133.      * that Overrun Detection is enabled in the DAP.
     
134.      *
     
135.      * Return values:
     
136.      *  Err::success   - write completed.
     
137.      *  Err::try_again - target returned SWD WAIT response, write not
     
138.      *                   completed.
     
139.      *  Err::failure   - write failed, either in the interface or due to SWD
     
140.      *                   FAULT.
     
141.      */
     
142.     virtual Err::Error write(unsigned address,
     
143.                              bool     debug_port,
     
144.                              uint32_t data) = 0;
     
145. };
     
146. 
     
147. #endif  // SWD_H
     

复制代码

关注一下，虽然用这个，但是却对其不了解