CC3220SF-LAUNCHXL: CC3220SF: Persistence of Application Data in XiP Flash

Tom B.

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, UNIFLASH, CC3220S

Hello,

So, I'm trying to understand how the CC3220SF works with the XiP flash when debugging and running on it's own. Here's how my device is setup.

The SPI flash contains a UniFlash image that was gang programed which:
- Contains only the SL Service Pack
- Contains no MCU bin
- Configured in Development mode with the devices MAC address included
The debugging/XiP programming is occurring via the SWD flash

Powering the device up the first time, after it unpacks the gang image it does nothing. This is expected, as there's no MCU bin.

The device then can be connected to in CCS, programmed with our application code and debugged. This is also expected, as the device was in development mode.

Removing the power and repowering the device the functionality is returned to the "do nothing" functionality. It acts as there is no application.

The problem:

This is a bit unexpected, because it tells me the the CC3220 seems to be erasing the XiP which contained the application data or maybe it is ignoring the fact the XiP is still programmed. At any rate, I'm trying to understand why this is the case. Can anyone help me understand what the CC3220SF is doing at bootup that would cause it to erase/not execute the data in XiP flash? Thanks!

over 7 years ago

0 Kobi Leibovitch over 7 years ago

TI__Guru 63006 points

Hi Tom,

As part of the secure boot procedure, the bootloader will compare the version on the internal (XiP) flash with the one on the External flash.
If they are not matched (as in this case), the internal content will be formatted and the external content will be copied instead. In your case the external is empty so no image will be copied.

To avoid the check (in debug mode), you can set the "__SF_DEBUG__" definition (e.g. in project properties/Build/Srm Compiler/Predefined Symbols).
This will add an header (ulDebugHeader) to the image that will be identified by the bootloader and will instruct him to keep the current XiP flash content.

Since the ulDebugHeader is not accessed by any MCU code, it will get dropped off by the linker by default - so you need to specify the linker to retain it.
You can add the following to linker cmd file (CC3220SF_LAUNCHXL_NoRTOS.cmd):
--retain=ulDebugHeader
Or update the Retain Configuration in the project Properties/Build/ARM Linker/Advanced Options/Symbol Management/

Br,
Kobi

0 Tom B. over 7 years ago in reply to Kobi Leibovitch

Prodigy 180 points

Great, thanks for the info, Kobi! I'll give it a try and report back to mark it resolved.

Is this debug feature/functionality documented somewhere in the TI documentation that you could reference? I haven't found it anywhere so far. Thanks for your help!

-Tom

0 Tom B. over 7 years ago in reply to Kobi Leibovitch

Prodigy 180 points

Hi Kobi,

OK, so that worked.

The caveat to that is, it worked after I realized that the functionality is tied to a bit of code that's in a TI file (CC3220SF_LAUNCHXL.c) that wasn't in my project. This was found after Googling and landing in the AWS FreeRTOS repo at the mentioned file. I pulled the snipped out of the file and put it into one of my application's files.

This makes my question about documentation of the magic debug header data slightly more important to me.

Thanks again for your help, by the way.

-Tom

0 Kobi Leibovitch over 7 years ago in reply to Tom B.

TI__Guru 63006 points

For example, in the getting started guide (www.ti.com/.../swru461a.pdf) chapter 3.1.
br,
Kobi

0 Kobi Leibovitch over 7 years ago in reply to Tom B.

TI__Guru 63006 points

Where did you get the "CC3220SF_LAUNCHXL.c" from?

It was part of the files for the last couple of releases.

Have you created yours with the pinmux tool?

br,

Kobi

0 Tom B. over 7 years ago in reply to Kobi Leibovitch

Prodigy 180 points

So, if you Google ".dbghdr", which is the item in the map file that should be there after compiling, the second result (for me) is:
github.com/.../CC3220SF_LAUNCHXL.c

This is the supporting code that AWS includes in their repo for the AWS demo on the SF LP.

That was what lead me to understanding how the Predefined symbol actually caused the desired effect.

EDIT: It actually looks like the guys from Zephyr wrote a really good comment header for it. Here's their whole file:

/*
 * Copyright (c) 2017, Texas Instruments Incorporated
 *
 * SPDX-License-Identifier: Apache-2.0
 */

/*
 * This debug header, located at the start of flash, indicates
 * to the bootloader that this is a debug image, allowing
 * debuggers and flash-loaders to access the chip over JTAG.
 * Also, on subsequent reboots, the bootloader skips the integrity
 * check, preventing the image from being mass erased.
 *
 * See section 21.10: "Debugging Flash User Application Using JTAG"
 * in the CC3220 TRM: http://www.ti.com/lit/ug/swru465/swru465.pdf
 */
#ifdef CONFIG_CC3220SF_DEBUG
__attribute__ ((section(".dbghdr")))
const unsigned long ulDebugHeader[] = {
	0x5AA5A55A,
	0x000FF800,
	0xEFA3247D
};
#endif

So it looks like the real reference is Section 21.10: "Debugging Flash User Application Using JTAG" in the CC3220 TRM: http://www.ti.com/lit/ug/swru465/swru465.pdf

0 Tom B. over 7 years ago in reply to Kobi Leibovitch

Prodigy 180 points

Have you created yours with the pinmux tool?

Good question. No, we actually started with a CC3220S and have decided that the SF may be the better path. So we have started off using a lot of the CC3220S related files from the LP demos. So our CC3220S_LAUNCHXL.c file didn't contain the SF specific debug header snippet.

0 Kobi Leibovitch over 7 years ago in reply to Tom B.

TI__Guru 63006 points

Ok. This explains the issue.

Br,
Kobi

0 Tom B. over 7 years ago in reply to Kobi Leibovitch

Prodigy 180 points

Thanks for the help Kobi. Your quick responses are great!

If it's OK with you, I'm going to write up a summary of how to solve this issue in a reply at the bottom of this thread so the solution can be all in one place. I think your original comment captures most of the solution, but the caveat being the snippet of code I was missing in my application and the reference to the SWRU 465 document for the magic header data.

Thanks again,

-Tom

0 Tom B. over 7 years ago in reply to Tom B.

Prodigy 180 points

So,

The resolution of this issue is "put some debug data at the beginning of the application data space and the secure boot loader will leave the XiP alone".

The reference document that gives this is Section 21.10: "Debugging Flash User Application Using JTAG" in the CC3220 TRM

The TI way to implement the inclusion of this data is to do the following:

Include the below snippet of code into your application that contains the data
Define the symbol "__SF_DEBUG__" in the Predefined Symbols section of the Project Properties (Project Properties/Build/Arm Compiler/Predefined Symbols)
Add the switch "--retain=ulDebugHeader" to the Linker file so that it doesn't eliminate the data when linking, because it's not used

/*
 * Debug functionality for the CC3220SF Module
 *
 * This debug header, located at the start of flash, indicates
 * to the bootloader that this is a debug image, allowing
 * debuggers and flash-loaders to access the chip over JTAG.
 * Also, on subsequent reboots, the bootloader skips the integrity
 * check, preventing the image from being mass erased.
 *
 * See section 21.10: "Debugging Flash User Application Using JTAG"
 * in the CC3220 TRM: www.ti.com/.../swru465.pdf
 */
#if defined(__SF_DEBUG__)
#if defined(__TI_COMPILER_VERSION__)
#pragma DATA_SECTION(ulDebugHeader, ".dbghdr")
#elif defined(__IAR_SYSTEMS_ICC__)
#pragma data_location=".dbghdr"
#elif defined(__GNUC__)
__attribute__ ((section (".dbghdr")))
#endif
const unsigned long ulDebugHeader[] =
{
    0x5AA5A55A,
    0x000FF800,
    0xEFA3247D
};
#endif

Doing this will stop the Secure Bootloader from erasing the application in the XiP flash.

Wi-Fi

Wi-Fi forum

CC3220SF-LAUNCHXL: CC3220SF: Persistence of Application Data in XiP Flash

The problem: