You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following guide outlines a procedure to build examples to flash to the board. Examples are minimal applications intended to test a certain feature on the board.
Copy file name to clipboardExpand all lines: docs/src/content/docs/getting-started/build-obc.md
+50-11Lines changed: 50 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ The following is a simple guide for building the app for the OBC and flashing.
13
13
```
14
14
15
15
:::tip[Tip: Reducing Build Time]{icon="setting"}
16
-
The `cmake --build .` takes some time to run since it is using a single thread to compile. To speed up the process we can use one of the following commands
16
+
The `cmake --build .` takes some time to run since it is using a single thread to compile. To speed up the process we can replace it with one of the following commands...
17
17
1. `make -j 16` (Recommended for most systems)
18
18
2. `make -j 32` (This is faster but depends on if your system can handle 32 parallel jobs)
19
19
:::
@@ -26,24 +26,59 @@ The following is a simple guide for building the app for the OBC and flashing.
26
26
## Flashing to the OBC
27
27
There are two main ways to flash to the OBC: **using the bootloader** or **using UniFlash**. UniFlash is the more common way so let's go over that first.
28
28
29
-
### Flashing Via UniFlash
29
+
### Flashing via UniFlash
30
30
1. When you open UniFlash you should be greeted with the following screen...
31
31
32
32
33
-
2. For the chip select `RM46L852` if you are using OBC Revision 1 or OBC Revision 2. If you are using the Launchpad, seletc `LAUNCHXL2-RM46`.
33
+
2. For the chip select `RM46L852` if you are using *OBC Revision 1* or *OBC Revision 2*. If you are using the *Launchpad*, select `LAUNCHXL2-RM46`.
34
34
3. Then for the connection, choose `Texas Instruments XDS110 USB Debug Probe`
35
35
4. Now press `Start` and you should see the following screen.
36
36
37
37
38
-
5. Browse for the file you would like to flash and then press `Load Image`.
38
+
5. Browse for the file with a `.out` suffix that you would like to flash and then press `Load Image`. Usually you will flash one of the following files...
39
+
* `OBC-firmware.out` in the `build_arm` directory >> This contains the main app to run on the OBC.
40
+
* `OBC-bl.out` in the `build_arm` directory >> This contains the bootloader for the OBC.
41
+
* An OBC example file from the `build_examples` directory >> This is for when you want to test specific functionality on the OBC (assuming you have written a test file for it and added it to the build script. See [Building Examples](/OBC-firmware/getting-started/build-examples/))
39
42
:::note
40
-
UniFlash may get stuck sometimes and throw errors. In such cases, navigate to session on the top red bar and start a new session. You will have to reconfigure UniFlash but it should get working again.
43
+
UniFlash may get stuck sometimes and throw errors. In such cases, navigate to session on the top red bar and start a new session. You will have to reconfigure UniFlash but it should start working again.
41
44
:::
42
45
43
-
### Accessing UART (WIP)
44
-
This is an important skill everyone should know just for debugging.
46
+
### Accessing UART
47
+
This is an important skill everyone should know just for debugging. We will go through the process for Windows and Linux.
45
48
46
-
### Flashing Via the Bootloader (WIP)
49
+
#### Pre-requisites
50
+
Both Linux and Windows have a program called `puTTY` available to download. `puTTY` is a great program to detect serial activity on ports so make sure you download this before proceeding!
51
+
52
+
1. Download and open `puTTY`. You should be greeted with the following screen...
53
+
54
+
55
+
2. Under the `Connection Type:` section, select the `Serial` option which should make `puTTY` show the following.
56
+
57
+
58
+
59
+
3. You can set the speed to `115200` which is the baud rate at the time of writing this tutorial (August, 2025). Update this rate if the baud rate of the board is increased!
60
+
4. If you know how to detect what USB port is connected to UART you can type that USB port into the `Serial line` field in `puTTY`. If you need help, read through the following sections!
61
+
5. You can then press the `Open` button and there should be a black screen that starts printing out text sent by the board!
62
+
63
+
#### Finding USB port on Linux
64
+
On Linux the port name will be in the form of `/dev/tty*`. For example the port could be named `/dev/ttyACM0` or `/dev/ttyUSB0`. To find the port connected to the board do the following...
65
+
1. Open up a terminal without the board connected and type in the following command that will list out all file paths starting with `/dev/tty`
66
+
```shell
67
+
ls /dev/tty*
68
+
```
69
+
2. Now connect the board and repeat the same command.
70
+
3. Look for differences in outputs between running the command before and after connecting the board. The `/dev/tty` file path that gets added the second time around is the port that your board is connected on!
71
+
4. You can type the name of the port you have determined to be going to the board in the `Serial line` field in `puTTY`. If you are using JTAG and have to connect two USBs to your Linux system, you will have to experiment and see which port outputs logs on puTTY.
72
+
73
+
#### Finding USB port on Windows
74
+
On Windows the port name will be in the form of `COMXX` with `XX` denoting numbers. For example possible port names are `COM1`, `COM12`, etc. To find the port connected to the board do the following...
75
+
1. Open `Device Manager` and you should be greeted with the following (the image is taken off the web so your window may look a bit different)...
2. Under `Ports` try to find the COM port labelled with `UART` somewhere in it's name. Once you have found it that is the COM port you will be using in`puTTY`.
78
+
79
+
### Working with USB on WSL (WIP)
80
+
81
+
### Flashing via the bootloader (WIP)
47
82
1. Use UniFlash to flash the `OBC-bl.out` file, ensuring you have built it for the correct board using the right argument for the `-DBOARD_TYPE=` option.
48
83
2. From the root directory activate the python virtual environment with the following command
49
84
@@ -54,11 +89,15 @@ This is an important skill everyone should know just for debugging.
54
89
```shell
55
90
cd obc/tools/python/
56
91
```
57
-
4. Run the app `app_update.py` script specifying a usb port and the absolute file path. The following is an example for linux.
92
+
4. Run the app `app_update.py` script specifying a USB port and the absolute file path. The following are some examples.
The bootloader sends messages through the UART port so if the first string that the script displays is not 'Erase Successful' or the script is takes more than 1 second to start, re-run the script.
101
+
The bootloader sends messages through the UART port so if the first string that the script displays is not 'Erase Successful' or the script is takes more than 1 second to start, re-run the script. Hopefully this is addressed in the future!
63
102
:::
64
103
5. Wait for the script to flash and the board should jump to app within 2 seconds of when flashing is completed. If not check the error that is being logged to UART and try again!
Copy file name to clipboardExpand all lines: docs/src/content/docs/getting-started/cmake-options.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title: CMake Options Guide
2
+
title: CMake options guide
3
3
description: Some useful options and options that we have defined
4
4
---
5
5
The following is a list of options along with their brief description. The guide is divided into most used and extra for convenience. You can go to the end of this page for examples on how to chain these options together.
@@ -10,10 +10,10 @@ The following is a list of options along with their brief description. The guide
10
10
If an argument is marked as **Default**, it will be the default argument that is used if the option is not specified. If there are no arguments marked as default then nothing will happen.
11
11
:::
12
12
13
-
## Most Used Options
13
+
## Most used options
14
14
These are options that you will frequently be using while compiling. **Unless otherwise specified these options are to be use within the `build_arm` directory of the project**
15
15
16
-
### `-DCMAKE_BUILD_TYPE=` (Can be used in directories other than `build_arm`)
16
+
### `-DCMAKE_BUILD_TYPE=` (can be used in directories other than `build_arm`)
17
17
This specifies what the current build directory is for. You can pass either of the **four** arguments into this command...
18
18
*`OBC`: Used to build for the board (use in the `build_arm` directory)
19
19
*`GS`: Used to build code for the ground station (use in the `build_gs` directory)
@@ -27,7 +27,7 @@ This option specifies the board that the binary is being built for since differe
27
27
*`OBC_REVISION_2`: Build the files for the second revision of the OBC
28
28
29
29
30
-
## Extra Options
30
+
## Extra options
31
31
32
32
### `-DDEBUG`
33
33
If specified, this removes all optimization flags to debug. Sometimes optimizations can interfere with critical code but, first check your code's logic before using this option.
description: How Orbital Organizes Files in their Repository.
2
+
title: The file structure explained
3
+
description: How Orbital organizes files in their repository.
4
4
---
5
5
UW Orbital's Firmware Repository is quite large. As a result the previous leads have constantly refactored it to where it is now. So let's go through it! This write-up will only provide a brief overview. Consult other places in the documentation for more detailed explanations.
0 commit comments