nuttx/configs/launchxl-cc1312r1/README.txt
2019-02-10 11:20:23 -06:00

134 lines
5.1 KiB
Plaintext

README
======
This directory holds NuttX board support for the TI LaunchXL-CC1312R1.
Contents
========
o Status
o Serial Console
o LEDs and Buttons
o Version 1 or 2?
o Running from SRAM
o Using J-Link
Status
======
2018-12-03: Fragmentary board support in place. The initial intent
of this board support is simply to assist in the CC13xx architecture
development. Serious board development will occur later. Board
support is missing LED and button support.
2019-02-10: Figured out how to connect J-Link and began debug. First
failure is in tiva_configgpio() while trying to configure the console
UART pins. The failure is a hardfault apparently generated by:
109 regval = getreg32(TIVA_GPIO_DOE);
The GPIO base address and DOE register offset seem to be okay. Must
be some issue with powering up the GPIO? The TI code calls Power_init()
which has not yet be brought into NuttX. Could this be the issue?
Serial Console
==============
The on-board XDS110 Debugger provide a USB virtual serial console using
UART0 (PA0/U0RX and PA1/U0TX).
LEDs and Buttons
================
LEDs
----
The LaunchXL-cc1312R1 and two LEDs controlled by software: DIO7_GLED (CR1)
and DIO6_RLED (CR2). A high output value illuminates an LED.
DIO7_GLED CR1 High output illuminuates
DIO6_RLED CR2 High output illuminuates
If CONFIG_ARCH_LEDS is not defined, then the user can control the LEDs in
any way. The definitions provided in the board.h header file can be used
to access individual LEDs.
These LEDs are not used by the board port unless CONFIG_ARCH_LEDS is
defined. In that case, the usage by the board port is defined in
include/board.h and src/cc1312_autoleds.c. The LEDs are used to encode
OS-related events as follows:
SYMBOL Meaning LED state
GLED RLED
------------------ ------------------------ ------ ------
LED_STARTED NuttX has been started OFF OFF
LED_HEAPALLOCATE Heap has been allocated OFF ON
LED_IRQSENABLED Interrupts enabled OFF ON
LED_STACKCREATED Idle stack created ON OFF
LED_INIRQ In an interrupt N/C GLOW
LED_SIGNAL In a signal handler N/C GLOW
LED_ASSERTION An assertion failed N/C GLOW
LED_PANIC The system has crashed OFF Blinking
LED_IDLE MCU is is sleep mode Not used
Thus iF GLED is statically on, NuttX has successfully booted and is,
apparently, running normally. A soft glow of the RLED means that the
board is taking interrupts. If GLED is off and GLED is flashing at
approximately 2Hz, then a fatal error has been detected and the system
has halted.
Buttons
-------
The LaunchXL-CC1312R1 has two push-puttons:
DIO13_BTN1 SW1 Low input sensed when depressed
DIO14_BTN2 SW2 Low input sensed when depressed
Version 1 or 2?
===============
Two versions of the CC1312R1 are supported selected by CONFIG_ARCH_CHIP_CC13XX_V1
or CONFIG_ARCH_CHIP_CC13XX_V2. How can you tell which one you have?
Perhaps you can tell by the markings on the chip, but I do not have the
secret decoder ring necessary to do that.
What you can do is enable CONFIG_DEBUG_ASSERTIONS. The firmware can
determine which version you have by looking at register contents. The
firmware will assert if you select the wrong version. If that occurs,
switch to the other version and the assertion should go away.
Running from SRAM
=================
The LaunchXL-CC1312R1 port supports execution from RAM. Execution from
SRAM as a "safe" way to bring up a new board port without concern about
borking the board because of a bad FLASH image.
if CONFIG_BOOT_RUNFROMFLASH=y is set in the configuration, then the code
will build to run from FLASH. Otherwise (presumably CONFIG_BOOT_RUNFROMSRAM=y)
the code will build to run from SRAM. This is determined by the Make.defs
file in the scripts/ sub-directory. Based on those configuration
settings, either scripts/flash.ld or sram.ld will be selected as the
linker script file to be used.
Using J-Link
============
Reference https://wiki.segger.com/CC1310_LaunchPad (for CC1310)
When shipped, the TI CC1312R1 LaunchPad evaluation board is configured to be
used with the on-board debug probe. In order to use it with J-Link, the
on-board debug probe needs to be isolated to make sure that it does not
drive the debug signals. This can be done by removing some jumpers next
to the XDS110 Out / CC1310 In connector [RXD, TXD, RST, TMS, TCK, TDO, TDI,
WDO]. After isolating the on-board probe, the CC1312R1 device can be
debugged using J-Link. Please note, that the J-Link needs to be connected
to the board using the CC1312R1 using the micro JTAG connector marked
"Target In".
NOTE: When connecting the J-Link, the interface must be set to JTAG, not
SWD as you might expect.
The RXD/TXD can then be used for a Serial console using the appropriate
TTL adapter (TTL to RS-232 or TTL to USB serial).