CCS/CC2640R2F: CC2640R2

Tushar,

Additional explanations about these errors are shown at the Debugging JTAG page at:

https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html

Hope this helps,

Rafael

Hi Rafael

I have tried a few things already. These are - 

- Lowering the TCLK frequency (didn't help)

- Using Flash Programmer 2 (at times the device CC2640R2F is detected and at certain other times, it is not)

When it was detected, I was able to perform mass erase on the core

When I tried to program it (burn the flash image), sometimes it would just say "device successfully reset" and at other times it would give an error "Create XBAL object failed: Debug interface is locked"

How do we resolve this?

Tushar,

Since you seem to have these troubles after loading code to the target once or more than once, this leads me to believe the code may be causing this device lockup. The explanation of error -1170 on the page I sent mentions the process of performing a mass erase on the device - you could try that and see if loading a simpler example code does not exhibit such behaviour.

I am not very familiar with the Flash Programmer 2 tool, but a search for the error message yields a few threads around e2e that points to the same scenario I described above. 

https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/808599

https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/705088

Hope this helps,

Rafael

Hi Rafael

The Flash Programmer 2 is able to successfully flash and verify the device. That was one of the debugging steps recommended in one of the e2es to ensure that the debugger is able to communicate with the device.

However when I use CCS, I get the "Unable to access DAP" error. What do you think could be going on here?

Thanks

Tushar

Does flash programmer need the external crystals on the board which are there for the microcontroller?

I am suspecting that flash doesn't need them but debugging through CCS does. Somehow the crystals are damaged and are causing this problem. Do you think this might be correct?

Also my VDDR starts off with 1.05V and then shows a steady decrease to 0.6V and below. 

Regards,

Tushar

Tushar,

Tushar Bhattacharyya2 said:

Does flash programmer need the external crystals on the board which are there for the microcontroller?

As I mentioned before, unfortunately I am not familiar with the flash programmer tool. I am able to connect to the CC2640R2F and it has both crystals fitted.

Tushar Bhattacharyya2 said:

Also my VDDR starts off with 1.05V and then shows a steady decrease to 0.6V and below. 

On my launchpad I see the VDDR and VDDRF pins steady at 1.6V, thus I wonder if there is a possible hardware issue. 

One aspect I have seen in the past is that sometimes the amount of data transferred to/from a target board may bring different connection outcomes (this case of the flasher and CCS having different behaviours). In these cases, I usually could track to other extrinsic factors such as a ground loops between the target and the host or noise on the JTAG lines. 

At this point I am unsure what may be happening in this case. I will point this thread to a device expert for further comments. 

Regards,

Rafael

-> Does flash programmer need the external crystals on the board which are there for the microcontroller?

Only the radio uses the external 24 MHz xtal

-> Also my VDDR starts off with 1.05V and then shows a steady decrease to 0.6V and below. 

This is not correct

To check if this is a hardware issue or not you can use http://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS

There are quite a few things that I tried out. I am listing them in order:

• Tried to debug with the XDS110 on CCS and got the DAP error mentioned above. 
• Switched to flash programmer 2 and after a few hiccups initially, was able to repeatedly detect the device (core) after disconnect and reconnect. Flash programmer 2 required me to update the firmware on my debugger (XDS110).
• Went back to CCS - it asked me to update the firmware on the XDS110! I did that and suddenly things became worse. I got this error now "A router subpath could not be accessed". 
• I connected to flash programmer 2 again and this time, the software failed to recognize the core! I tried mass erase and it didn't go through either. I guess my core is damaged? Also, it it at this point TER, that I measured the wrong voltage at VDDR quoted above. 

Did these firmware updates to XDS110 screw something up in my board?

Interestingly, I decided to power my custom board with a coin cell today and lo and behold! It was working! I have a few custom LEDs in my board for debug and testing GPIOs and the last time I had used flash programmer 2 to flash an image, I had written the code to blink one of the LEDs and to turn ON another and they were doing exactly that!

I am now sure there is something with the XDS110 debugger and CCS that is somehow not working along with my board. Any pointers will be highly appreciated!

Thanks

Tushar

I made another interesting observation yesterday. 

I wanted to see if I could flash any output file into the core using Flash Programmer 2 and if that would work.

So I flashed a modification of simple peripheral that I had made recently. Then I disconnected the debugger and powered my custom board using a coin cell and I was able to connect to my custom board using my phone! And also read values!

But when I power custom board using the debugger, it doesn't work. 

I also read the different voltage values in each case and they are as follows.

With WMCU_VDD (power from debugger) with or without JTAG pins connected, VDD ~ 3.17V, VDDR = 1.6V

With coin cell, VDD ~ 2.6V, VDDR = 1.5V

Any ideas on what might be going on?

VDDR should be 1.67 V meaning that for all your cases the value is off. The value you measure could look different depending on how your instrument works since this voltage will have a slight saw tooth shape. But the VDDR voltage should not change according to how you power the device. 

I still suspect a hardware issue. 

Have you also tested some of the examples under https://dev.ti.com/tirex/explore/node?node=APwBWdtqTgxZuJ9l4iRqpQ__krol.2c__LATEST? Not too familiar with the BLE examples but some of them require that you combine more than one hex file. 

Hi,

Thanks for providing additional details. I tend to agree with TER that this looks more and more like a hardware problem. 

Tushar Bhattacharyya2 said:

But when I power custom board using the debugger, it doesn't work. 

How are you powering the board when the Debug Probe is connected? From your posts it seems you were using either an external power source (not a coin cell) or the debug probe itself (via its auxiliary connector). 

If you are using an external power source, I mentioned this in a previous post: 

desouza said:

One aspect I have seen in the past is that sometimes the amount of data transferred to/from a target board may bring different connection outcomes (this case of the flasher and CCS having different behaviours). In these cases, I usually could track to other extrinsic factors such as a ground loops between the target and the host or noise on the JTAG lines. 

If you are powering your board using the Debug Probe TMDSEMU110-u itself, keep in mind it is limited to 100mA and usually can't keep up with some of the sudden current changes required by the wireless microcontrollers. To provide a steady supply to a target (up to 800mA) you need a TMDSEMU110-ETH add on. 

You can also check our design guidelines at the XDS Target Connection Guide at:

https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds_target_connection_guide.html

Hope this helps,

Rafael

My custom board is powered by the debugger itself when it is connected to it. 

Also the board ground is connected to the debugger ground, so I don't see an issue there. 

I am using the XDS110 debugger that is part of the CC2640R2 launchpad.

@TER @desouza 

I am still struggling with this.

When operating from a coin cell (~2.8V) , all my functionalities including wireless are working.

When supplying from the LAUNCHXL-CC2640R2, none of those functionalities work.

I also see that when on the coin cell, I am drawing a current between 5-6mA

When powered by the LAUNCHXL, it's drawing 18-19mA.

It's really baffles me. 

I am okay to submit my schematic for a review if that helps. 

Tushar Bhattacharyya2 said:

When supplying from the LAUNCHXL-CC2640R2, none of those functionalities work

Supply from the launchpad is 3.18V

You can request a review here :

It would also be interesting to see a picture of your connection when it doesn't work. 

Thank you. I have submitted the request for review. 

Also here's the picture of the setup when it doesn't work. 

- Do you have reset connected?

- Is it any difference if you remove the battery when you try to power it from a LP? 

- On connecting RESET, Vcc current drops down quickly from 5 to 3.5mA. Without reset, it's around 8.5mA. 

- After removing the battery, with RESET connected, current is around 3.6mA. Without RESET connected, current fluctuates a lot, sometimes going beyond 19mA and sometimes down to 8-9mA.

Tushar

With reset connected I was referring to: The reset line from the XDS110 is connected to the reset on your board.

And in which state do you see this power consumption?

TER said:

With reset connected I was referring to: The reset line from the XDS110 is connected to the reset on your board.

Yes, I am referring to the same as well.

TER said:

And in which state do you see this power consumption?

Right after power up, when the device is advertising.

thanks,

Tushar

I don't see any reason why the current draw should be different depending on how you connect reset. The reset line should be a logic '1' in both cases when the radio is active. 

When you get a jira ticket name (you should get a mail when somebody approve your HW review request), please post the ticket number here so it's easier for me to find it. 

TER said:

I don't see any reason why the current draw should be different depending on how you connect reset. The reset line should be a logic '1' in both cases when the radio is active. 

The reset is '1' on my board since it is pulled HIGH, but the reset logic from the XDS110 on the LP is '0'. Is that resetting my circuit continuously?

TER said:

When you get a jira ticket name (you should get a mail when somebody approve your HW review request), please post the ticket number here so it's easier for me to find it. 

Sure I will update you with the ticket number once I receive a reply from someone. 

The reset sounded strange. Do you see a logic '0' on the LPs reset line even if you are not connecting the LP to the DUT? CC2640R2F should use ~1 uA in active reset. 

Hey, I was seeing a '0' on RESET even when I didn't connect the LP to the DUT. I had the "XDS110 Power" jumper removed during this. When I put the jumper back in it's default position, the RESET reads 1.10V whereas TMS and TCK read 3.20V each.

Do you have a different LP to test with? The Reset line should be to VDDS.

Just to be sure, could you post a picture of the LP when you measure 1.1 V and post?

No I only have one Launchpad.

Here's the picture of the measurement. 

Interesting. Are those 3 other wires connected to anything? 

No, the other 3 wires are not connected to anything. But I measure 3.2V on them.

Hm, I did some measurements on a CC2640R2F Launchpad now. It looks like the output from the XDS110 reset line is high-z if the debugger is not trying to pull the line low. I started with all jumpers removed and measured 10 mA on he reset line, then I connected the jumper and it went up to 3.3 V. Then if I removed the jumper the reset stayed at 3.3 V on the debugger side. 

Hm ok. Still not sure how it's affecting my hardware. I submitted the design review request and it just got the first level approved and now it's with another internal team for approval I guess. The case number is CS0233497 if it helps.

Thanks

Tushar

Hmm, it looks like a jira ticket hasn't been made yet for some reason. You can also send me a friend request and send the design as a personal message. 

Hi TER!

I was just going to update you. I received an email from a TI engineer earlier today and I have submitted my files to him. I didn't get any JIRA number from him though. I will send you a friend request and share with you further information.

Thanks.

Tushar

Hi Tushar,

I reviewed your design files and just emailed you my feedback. I recommend you try changing C28 to a 100nF capacitor. With the current value, the reset rise time is 1 second, which is quite slow.

When using the LaunchPad as the debugger, the jumper on the VSENSE header should be placed on pins 1 and 2, so that the level shifters are powered from the USB. If it is placed on pins 2 and 3, and there is no external voltage source connected to the LaunchPad's power rail, the level shifters will not work. The UART, JTAG, and RESET signals all come from these level shifters. 

How are you connecting power from the LaunchPad's 3.3V header to your custom board? 

BR,

Seong

Hi Seong, 

Noted about the cap. Does having a slow rise time affect how the part would respond when I wanted to enter debug mode in CCS?

I have the jumper on pins 1 and 2 of VSENSE and I am powering my custom board using the 3V3 and GND headers on the XDS110 side. 

Surprisingly, when I use a TPS62730 to power the CC2640 rails, now I have a functional board with BLE and I am also able to enter debug mode in CCS!

Thanks

Tushar