CC3220SF-LAUNCHXL: OOB application always starts up after reset or PUR, when new project code flashed

Hi David,

Thanks for your question. Please allow us some time to provide you with an answer.

David,

When flashing the device using debug mode the application is loaded to the internal flash. The default operation for the SF device after power reset is to overwrite internal flash with the application on external flash. One solution is to flash a blank image to the external flash enabling the device to run from internal flash.

Another option is to include the __SF_DEBUG__ section of code which changes the default operation to run directly from internal flash.

Hi Austin

I understand your suggestions, but can you give me an idea of how I can do this, I am familiar with CCS, but new to the SimpleLink environment, and Uniflash. My TI-RTOS code works OK under debug as per the log, however I need to understand how to create and program a blank image to the external flash. Please can you help me as I can't see any instructions on this in the Uniflash guide, or means of doing it from CCS.

I could also include the __SF_DEBUG__ section of code, but again I'm not sure where to find how to do this.

I will try these and report back, if you can supply a bit more information to help.

I now have several CC3220SF LAUNCHXL EVK's that need programming for an IoT MQTT sensor demonstration where my code needs to remain in the internal flash to run. The EVK's all run with external I2C sensors from TI, this part works.

I have seen two E2E forum entries that mention a similar problem "CC3220SF-LAUNCHXL: network_terminal project debug issue"  the entries suggest that you enable __SF_DEBUG__ and use a line --retain ulDebugHeader in the linker build option. I have tried this by putting #define __SF_DEBUG__ in the CC3220SF_LAUNCHXL.h file, then placing --retain ulDebugHeader  in the the following property:

CCS Build/ARM Linker/Advanced Options/Symbol Management - Specify symbols/sections to be retained by linker (--retain).

This now produces a project with the debug header seen in the .map file:

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.dbghdr    0    01000000    0000000c     
                  01000000    0000000c     CC3220SF_LAUNCHXL.obj (.dbghdr)

.binit     0    01000000    00000000     

.resetVecs
*          0    01000800    0000003c     
                  01000800    0000003c     release_pem4.oem4 (.resetVecs)

.text      0    01000840    0001475a     
                  01000840    00001122     rtsv7M4_T_le_eabi.lib : _printfi.obj (.text)
                  01001962    00000002     drivers_cc32xx.aem4 : I2CCC32XX.oem4 (.text:I2CCC32XX_cancel)
                  01001964    00000680     simplelink.a : driver.obj (.text:_SlDrvMsgRead)
                  01001fe4    0000042c     driverlib.a : prcm.obj (.text:PRCMCC3200MCUInit)
                  01002410    00000424     mqtt_client_app.obj (.text:mainThread)
                  01002834    00000380     simplelink.a : driver.obj (.text:_SlDrvMsgWrite)
                  01002bb4    0000033c     client_cbs.obj (.text:MqttClientCallback)
                  01002ef0    00000320     network_if.obj (.text:Network_IF_ConnectAP)
                  01003210    000002dc     simplelink.a : driver.obj (.text:_SlDrvRxHdrRead)
                  010034ec    000002bc                  : sl_socket.obj (.text:sl_Select)

......

**********************

The problem remains in that the programmed image reverts to the OOB factory application on the CC3220SF_LAUNCHXL after reset or PUR.

I think I still have a serious issue with the /sys/mcuflashimg.bin file for the factory image being copied over the flash section that CCS V7.2 is writting to. Can someone explain in detail how I can stop this.

Regards David

Hi David,

It sounds like you are on the right track.  I'm not sure right now why it isn't working for you after following the steps outlined in the thread below.  I can take a look into this and get back to you.

In the meantime, using Uniflash please try to flash the CC3220sf device in development mode with just the certificates and service pack files.  Do not include an application.  Then, try to rerun your debug application and verify if this changes the outcome.

Hi Austin

We still have a serious issue somewhere!

Debug and reset issues with CC3220SF LAUNCHXL and CCS V7.2.0.00013

Code programmed is now the stock i2ctmp006_CC3220SF_LAUNCHXL_tirtos_ccs project
This project behaves exactly the same with debug header enabled or disabled in CC3220SF_LAUNCHXL.h
It compiles and programms properly, and also runs properly reporting temperature to the PC via the back channel UART, until reset.

I have programmed the CC3220SF_LAUNCHXL flash via Uniflash with a blank project (no user program file) with sp_3.4.0.0_2.0.0.0_2.2.0.5.bin service pack and default Trusted Root-Certificate Catalog. Other settings were:

Development Mode General->Settings page

Image Mode - Development
Original MAC Address - As board reports on connect
Capacity - 4M BYTE (reported, with "Check device size" greyed out)
Secured Device - True
Target Device - Production Device
Restore To Factory Image SOP - Disabled
Restore to Factory Configuration - Defaults Only
Use dvice MAC Address - ticked

RESET is where ALL the problems occur, as CC3220SF_LAUNCHXL stops working every time, the project will also not reset through CCS control. No breakpoints were set during debug or prior to launch of debug.
I get the following message in the console when the CC3220SF_LAUNCHXL reset button is pressed:

**************************
Cortex_M4_0: GEL Output:
Memory Map Initialization Complete
Cortex_M4_0: GEL Output:
Target Reset
CS_DAP: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 7.0.48.0)
Cortex_M4_0: JTAG Communication Error: (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)
Cortex_M4_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
**************************

NOTE reseting the emulator before connecting and reloading the program does NOT help, it still behaves the same every time.

UART log: (some blank lines removed)

**************************
Data received: Starting the i2ctmp006 example

I2C Initialized!

Sample 0: 25 (C)

Data received: Sample 1: 25 (C)

Data received: Sample 2: 25 (C)

Data received: Sample 3: 25 (C)

Data received: Sample 4: 25 (C)

Data received: Sample 5: 25 (C)

Data received: Sample 6: 25 (C)

Data received: Sample 7: 25 (C)

Data received: Sample 8: 25 (C)

Data received: Sample 9: 25 (C)

// ************** CC3220SF_LAUNCHXL - Manual reset here ********** //
// program should start again with first message, but never does //

The CC3220SF_LAUNCHXL reset button does not work as the code does not restart the program loaded from CCS, now that the blank program has been loaded to flash with Uniflash it no longer starts the OOB project upon reset.

Every time code is reset in CCS, the debug window reports "0x0000EB30 (no symbols defined)"

0000eb22: 4402 add r2, r0
0000eb24: 0020 movs r0, r4
0000eb26: 0000 movs r0, r0
0000eb28: 1000 asrs r0, r0, #0x20
0000eb2a: 4402 add r2, r0
0000eb2c: 0008 movs r0, r1
0000eb2e: 0000 movs r0, r0
0000eb30: F24F00C8 movw r0, #0xf0c8 /* STOPS HERE ON RESET IN CCS with message - No source available for "0xeb30"*/
0000eb34: F2C44002 movt r0, #0x4402
0000eb38: 6800 ldr r0, [r0]
0000eb3a: F3C01042 ubfx r0, r0, #5, #3
0000eb3e: 2800 cmp r0, #0
0000eb40: F47DACB8 bne.w #0xc4b4
0000eb44: F24D000C movw r0, #0xd00c
0000eb48: F2C44002 movt r0, #0x4402

Because I am now using a standard example project this can be easily simulated at TI.

All the versions of applications I have in CCS to load onto the CC3220SF_LAUNCHXL exhibit the same problems.

Please can you help me past this problem as I have a demonstration to perform in a couple of days time.

Regards David

Hi David,

I've found your mistake with the method of defining  __SF_DEBUG__ .  As you mentioned:

I have tried this by putting #define __SF_DEBUG__ in the CC3220SF_LAUNCHXL.h file, then placing --retain ulDebugHeader (wrong) in the the following property:

CCS Build/ARM Linker/Advanced Options/Symbol Management - Specify symbols/sections to be retained by linker (--retain).

This now produces a project with the debug header seen in the .map file:

In the same project property (Symbol Management-->Specify symbols/sections to be retained by linker (--retain)), type the following:

ulDebugHeader

Please let me know if this works for you.  I have verified that it works on my setup.

The SOP configuration 010 matches my configuration. Which version of the SDK did you use? I am using simplelink_cc32xx_sdk_1_40_01_00 inside the provisioning example. It may be best to reinstall the SDK and start fresh if there have been many modification made.

Can you attach a copy of the .map file?

Hi Austin

Take a look at my modified post above, think the issue is resolved, just need check same procedure on our custom mqtt client project. If so we are resolved.

Thanks David

Hello David,

         I followed the procedure of flashing blank project in uniflash utilty  given by you and it worked as after reset out of the box application did not run.

         But when I started flashing other programs in CCS, (Eg. Timerled) it is not running after reset. Have you achieved it with CCS ?

Regards,

Omkar