Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/DEVELOPERS-GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ There are three defined ways in which DAPLink can be extended. These are adding


## Test
DAPLink has framework that allows automatic loading and testing of software on one or more boards. This can be run on the current development environment or a release package. Test results are written to the current directory, along with printed to the console. Testing is run from the run_test.py script in the test directory. For all testing options, see the run_test.py help output - ``run_test.py --help``. To run basic tests with the current development environment, see the steps below.
DAPLink has a framework that allows automatic loading and testing of software on one or more boards. This can be run on the current development environment or a release package. Test results are written to the current directory and printed to the console. Tests are launched using the run_test.py script in the test directory. Specify --help to view testing options (``run_test.py --help``). To run basic tests with the current development environment, see the steps below.

* Build the project to be tested.
* [Enable automation mode](ENABLE_AUTOMATION.md) on the board if is has not been enabled already
Expand Down
8 changes: 4 additions & 4 deletions docs/ENABLE_AUTOMATION.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Enable Automation Features
1. Update the interface software to a version at or above 0241
2. Create an empty text file called "auto_on.cfg" on the drive while the reset button is held
3. Release the reset button after the drive remounts and confirm "Automation Allowed" is set to 1 in details.txt
4. Update the bootloader software to a version at or above 0241
5. Confirm that "start_bl.act" causes the device to enter bootloader mode and "start_if.act" causes the device to enter interface mode
1. Copy an empty text file called "auto_on.cfg" to the DAPLink MSD drive while the reset button is held.
1. Release the reset button when the drive unmounts. When it remounts, confirm "Automation Allowed" is set to 1 in details.txt
1. Update the bootloader software to a version at or above 0241
1. Confirm that the "start_bl.act" MSD command causes the device to enter bootloader mode, and that the "start_if.act" command causes the device to enter interface mode. See [MSD Commands](MSD_COMMANDS.md)
61 changes: 61 additions & 0 deletions docs/MSD_COMMANDS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# MSD Commands

DAPLink allows you to give it some simple commands via its MSD interface. By
copying a file with a certain name to the root of the DAPLink MSD drive, you
can get DAPLink to either perform an action or configure a flash-persisted
option. The contents of the file are ignored; you can pass it an empty file.

These MSD commands work only if you are either holding down the RESET button
when you add the file to the MSD drive, or if you've turned on DAPLink's
automation-allowed mode. Of course, the way you turn on automation-allowed
mode is via an MSD command (see below). So, you'll either hold the RESET
button each time you invoke an MSD command or you do so only once to turn
on automation-allowed mode. This mode is saved in flash and so it persists
across board reboots.

By convention, files that end with ".act" trigger an action; files that end
with ".cfg" trigger an option change. The mechanism is case-insensitive.

Every command completes by remounting the DAPLink MSD drive. Every command
is supported in both interface and bootload mode.

`start_bl.act` This file will force DAPLink to remount in bootloader mode.
It is equivalent to unplugging the USB cable, and plugging it back in while
holding the RESET button. This command has no effect if DAPLink is already
in interface mode.

`start_if.act` This file will force DAPLink to remount in interface mode. It
is equivalent to unplugging the USB cable and plugging it back in, when
DAPLink is currently in bootloader mode. This command has no effect if DAPLink
is already in bootloader mode.

`auto_rst.cfg` This file will turn on Auto Reset mode. In this mode, the RESET
pin is automatically asserted after programming an application image to the
target processor flash via the DAPLink MSD drive (in interface mode). Note
that this mode does not affect when happens when you update the Hardware
Interface Circuit firmware (DAPLink) via the DAPLink MSD drive in bootloader
mode.

`hard_rst.cfg` This file turns off Auto Reset mode.

`assert.act` This file can be used to test DAPLink's assert utility. When you
copy this file to the DAPLink MSD drive, DAPLink generates a call to the
util_assert() method. An assert call causes the DAPLink MSD drive to remount
with an additional file, ASSERT.TXT, appearing at the root of the drive. This file
details where the assertion failure occurred (source file, line number). An
assert call is a no-op if there is already an outstanding assert failure (there
can only be one). The outstanding assertion failure can be cleared by deleting
ASSERT.TXT. The deletion causes a remount of the DAPLink MSD drive. In actuality,
any file operation (addition, deletion, content change) could be used to trigger
a DAPLink command. Deleting ASSERT.TXT is actually a DAPLink MSD command in its
own right.


`refresh.act` This file forces a remount of the DAPLink MSD drive

`auto_on.cfg` This file turns on automation-allowed mode. In this mode, DAPLink
MSD commands can be triggered without needing to hold down the RESET button
while copying the command file to the DAPLink MSD drive. Also, bootloader updates
are allowed only in automation-allowed mode.

`auto_off.cfg` This file turns off automation-allowed mode.
2 changes: 1 addition & 1 deletion docs/PORT_BOARD.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ A board is composed of a Hardware Interface Circuit and target MCU. To create a
- records/board/myboardname.yaml
```

Next create a new file in the `records/board` dirctory called myboardname.yaml. This file defines the target MCU and allows overrideable board parameters to be configured. The target MCU in this example exists and is a Nordic nRF51822 (16k RAM variant)
Next create a new file in the `records/board` directory called myboardname.yaml. This file defines the target MCU and allows overrideable board parameters to be configured. The target MCU in this example exists and is a Nordic nRF51822 (16k RAM variant)

```yaml
common:
Expand Down
12 changes: 6 additions & 6 deletions docs/PORT_TARGET.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
# Adding A New Target
Adding new target support requires creating a flash algo blob and the implementation for some stub functions. Target support is added to the `source/target/<mfg>/<target>` directory. At minimum, 3 files are needed. The first is `source/<mfg>/target_reset.c`
Adding new target support requires creating a flash algo blob and the implementation for some stub functions. Target support is added to the `source/target/<mfg>/<target>` directory. At minimum, 3 files are needed. The first is `source/target/<mfg>/target_reset.c`

```c
/**
Expand Down Expand Up @@ -50,7 +50,7 @@ uint8_t target_set_state(TARGET_RESET_STATE state)

uint8_t security_bits_set(uint32_t addr, uint8_t *data, uint32_t size)
{
// if there are security bits in the programmable flash reigon
// if there are security bits in the programmable flash region
// a check should be performed. This method is used when programming
// by drag-n-drop and should refuse to program an image requesting
// to set the device security. This can be performed with the debug channel
Expand Down Expand Up @@ -130,7 +130,7 @@ static const program_target_t flash = {
0x20000000, // location to write prog_blob in target RAM
sizeof(targetname_blob), // prog_blob size
targetname_blob, // address of prog_blob
0x00000200 // ram_to_flash_bytes_to_be_written
0x00000200 // program_buffer_size, largest size that can be written in a single call to program page
};

```
Expand Down Expand Up @@ -166,10 +166,10 @@ The last required file is the target MCU description file `source/targets/<mfg>/

// target information
const target_cfg_t target_device = {
.sector_size = 4096,
.sector_cnt = (MB(1) / 4096),
.sector_size = 2048,
.sector_cnt = (KB(512) / 2048),
.flash_start = 0,
.flash_end = MB(1),
.flash_end = KB(512),
.ram_start = 0x20000000,
.ram_end = 0x20010000,
.flash_algo = (program_target_t *) &flash,
Expand Down
4 changes: 2 additions & 2 deletions tools/build_release_uvision.bat
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@
:: See the License for the specific language governing permissions and
:: limitations under the License.
::

rmdir /q /s uvision_release
mkdir uvision_release
git rev-parse --verify HEAD > uvision_release\git_info.txt
git diff --no-ext-diff --quiet --exit-code >> uvision_release\git_info.txt
Expand All @@ -32,4 +32,4 @@ progen generate -t uvision -b
SET LEVEL=%ERRORLEVEL%
python tools/copy_release_files.py
if %errorlevel% neq 0 exit %errorlevel%
exit %level%
exit /B %level%