or it might look like this blank version at first:
or
or it might look more like this:
- The Debug Button will have become the Stop button. You can then press the Stop button to exit Debug mode.
Tips for TI Board and CCS
If you're using an SDK version greater than 4.40, you'll likely see uartecho2 rather than uartecho. In order to get uartecho, please do ensure you're using a lower SDK (like 4.30.00.06 added above) and then you'll see the uartecho project, as seen in the image below:
Most personal computers have an operating system that maintains central control; it executes programs by giving them momentary control and then resumes control when the program ends. Most embedded microcontrollers, however, don't have a central operating system.
There are two common models in embedded systems: using a "super loop" or using a Real Time Operating System (RTOS). In the super-loop model, there is a main loop which is an infinite loop and, once initialization is complete, the program loops indefinitely, servicing various functions.
You can read more about "The 'Super Loop' Architecture for Embedded C programming" here: https://www.includehelp.com/c/the-super-loop-architecture-for-embedded-c-programming.aspx
This is usually implemented as a while loop using a while(1) type construct. Since many embedded systems are event driven, they wait for events to indicate something has happened. These events are usually handled by hardware interrupts.
In such super-loop systems, also called bare-metal systems, every task is coded inside the infinite loop except the interrupts. Thus, an embedded system microcontroller like this will execute each task in its infinite loop sequentially until there is an interrupt event.
You can read more about "Bare-metal and RTOS Based Embedded Systems" here: https://microcontrollerslab.com/difference-bare-metal-and-rtos-based-embedded-systems/
The timer, on the other hand, is going to be globally watching over the whole system to check for interrupts (e.g., you pushing one of the physical buttons).
The timerCallback() is used as the timer interrupt callback
function and is set via params.timerCallback = timerCallback;.
It will be called every time the timer
reaches the countdown set with params.period. Code can be added here
for anything that needs to be done on a regular interval or after a
certain amount of time.
In general, the firing of the abstract timer button for this global timer is decided by the timer flag. First, a global (volatile) variable is set to FALSE, which says the abstract button is off. Then, when the callback function is executed, the abstract "button" is set to on by setting the TimerFlag variable to TRUE. At the end of the switch statement, the timer is set back to OFF, so that this cycle can continue.
If you get an error for the TimerFlag's call complaining about it being undefined, then it was probably not declared as volatile. The TimerFlag needs to be initialized early on as a volatile variable. This should look something like this:
volatile unsigned char TimerFlag = 0;
This initializes the TimerFlag to false. Then, in the callback function, the TimerFlag volatile variable should be set to true, which will then tell the timer to start monitoring interrupts. Remember, you can directly use bool values (preferred via the stdbool.h header), or the integer values of 1 and 0, to set a variable to true or false.
In addition, if you add actual hardware control code directly to the callback/interrupt (like readTemp()), it might cause problems like not being able to read more than a single value or the system hanging on the interrupt; as such, it's better to have the timer dedicated to setting a timer flag and then having your main control/implementation code called from main() while loop that checks the timer flag.
Here are some additional helpful links about embedded systems and super-loop approaches:
And here is a great resource for learning more about
timers:
https://embeddedinventor.com/embedded-timers-their-types-and-applications/
If you're on a Linux or Mac system, you can identify your COM port by doing the following:
ls /dev/tty*
which should give you something like this:
Once you connect your board and load the drivers for the COM port, it should show you the additional ports, as follows:
You might have to guess which port is the correct one but it should be one of the two new ports; e.g., it is the usbmodemE00810101 above in this case. You can use the Debug mode again for the Serial COM Port component in the uartecho project:
This will then let you use the Target → Connect COM port, as follows:
You can then use one of the following approaches to print to the console:
printf() along with Debug to see the outputputs() along with Debug to see the outputTarget → Connect COM Port as above to
connect a COM port and then use either UART_read()/UART_write()
directly or via Debug using either printf() or puts() to
output and read from that COM port
In general, in order to debug to the console, you can:
int foo = 5; char pid[20]; sprintf(pid, "data: %d\n", foo); puts(pid);or
int foo = 5;
printf("Got: %d\n", foo);
You can also use the UART to do so as above, of course.
If you're having issues with printing to the console, I'd recommend doing the simple puts() example here:
Tips for Using Printf: What is C I/O?: Getting C I/O working / Troubleshooting
I'd also recommend checking the stack and heap sizes, etc., as mentioned here:
If you want to simulate the return key, on the TI Boards, it seems to be '\r' whereas, on other boards, it's different. E.g., on the stm32 nucleoboards, it seems to be '\0':
If you run into issues with the board itself, here are some troubleshooting steps that might prove helpful:
In general, you can try the above nominal fixes but, if they don't work, I'd recommend contacting TI Tech Support before attempting more significant hardware manipulations as some changes might render the board unusable.
Finally, if you receive the dreaded, "Error connecting to the target: (Error -1170)" and get the "Unable to access DAP" error, a simple fix might be to downgrade your CCS SDK to a version below 4.40. Starting with CC32xx SDK 4.40, SysConfig ImageCreator support was added in to give the same ImageCreator functionality from the UniFlash tool but if there's a misconfiguration or an issue with it, you can exclude image.syscfg from the build or, to make the change permanent and keep the newer version of the CCS, you can go to the project properties and switch from the MCU+Image to the Debug build configuration, as well. The .cfg contains the configuration for TI-RTOS while the .syscfg has configuration for drivers and some software stacks.
I might recommend ensuring the board is still in a stable state, as well, though. In general, the SOP should be in 010 but it's possible the board came mis-configured or there was another hardware issue. In our class, we don't change the hardware components, other than pressing buttons on the board, so I'd highly recommend contacting the TI Tech Support (you can chat with them 24/7 via chat or email) and they can either help zero in on the issue or replace the board, as needed (I know others in our class had to have their boards replaced this term, as well)!
Once you install CCS and import the pwmled2 project, you should ensure your board works and can connect to CCS. If you instead receive an error, perhaps like 'SC_ERR_PATH_BROKEN', you should call TI customer support and, if they can't help fix it, then it's likely due to a broken board which needs to be replaced.
Once the board is connected and runs the test program, you can start to make changes. If, after making changes, you get an error like:
Error connecting to the target:
(Error -1170 @ 0x0)
Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 7.0.48.0)
This error usually indicates that communication was lost between the IDE and the microcontroller. This likely happens with the pwmled2 program as it has an infinite while loop so if you make a change, you have to first stop the board or reset it. In addition, if you use Debug, you have to ensure you're stopping that, as well.
Here are some troubleshooting steps to help; please try to:
In general, you can try the above nominal fixes but, if they don't work, I'd recommend contacting TI Tech Support before attempting more significant hardware manipulations as some changes might render the board unusable.
The other things to try (with great care!) are as follows:
Nota Bene: although the SOP should, in general, be in 010 it's possible the board came mis-configured or with another hardware issue. In our class, we don't change the hardware components (other than pressing buttons on the board) so I'd highly recommend contacting the TI Tech Support (you can chat with them 24/7, I believe) and they can either help zero in on the issue or replace the board, as needed (I know others in our class had to have their boards replaced this term, as well)!
