Part Number: CC1310
Tool/software: Code Composer Studio
I have a problem loading my FW using CCS on one board with CC1310F128RHB.
I'm able to load the code when the flash is completely erased. And I can read the following messages:
Cortex_M3_0: Writing Flash @ Address 0x00000000 of Length 0x00007c00
Cortex_M3_0: Loading flashloader to target: FlashLoaderCC26x0.out
Cortex_M3_0: Chunk 1: addr=0x00000000, length=4096, crc=0x18A29E37 (using block 0)
Cortex_M3_0: Chunk 2: addr=0x00001000, length=4096, crc=0xBBDF133B (using block 1)
Cortex_M3_0: Chunk 3: addr=0x00002000, length=4096, crc=0x51FD50FE (using block 0)
Cortex_M3_0: Chunk 4: addr=0x00003000, length=4096, crc=0x0F08CF2E (using block 1)
Cortex_M3_0: Chunk 5: addr=0x00004000, length=4096, crc=0x1E712C5A (using block 0)
Cortex_M3_0: Chunk 6: addr=0x00005000, length=4096, crc=0x3C2CEA1F (using block 1)
Cortex_M3_0: Chunk 7: addr=0x00006000, length=4096, crc=0x264C4B14 (using block 0)
Cortex_M3_0: Chunk 8: addr=0x00007000, length=3072, crc=0xA246B145 (using block 1)
Cortex_M3_0: Writing Flash @ Address 0x00007c00 of Length 0x000036f0
Cortex_M3_0: Chunk 1: addr=0x00007C00, length=4096, crc=0x0BB1646B (using block 0)
Cortex_M3_0: Chunk 2: addr=0x00008C00, length=4096, crc=0xEEA8EA62 (using block 1)
Cortex_M3_0: Chunk 3: addr=0x00009C00, length=4096, crc=0x612228DB (using block 0)
Cortex_M3_0: Chunk 4: addr=0x0000AC00, length=1776, crc=0xF0C9E992 (using block 1)
Cortex_M3_0: Writing Flash @ Address 0x0001ffa8 of Length 0x00000058
Cortex_M3_0: Chunk 1: addr=0x0001FFA8, length=88, crc=0x6A7E1EBF (using block 0)
If the flash is not erased, if I try to load the FW again I'm not able to do that and I get the following messages:
Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Cortex_M3_0: Flashloader: Verbose output enabled.
Cortex_M3_0: GEL Output: Board Reset Complete.
Cortex_M3_0: Target timed out! (Block 4096)
Cortex_M3_0: Status 0xFFFFFFFF: Target flashloader has not returned any status. Unknown error!
Cortex_M3_0: Command=20 -- addr=0x00002000 -- length=0x00001000
Cortex_M3_0: File Loader: Memory write failed: Timed out waiting for target flashloader to execute command.
Cortex_M3_0: GEL: File: C:\Projects\IRSAP\project\workspace_ti_ccs\rfIrsapNow20Cu\Now20Cu_DeltaType\rfIrsapNow20Cu.out: Load failed.
If I erase the flash using Flash Programmer 2, I can load the FW again.
I read that other people had the same problem, but I can't understand if there is a reason and a solution or not.
Thanks in advance for your help, Andrea Sironi.
Interesting; in CCS, are you using the option to erase all unprotected sectors on the Flash options of your project?
Check section 7.2.3 to learn how to access the project debug roperties and section 7.5.5 for the flash options on the CCS User's Guide at:
Hope this helps,
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to desouza:
sorry for the late of my answer.
I really have the Program Load Settings as Necessary Sectors Only (Retain untouched content within Sector).
I want to tell you that I have more prjects for more different HW and this configuration is the same for all the project.
I have also verified another thing: after I have loaded the code, now I need to execute a Forced Mass Erase, otherwise I'm not able to take the control of the device anymore. Smart RF Flash Programmer messages are:
>Initiate access to target: XDS-L2000J7M using 2-pin cJTAG.
>Create XBAL object failed: Debug interface is locked.
>XBAL EB pointer is null.
>Failed to create device object.
I must investigate about this, have you got any suggestion? Thanks, Andrea
In reply to Andrea Sironi:
I am unsure what may be causing this issue, but usually when you are forced to erase the existing code ont he device is due to a problem on the code itself; that tends to happen when the processor is put to run in a very tight loop or it continuously resets itself, leaving no time for the Debug Probe to regain control of the device. You can validate the stability of your development environment by loading an example code from the Simplelink SDK and see if all the actions are stable.
In this case, can you see if you enable the vector catch breakpoints of the ARM Advanced Features section? Check the post below for details about this.
That will allow you to "trap" the processor in case an exception happens and hopefully allow you to get an idea on where the code went wrong.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.