Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
Checklist for Processor SDK RTOS questions on E2E
When posting RTOS questions to the TI e2e forums here are some recommendations on information that you need to provide so that we can help you debug the issue.
- 1 Information to provide in initial E2E post:
- 2 Debugging Build issues
- 3 CCS related issues
- 4 Custom board related issues
- 5 TI RTOS related questions
- 6 Specific peripheral and module related issue
Information to provide in initial E2E post:
When working with Processor SDK RTOS , it is important that you work with the versions of tools and dependencies that are recommended in the Release notes of Processor SDK RTOS version that you have specified. Hence it is critical for us to know
- EVM Hardware used for the debug ??
- Host Environment Linux or Windows ??
- Processor SDK RTOS version ??
- Code composer Studio version ??
Debugging Build issues
Most Build issues related to Processor SDK RTOS are related to issue with host setup or due to working with incorrect version of build tools. Starting with Processor SDK RTOSv3.3, we plan to have Compiler tools packaged as part of the Processor SDK.
- Please provide a log or screenshot of command line when you run setup.bat provided in Root directory of Processor SDK RTOS. Check the log to see if all those paths exist on your host machine.
- Provide the log of the build error when you encounter and steps by which we can reproduce the error.
Setup and script issue
As indicated earlier CCS is not part of the Processor SDK RTOS package but a separate IDE tool to help debug issues while building RTOS application. TI typically only validate a version of Processor SDK RTOS with a single version of CCS specified in the Release Notes. We recommend that you use that version of the tool so that the CCS projects and builds work as advertised in the documentation.
- Provide a snapshot of the setup.bat and confirm that all paths setup by the script are available on the host.
- Before building CCS projects using Processor SDK RTOS, make sure that the components are discovered in the CCS as described here:
Emulation Related issues with TI EVM
Processor SDK RTOS is supported on all TI Processor EVMs which have different on board and external Emulation requirements so please follow the instructions provided in [Hardware User guide and Hardware setup guides http://processors.wiki.ti.com/index.php/Processor_SDK_Supported_Platforms_and_Versions]
- Indicate which wiki was referred to setup the EVM and which step is not working as expected.
- Provide Emulator version used, Host Setup and CCS version used.
- Provide relevant Hardware settings like jumper settings, boot switch settings etc.
TI supports and provides guidance in porting Processor SDK RTOS to Custom board. However debugging issues on custom hardware are more involved as we don`t have access to the modified software and hardware. It will help us immensely if you can provide the following information.
- How is your EVM hardware different from TI supported platform for the processor in question.
- What changes have been made to software to meet the differences in hardware.
- Is there a way TI can reproduce the issue. For eg is there any other processor in the device family with similar interface that you are aware of.
- Provide information on diagnostics that you may have used to check that the hardware changes are connected as expected. For example in devices that support pin multiplexing, you can configure pins as GPIO and toggle pins.
- share any clock or electrical scope observations if there are any.
TI RTOS OS related questions can vary as there are several modules supported in the OS. All of the TI RTOS configuration is brought together in the application using a .cfg file associated with the projects. We recommend that you provide the following information.
- Please attach your .cfg file so that we can understand the features that are enabled and associated configuration.
- If you are using UIA then please provide the SYSBIOS logs (system_printf) for us to understand the code flow or error reported.
- If the RTOS application fails due to a stack over flow or internal error, it dumpes the core registers for analysis with an error code. Please provide this log.
Different peripherals and Boot modes require different set of information to analyze. In some cases we provide Debug GEL files, Gels to capture registers and other tools and utilities that help us debug the issue.
The ROM boot loader on the device is a black box to the end user so it usually generates a lot of questions. Here are some tools that you can use to provide us information when you run into issues.
- Please provide Boot Mode Pin settings. This is referred to as SYSBOOT pins on SITARA devices and DEVSTAT BOOTMODE[15:0] on Keystone devices. This helps us understand many things about how the ROM bootloader views the initialization parameters for the SOC.
- If the device doesn`t boot using the instructions provided by the SOftware USer guide, connect to the device using an emulator and provide value of the Program Counter(PC). This helps us look up the location of the hang using the ROM symbol table.
- In many cases, we provide a Debug GEL file that can be run using CCS that captures system clock configuration, device state, boot mode pins etc. Here are some Gel files that you can run when the boot fails.
- Keystone I device Debug GEL file
- OMAPL137 Debug GEL file
- If you are using secondary bootloader (SBL), indicate the changes that you have made or the instructions you followed.
- Let us know if you have run any diagnostic tests if you have to confirm that the interface with the boot media is correct.
- Describe any other symptoms that may be relevant or any pattern you may have observed with respect to the boot mode. Eg : Fails at a given temp, fails on small subset of boards, fails x% times.
Serial IO drivers
Processor SDK RTOS provides drivers for serial IO peripherals like GPIOs, I2C, UARTs etc. Theses drivers are built to be use in both bare-metal and TI RTOS environment and are designed to be compatible across all TI platforms including the TI MCU devices.
- TI recommends use of these driver in application development.
- TI support can`t scale to support custom driver development. Custom code on custom platforms can`t be supported across a large user base.
- If custom drivers can`t be avoided and support is required then please allow for sufficient time and provide clear instructions on how to setup the code on TI platform.
- Bit banging and creation of register level defines is not supported. TI recommends use of TI functional and register CSL
McASP is the audio peripheral used on many devices that are supported by Processor SDK RTOS. The peripheral can be configured in various different configurations and supports wide variety of clocking settings. To debug McASP related issue, we usually expect the following information in your e2e posts.
- Please describe your hardware setup when testing the McASP driver.
- Is the McASP the clock master or clock slave
- What ADC is interfaced with the McASP and what Oscillator crystal has been used to get to required sampling rates.
- Which McASP Serializers pins are used
- MCASP mode settings
- Is the McASP in synchronous mode or asynchronous mode?
- TDM Configuration settings: What is the number of slots and wordlength used?
- How is the bit rate(XCLK and RCLK) and frame syncs configured.
- McASP driver configuration:
- What is the buffer format used?
- Channel configuration in case of multi-channel input.
- Is FIFO and EDMA enabled.
- McASP Error registers:
- Report Frame Sync, Overrun, under run errors