CC3220SF-LAUNCHXL: TI-RTOS version of Hello...from TI-Resource Explorer will not connect to target: error is "Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP"

Thanks, Ben, that solved the problem. It would have been nice if the Error message provided a bit more information... or a link to this solution. Searching for "Unable to access DAP" wasn't very useful but in hindsight, searching for CC3220 with Error 1170 came up with a couple of E2E posts that led in the right direction.

Going through the suggested solution, SimpleLink Academy suggests using Uniflash Cloud but that gives the error:

"Error: CC3220 Image Creator is not support on the Cloud. Please download the Desktop version."

Besides the obvious grammar error, it looks like the Cloud won't help us solve the problem. After installing the desktop version, things went smoothly at first. Towards the end of the process, though, where the tool asks for an "MCU Img", I was confused as to what was needed. At first, I tried one of the CC3220 bin files I had created - but then ran into the next error about "wrong device type". In the end, I found that we can just leave the "MCU Img" blank. It would be helpful to state that in the SA instructions.

When I clicked "Burn", though, it showed a dialog that said:

"Wrong Device Type" with buttons for "Program" and "Abort".

I couldn't figure out how to fix this error. I backed up a few times trying different things but with no luck. In the end, I just clicked "Program" to give it a try... and that seemed to work. After this process, my device was left in Development mode and I was able to go back to CCS and continue debugging as expected.

I'm still unsure as to why the CC3220 on my LaunchPad switched to Production mode? I had used it many times in the past without a problem. But I appreciate your quick suggestion on how to fix the problem.

Thanks,
Scott

Hi Scott,

I understand what you mean about the error code, but I think it's a bit tricky since the error is a generic error for the JTAG and the key here is understanding what on the device-side is causing it. Hopefully this E2E can serve to bridge that disconnect. I'll check to see if we can make it even more prominent by turning it into an FAQ.

I'll also check on the statement about using ImageCreator through the cloud. I don't think that should be there.

Regarding the "Wrong Device Type", it sounds like your ImageCreator project is setup for a specific device variant which doesn't match the device on the EVM. For example, "S" type instead of "SF" or "20" instead of "30/35', etc. I don't think this is a big problem since the settings you are loading to the device (including putting into dev mode) shouldn't be affected. You can do a quick sanity check though by seeing what the ImageCreator project "device type" is and comparing to what your EVM is.

Not sure why your LP switched to production mode. I wouldn't expect it to based on the steps you are saying you took. Let me know if it happens again and we can investigate further.

Best Regards,

Ben M

Ben - thank you so much for the quick response. Very helpful. I am back up and running. A few items to consider:

1. I agree 100% with Scott and some of the confusion around all the buttons and what to do to ONLY get your board unstuck from production mode to develop mode. (fyi - we can help you write AWESOME instructions for your users...this is why we are THE trusted 3P to TI for all EP!) I am not joking about this. We spend an insane number of hours crafting our workshops and lab instructions on Simplelink processors to ensure first time success and it is just this sort of stuff that can either make or break the OOB experience for the customer. Ok - nuff said. You know how to contact us.

2. When my board was finished flashing, I received the error: "operation failed: Unhandled exception: Error: SLImageCreator.exe: XDS Power On failure: 1". SOOO descriptive. ;-)  If I hadn't see Scott's message (which did not contain this error), I might have spent 30-60min more trying to figure out "why this happened". But I followed Scott's advice of "just ignore the errors...they mean nothing", which, as an embedded programmer, bothers me immensely...but he was right. I ignored it...and there is a still small tickle in the back of my brain wondering if something weird may happen later when I am debugging code on this board that some day someone will say "yo dude...do you remember that error you got when you programmed the board into development mode? Yes, that one. Sorry for the 1.5 days of debug you have recently gone through but THAT was the mistake. You should have never ignored that error." Why am I sensitive? Because I have been using embedded tools for 30 years...I have been through this a few times before. But I digress. The TI-RTOS code works great and runs fine. But I am still not completely comfortable.

3. Why did my board (same question Scott has) suddenly jump into production mode? Over the past year, we have developed TI-RTOS code just fine on this board with ZERO issues. It must have been in develop mode the whole time. Right? The ONLY thing that changed was a few days back when I hooked it up again (after 4-5 months of non-use) and the tools asked me to upgrade the FET/JTAG software. Bang, problem happened. I have a suspicion that somewhere buried in that FET/JTAG/EMU software update, the device/board is PROGRAMMED into production mode. It is the only explanation. Is it possible for you to follow up on this and let us know if this is true or not true? It would be important for us to know so that we can add this information to our installation guide for the CC3220SF Workshop on using TI-RTOS. In fact, this whole discussion, and your responses, will be edited down and added to our installation guide so ALL users will be able to walk through this successfully.

Thanks again Ben. Sorry for the longer post here that you "must" read. There was more involved here than just an error and a fix. We bust our behinds to be detailed, thorough and complete in our lab writeups and installation guides for all TI EP workshops we develop for your customers. Our goal is "confidence and competence"...so "little'" things like this can actually turn ON or OFF customers to your products and we want to ensure SUCCESS because we heavily support TI EP products and your customer base. So thanks for helping us through this...

Cheers,

Eric Wilbur

Hi Eric,

I continued to explore the root cause of this issue with our tools team today.

We were able to run through a series of tests and conclude that the problem is not related to the emulation firmware update. We took a "fresh" LP with outdated XDS110 firmware, connected to it with CCS (by launching connection with target config instead of by launching a debug session), then updated the firmware after the prompt. Following this process, the firmware is successfully updated and CCS can still connect to the EVM afterward.

Looks like the actual trigger for the problem may be the Sysconfig ImageCreator tool and how it interacts with the board when it first builds a project from the v4.40 SDK. We are still digging into this.

Best,

Ben M

Thanks Ben. I appreciate the follow up. I didn't suspect that was the root cause. If I think about "what changed" from my board working 6 months ago vs now, the only changes were a) updated the XDS110 firmware; b) updated to a new SDK (4.30). So I now suspect something with the SDK. Still curious that both Scott and I had the same problem at the same time using the same updates.  ;-)

Eric

Hi Eric,

Agreed. Just letting you know we seem to have ruled out (a).

Were you both working with SDK v4.30? I'm still only seeing on SDK v4.40.

I'll keep you updated as we keep making progress.

Best,

Ben M

Hi Ben, the new SDK (v4.40) was released and became available just a couple of days after we had the problem. Since then I've upgraded to CCS 10.2 and SDK v4.40 without any problems.

Eric and I were both using CCS 10.1.1 at the time of the incident. We use Sysconfig to configure the drivers for our examples and lab solutions and so we were running that tool to build our code. But since, at that time, we were not aware of the new ImageCreator feature in Sysconfig, we didn't (knowingly) use it. I say "knowingly" in case there were any pre-release ImageCreator elements that were a part of the Sysconfig that was bundled with CCS v10.1.1.

Thanks,
Scott

Hi Scott,

Yeah, we had a preview of the tool available in one of the demos. The local_ota demo. It's possible that led the issue. It makes it unlikely though.

All this info helps though. Again, we will keep digging and report back what we find.

Best,

Ben M