2018-12-03 18:40:57 +01:00
|
|
|
README
|
|
|
|
======
|
|
|
|
|
2019-01-19 17:31:06 +01:00
|
|
|
This directory holds NuttX board support for the TI LaunchXL-CC1312R1.
|
2018-12-03 18:40:57 +01:00
|
|
|
|
|
|
|
Contents
|
|
|
|
========
|
|
|
|
|
|
|
|
o Status
|
|
|
|
o Serial Console
|
|
|
|
o LEDs and Buttons
|
2019-01-23 16:04:19 +01:00
|
|
|
o Version 1 or 2?
|
2019-01-24 21:55:44 +01:00
|
|
|
o Running from SRAM
|
2019-02-10 18:20:23 +01:00
|
|
|
o Using J-Link
|
2018-12-03 18:40:57 +01:00
|
|
|
|
|
|
|
Status
|
|
|
|
======
|
|
|
|
|
|
|
|
2018-12-03: Fragmentary board support in place. The initial intent
|
|
|
|
of this board support is simply to assist in the CC13xx architecture
|
2019-01-23 16:04:19 +01:00
|
|
|
development. Serious board development will occur later. Board
|
|
|
|
support is missing LED and button support.
|
2019-02-10 18:20:23 +01:00
|
|
|
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?
|
2018-12-03 18:40:57 +01:00
|
|
|
|
|
|
|
Serial Console
|
|
|
|
==============
|
|
|
|
|
|
|
|
The on-board XDS110 Debugger provide a USB virtual serial console using
|
|
|
|
UART0 (PA0/U0RX and PA1/U0TX).
|
|
|
|
|
|
|
|
LEDs and Buttons
|
|
|
|
================
|
|
|
|
|
|
|
|
LEDs
|
|
|
|
----
|
|
|
|
|
2019-02-10 18:20:23 +01:00
|
|
|
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.
|
2018-12-03 18:40:57 +01:00
|
|
|
|
|
|
|
Buttons
|
|
|
|
-------
|
|
|
|
|
2019-02-10 18:20:23 +01:00
|
|
|
The LaunchXL-CC1312R1 has two push-puttons:
|
|
|
|
|
|
|
|
DIO13_BTN1 SW1 Low input sensed when depressed
|
|
|
|
DIO14_BTN2 SW2 Low input sensed when depressed
|
|
|
|
|
2019-01-23 16:04:19 +01:00
|
|
|
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.
|
|
|
|
|
2019-01-24 21:55:44 +01:00
|
|
|
Running from SRAM
|
|
|
|
=================
|
2019-01-23 16:04:19 +01:00
|
|
|
|
2019-01-24 21:55:44 +01:00
|
|
|
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.
|
2019-02-10 18:20:23 +01:00
|
|
|
|
|
|
|
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).
|