Those are the correct connections.

To confirm I just setup a CC2650 LaunchPad and made those connections to my CC2640R2 LaunchPad.

I ran the Test Connection tool from inside CCS and that passed.

I then tried the pwmled example from the SDK and that worked fine as well:

Seems like there is a bad or noisy connection.

In CCS if you own the .ccxml file in your project (probably in the targetConfigs folder) you can click on the button there to test the connection and see if it gives you any more info.

Regards,

John

Hi John,

I did the same test with 2 Launchpads, like you did, and it worked fine. But when I am using my own custom made board, it still shows the DAP error. 

Testing the connection in CCS is working.

Christian

Are there any flags or register I have to set for first time flashing???

Christian,

I spoke to some people and have a couple things for you to try.

SmartRF

1. Try using SmartRF programmer to erase the flash on the device: http://www.ti.com/tool/download/FLASH-PROGRAMMER-2
2. If that is able to connect and erase the device then try connecting in CCS.

Different JTAG settings

1. Open the .ccxml file that is in your project.  Typically in the targetConfigs folder.  
2. Change the connection to be JTAG instead of cJTAG and also change the TCK to 1.0 MHz.

Save the changes and try connecting.

Regards,

John

Hi John,

thank you for your answer. I tried out your suggestions:

1. Erasing the flash with SMARTRF worked
2. I did the changes in CSS, but I still get the errors (see pic below)

I have built two of these custom boards and both have this error. 

It looks like that flashing of the chip is working, but then the CPU doesn't start.

Christian

Interesting.

Can you try the following:

1. From the View menu in CCS open the Target Configuration View
2. Find the .ccxml file that is part of your project
3. Right click on it and choose "Launch selected configuration".  This will start a debug session in CCS but won't connect to anything yet.
4. When the debug view opens click on the top level node in the tree (it will be the name of the .ccxml file).  Select "Show all cores".
5. Under "Non debuggable devices" select the one that ends in ICEPick_C.
6. Click on the connect button on the toolbar. 
7. Open the registers view.
8. If you expand core registers. Do the TAP registers have values other than 0 or 1?
9. Next select the DAP under "Non debuggable devices" and see if you can connect to that.
10. If that works can you open a memory window and see if you can go to 0x20000000

Regards,

John

1. The tap registers inisde of ICEPick_C have other values than 0 or 1. See pic.
2. Accessing the memory at address 0x20000000 of  DAP was also working

Well that is good.  You actually connected to the DAP without an error.

If you go back to the Debug View and select the Cortex M and connect what happens?

If it connects ok could you then try clicking on the load program button and select the .out from your project.

If I am connecting to the Cortex M3, first it is saying it is "Suspended". After the program is loaded from my project, the error appear again

Ok this time after connecting to the M3 go to the Tools menu and select GEL files.

Select all the GEL files and remove them.

Now try to load the program.

It still fails with the same error. 

Can it be that I have a fault in my hardware design or do you think, that this is a software issue?

I am not sure where the issue is at this point.

Let's try a couple more things.

#1 Using SmartRF to load the program

Run SmartRF and do a mass erase

Then use SmartRF to load the program image

Did that work?

If so we could try then connecting in CCS (using the method of launching a debug session with the .ccxml and manually connecting) and instead of loading the program you can choose to use load the symbols from the .out and see if that goes without error. 

#2 We can generate some logs from the debugger that might provide some more information

In CCS you can go to the help menu, select CCS Support.  In the dialog that opens you can enable the Debug Server Log.

Then try launching a debug session and loading the program.  After getting the error exit the debug session and then add the logs to the thread.

Regards,

John

Good morning John,

Task 1 worked without any errors. When I was loading the symbols, I did not see any response inside of CSS; no log and errors.

Attached the log of Task 2

Christian7608.debug.log

Just wanted to let you know that I did pass the log on to the development team.  Once I hear something I will let you know.

Regards,

John

Hi John,

Thanks for your update. I hope they will find something.

Christian

John,

This is to let you know that I followed all of the procedures described in this post to resolve issues with a BOOSTXL-CC2650MA CC2540MA board, and I am getting the same errors. The issues arose after upgrading to ccsv9 (version 9.0.1.00004). The same setup worked fine with ccsv7.

I cannot continue development until this issue is resolved.

EDIT: I used SmartRF Flash Programmer 2 to erase memory again. This time, ccsv9 successfully flashed the BOOSTXL-CC2650MA. I corrected the part number typo above.

Dennis

Christian,

Looking over this thread I have one more idea to try to isolate the root cause of this behaviour. Can you disable the "Auto Run to main" option from the Debug Configuration?

Details at the section "Auto Run and Launch options" of the Debug User's Guide below:

http://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html 

This will cause the program to be loaded and halted at _c_int00 (or wherever the entry point of your code is) without running to main(). This will help see if the issue happens during or just after the code is flashed to the device or if the issue happens between the entry point and main(). 

If the issue is still happening after disabling this, I would thorougly scope the power supply lines to your external board. It may be sagging due to excessive current (proportionally to the thin wires being used) and causing the device to become unstable during flashing. 

If the issue does not happen, the problem is with the code itself - something is happening after the Entry point that is causing the CPU to go haywire. At this point I would perform a step-by-step debug of your loaded code to try and track where the issue may be triggered. Another detail is if the JTAG pins TDI and TDO are being re-configured by your code - something that would break communications if the target is configured by 4-wire cJTAG or JTAG. If that is what is happening with your system, you should have a fully stable system if you run with 2-pin cJTAG mode (the two pins TMS and TCK are not multiplexed). 

Also, if your CC2650 Launchpad is Rev 1.3, make sure that it has a jumper set between pins 1-2 (XDS110 Power) to guarantee the voltage translators are properly set. If your launchpad is Rev 1.1, there is no jumper. 

Which SDK and CCS versions are you using? If you go to the menu Help --> About --> Installation Details, what is the version of the TI Emulators component?

Hope this helps,

Rafael

Hi Rafael,

My CCS version is 9.0.1.00004, TI Emulator version is 8.1.0.000007 and XDCTool version is 3.55.00.11.

I was able to locate the line, where the error is triggered. It happens inside the function   TrimAfterColdResetWakeupFromShutDown$27() at address 0x0000a278. I was only able to read the assembly code. See pic.

I hope you have a better understanding of this function.

Thank you

Christian

Hi John and Rafael,

Do you have any updates to this issue?

Thank you

Christian

Hi Rafael,

The TCK is already set to 1.00MHz. This was one of the first things I was changing. I think, that the JTAG communication is fine. There must something going on during the reboot of the chip.

Christian

Looking at the setup.c and the setup_rom.c/h files (C:\ti\simplelink_cc2640r2_sdk_3_10_00_15\source\ti\devices\cc26x0r2\driverlib) might help.  Are you using the internal DC/DC converter, LDO, or an external regulator in your design?

Thanks,

Chris   

Hi Chris,

I am using the internal DC/DC converter. Do you think it is not running?  Inside of the function "TrimAfterColdResetWakeupFromShutDown" the JTAG power is turned down. This could cause the error.

Christian

Maybe a quick test would be to change the settings in the ccfg.c file.

//#####################################
// Power settings
//#####################################

#ifndef SET_CCFG_MODE_CONF_VDDR_TRIM_SLEEP_DELTA
#define SET_CCFG_MODE_CONF_VDDR_TRIM_SLEEP_DELTA        0xF        // Signed delta value +1 to apply to the VDDR_TRIM_SLEEP target (0xF=-1=default=no compensation)
#endif

#ifndef SET_CCFG_MODE_CONF_DCDC_RECHARGE
//#define SET_CCFG_MODE_CONF_DCDC_RECHARGE                0x0        // Use the DC/DC during recharge in powerdown
#define SET_CCFG_MODE_CONF_DCDC_RECHARGE             0x1        // Do not use the DC/DC during recharge in powerdown
#endif

#ifndef SET_CCFG_MODE_CONF_DCDC_ACTIVE
//#define SET_CCFG_MODE_CONF_DCDC_ACTIVE                  0x0        // Use the DC/DC during active mode
#define SET_CCFG_MODE_CONF_DCDC_ACTIVE               0x1        // Do not use the DC/DC during active mode
#endif

#ifndef SET_CCFG_MODE_CONF_VDDS_BOD_LEVEL
// #define SET_CCFG_MODE_CONF_VDDS_BOD_LEVEL            0x0        // VDDS BOD level is 2.0V
#define SET_CCFG_MODE_CONF_VDDS_BOD_LEVEL               0x1        // VDDS BOD level is 1.8V (or 1.65V for external regulator mode)
#endif

#ifndef SET_CCFG_MODE_CONF_VDDR_CAP
#define SET_CCFG_MODE_CONF_VDDR_CAP                     0x3A       // Unsigned 8-bit integer representing the min. decoupling capacitance on VDDR in units of 100nF
#endif

#ifndef SET_CCFG_MODE_CONF_VDDR_TRIM_SLEEP_TC
#define SET_CCFG_MODE_CONF_VDDR_TRIM_SLEEP_TC           0x1        // Temperature compensation on VDDR sleep trim disabled (default)
// #define SET_CCFG_MODE_CONF_VDDR_TRIM_SLEEP_TC        0x0        // Temperature compensation on VDDR sleep trim enabled
#endif

Regards,

Chris

Hi Chris,

Yes this helped. Now it is running without an error. FINALLY!!!

But I guess, this is not the final solution. Why is the DCDC not running?

Christian

I am not sure.  Can you do some troubleshooting around the DCDC circuit?

http://www.ti.com/lit/pdf/swra640

see sections 9 and 10 on page 31

Regards,

Chris

I was checking the voltage of PIN33(DCDC_SW). It has 1.60V. According to the datasheet it should have 1.68V. I was ignoring the difference due voltage drops from the cables at the voltmeter. I guess the inductive is  a little bit too small. I am going it to replace it with a bigger value. We will see, if this is the issue.

Thank you

Christian

Hello,

    Have you had any success in changing the inductor and confirming the issue is with the DC-DC regulator?

Regards,
Chris

Hi Chris,

I had to order new inductors. Hopefully I am getting them today. 

I will inform you, if I had luck.

Regards,

Christian