CCS/TMS320F28377D: XDS510 successfully connects to secured processor, XDS200 does not

Richard,

Despite the logs show the output of the debug server, can you also check the output of the GEL itself? If not redirected to a file, the GEL script usually outputs to the console. Perhaps this output can give additional hints as to what exact point in the GEL routine the processor is locking itself up. 

Considering all other details identical, one thing to keep in mind is that typically the XDS200 has twice the data throughput of a XDS510, thus potentially affecting any delay routine on the GEL itself. Although not with the exact same condition as yours, but I have seen DDR and PLL setup routines causing the processor lockup due to the absence of delays. 

A bit more obscure issue could be a borderline condition in hardware that is causing the XDS200 data transfers to have insufficient noise margin when compared to the XDS510. Given the XDS200 can have its TCLK adjustable in the .ccxml file, you can try to reduce its speed and see if the behaviour changes. 

I will think about other possibilities and, if I find something relevant, I will report back. 

Hope this helps,

Rafael 

Hi Rafael,

Thank you for your response.

> Despite the logs show the output of the debug server, can you also check the output of the GEL itself? If not redirected to a file, the GEL script usually outputs to the console. Perhaps this output can give additional hints as to what exact point in the GEL routine the processor is locking itself up. 

As the first trace shows, the gel script is outputting to the console, the second trace shows the process with exactly the same gel script, therefore if the gel script was run I would fully expect the output to appear in the trace. Or is there some other output that is available that I'm not aware of?

I don't know whether the issue is something breaking before the gel script is run or the gel script isn't run for some other reason.

Changing the JTAG clock speed of the XDS200 down to 1MHz (from 10MHz) made no difference.

Also, the process also fails with an XDS100v2 so the issue is with both the XDS200 and XDS100.  There is no option to control the JTAG clock speed on an XDS100.

Any further advice would be greatly appreciated.

Thanks,

Richard.

Note: CCS (and therefore DebugServer) version:

Version: 8.1.0.201805221500
Build id: N201805221500

Richard,

I will care about that.

Regards, Bernd

Richard,

Please apologize; I missed your replies and the GEL output on your logs (somehow the failed output tricked me into thinking the GEL was not being printed out). 

It took me a while to figure out the exact steps to protect the Flash memory (it's been a while since I did this), but I was able to program the password and the Z1-EXEONLYSECT registers with CCS (I don't have a script) using my XDS200 Debug Probe. The only errors returned were when I tried to access the protected areas of the locked device. 

I also tested with a XDS560v2 and a XDS100v2 - accessing the protected areas, that is (as the OTP was already programmed  the XDS200).

Therefore I am not entirely sure what is happening in your case - if this is due to an inherent difference of speed between the two Debug Probes (the faster XDS200 being a bit less forgiving with a possible delay on the target) or a hardware factor (noise or other aspect). Are you using a galvanic isolator between the Debug Probe and the device?

Also, would you mind sending the script so I could take a quick look? 

As for my settings, I am using CCSv9.1 with all the tool defaults and 190MHz of PLLSYSCLK.

Regards,

Rafael

Hi Rafael,

Thanks for your response, apologies for the lack of response from my side - I have been dealing with another urgent issue.

Could you explain how you connected to a secured device using the XDS200, please?  Did you use a gel script, if so, what did it contain?  What target configuration did you use?  How did you configure the following options:

• Auto Run and Launch Options / Realtime Options.Enable realtime mode (critical interrupts serviced when halted, rude/polite mode...)
• Auto Run and Launch Options / Realtime Options.Enable polite mode (respect HPI, DBGM and FRAMEID)
• Program/Memory Load Options / Connection Options.Reset the target on a connect
• Program/Memory Load Options / Reset the target on a program load or restart

I have tried with CCS V9.1 with an XDS200 with ALL the same settings as I used on an XDS510 (using CCS V8.1 which worked) and I just get the message:

C28xx_CPU1: Error connecting to the target: (Error -1133 @ 0x0) Device blocked debug access because it is currently executing non-debuggable code. You may retry after the device has had time to enter debuggable code, or you may cancel, disable realtime mode, and then attempt to connect. (Emulation package 8.2.0.00004)

With regards an isolator, we are not using one but all debugging on unsecured devices with all emulators works without issue so I'd like to understand why an isolator would effect access to a secured device only?

Can you confirm that gel files operate correctly with the XDS200 from the ccxml configuration file?  In my original post, the gel file does not appear to be run at all for the XDS200 and I don't have an explanation for that behaviour.

Thanks,

Richard.

Richard,

Earlier today I have sent an e-mail to BO with the following comments:

email said:

I was able to revisit this issue yesterday.

I am using CCSv9.1 and my XDS200 and I was able to properly secure the entire Z1 Flash of my F28377D device successfully. I am using the CCS interface and not GELs or any source/linker files on the project.

I haven’t tested Uniflash yet, which I will try later today.

The CCS procedure I am following is:

-          Manually launch a debug session with both XDS200 and F28377D experimenter kit.
-          Go to menu Tools → On-Chip Flash
-          Fill the Z1-CSMPSWD[0:3] with the password. Click on the Program Password button
-          Fill the Z1-EXEONLYSECT, Z1-EXEONLYRAM, Z1-GRABSECT and Z1-GRABRAM with the desired values. In the screenshot attached, I am protecting all Flash regions while leaving RAM unprotected. Click on the Program All Zone 1 Security Settings
  - During the programming of these OTP registers, CCS informed me the clock speed of the device was outside of its specs. To workaround this, I simply set the System PLLCR Integer Multiplier to 18
-          Terminate the debug session ( button)
-          Once in the Edit perspective, debug an ordinary project without the password settings. During load, CCS should present something similar to the following:

C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
C28xx_CPU1: Warning: Failed unlocking device (zone 1) after reset.
C28xx_CPU1: Flash Programmer: Error erasing Sector A. FMSTAT value = 1040. Operation Cancelled (0).
C28xx_CPU1: File Loader: Memory write failed: Unknown error
C28xx_CPU1: GEL: File: C:\Users\a0356111\workspace_v9_1\adc_soc_epwm_cpu01\CPU1_FLASH\adc_soc_epwm_cpu01.out: Load failed.

-          Back to the same project in the Edit perspective, right-click on the project, select Properties → Debug
-          Fill the Z1-CSMPSWD[0:3] with the password.
-          Debug the project again. The Flash should be fully erased and properly programmed. 

Despite the XDS510 works on the previous version of CCS, the original issue reported is a connection issue only on the XDS200 – that is why I asked for the script he is using to connect and program the device to see if I could track any potential issues with it. 

Also, as I mentioned in one of my replies, the inability of the XDS200 to connect may be due to slight hardware differences between one of our development kits and his custom board – unfortunately I couldn’t find anything reported in this regard. Did he try to follow the same procedure with one of our regular development kits? 

I will try the procedure using Uniflash, but know that this utility is more limited than CCS for diagnostics. Traditionally we recommend using CCS until the procedure is well oiled.

The fact you are unable to connect is the most troublesome scenario, which is independent of an active DCSM or not.

If you have CCS, what does the "Test Connection" button report?

Also, can you try to connect to the ICEPICK and inspect the status of the cores? Check item 8 of the section below: 

https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html#troubleshooting-the-connect-phase 

By the way, I configured Uniflash 5.1.0 and added the same password and I was able to properly unlock the flash sectors, load code, etc. 

Hope this helps,

Rafael

Hi Rafael,

Thanks for the steps, I was able to reproduce the correct behaviour following them using a XDS200 and a controlCARD devkit.  I was able to connect, flash and debug a small program on a secured device using a XDS200.

However, after loading our software, this was no longer the case.  I was not able to connect to the device using the same approach with a XDS200.

After enabling 'rude' realtime mode, I was able to connect with a XDS510 but enabling 'rude' realtime mode with the XDS200, it still failed to connect.

I believe I have eliminated connection issues, our hardware and the process leaving only our software as the crucial factor. Therefore, there is something in our software that is requiring realtime mode and this prevents connection with a XDS200 but works fine with a XDS510.

What settings require 'rude' realtime mode to be used and would it be possible to test your board with those settings and the XDS200?

I am sending an email to Bernd with far more detail in it, which may help.

Thanks,

Richard.

Richard,

Richard Day1 said:

However, after loading our software, this was no longer the case. 

That is my suspicion on the e-mail I sent Bernd and copied below. 

email said:

I strongly suspect their application is making the device to go haywire somehow. 

Did the customer try to connect and inspect the status of the cores using the ICEPICK as I suggested before? This would help isolate the issue to the core or to the entire device.

The tips below are to try and intercept the core before the flashed code takes it to la-la-land.

The technique described in this post can help move one step further.

If unable to connect to the ICEPICK, can the customer follow the same steps in the post above until step 5 then:

6) right-click on the C28xx_CPU1 core
7) press and release a physical reset button on the board
8) immediately select Connect Target. They may need to retry this a few times.

If the code previously loaded in the core is indeed taking down the device, the reset options in the Debug Configurations → tab Target → Program/Memmory Load Options → Connection Options should help as well.

I am not entirely sure how the customer has connections to the target, thus I can’t necessarily guarantee the nRESET/SRST or the EMUn bootmode status can help overcome this scenario. These options are present in the Advanced tab of the Target Configuration File

Given that I don't have code that "breaks" my F28377D, I can't necessarily test the effectiveness of the Real-time mode here. However, the suggestions above may help see if the XDS200 is able to connect even under less than ideal circumstances. 

In the meantime, I will try to see if I find a testcase that locks up the device. 

Regards,

Rafael

Richard,

Thanks for sending the testcase. Unfortunately I was unable to reproduce the inability to connect. Please check the procedure in the video below: 

The video above uses CCSv9.1.0 with the latest emupack and flash packages. I will retry with CCSv8.3 and report back. 

Regards,

Rafael

Hi Rafael,

Thank you for the video, I can replicate your findings including connecting to the device after it has been flashed with code.

However, I find that once the device has been powered down and powered back up, it is NO longer possible to connect to the device with the XDS200.  Reconnecting to the device before powering down is connecting to an *unlocked* device and this has never been an issue.  Once the device has been re-powered, it is locked and this is when the issue occurs.

Could you please try this and report back on your experience, please?

Thanks,

Richard.

Hi Rafael,

Thank you for your video, I followed it and replicated your experience including connecting to the device after flashing it with code.

However, if the device is powered down and then powered back up, it is NO longer possible to connect to the device with an XDS200. Am I right in thinking that throughout the video, you did not reset or power down the device?

Could you power down your device, power it back up and then try to connect to it with an XDS200, please?

Thanks,

Richard.

Richard,

Unfortunately I still couldn't reproduce the issue. In the short clip below, I deliberately try to connect to the powered down device (it throws an error) but, when I power it up, I can reload the code without issues. 

The password is pre-programmed in the CCS Debug Configurations settings (I also show that on the video).

I will keep trying to break my system here in the hopes there is a minute detail that is escaping my procedure. 

Regards,

Rafael

Hi Rafael,

Thanks for continuing to support us on this!

Below is a memory dump of 0x78000 onwards on my device (connected via an XDS510 and unlocked), is there anything here that is different to yours? Is there anything that looks suspicious?  Am I right in thinking that all the DCSM settings are contained within this block or is there any other settings held in OTP that could explain the difference in behaviour?

I'm wondering whether the only route now is to send you the board we have and see whether you can connect to it, would this be possible?

Thanks,

Richard.

Richard,

Unfortunately I can't see the screenshot. Could you resend it, but now you have to click on the small clip button at the top of the editor view?

I am pretty sure the DCSM settings written to OTP would influence the ability to connect or probe the device, but still the difference between the XDS510 and the XDS200 is really baffling and could only be explained by some borderline hardware condition. 

I could potentially analyze this on your hardware but I would have to confirm with other folks if there is am not familiar with a specific process to do this. I will report back. 

Regards,

Rafael

Hi Rafael,

Apologies, hopefully this will be visible:

Thanks,

Richard.

Richard,

Thanks for sending the screenshot. Are you showing this with the XDS200 or the XDS510?

I see a very similar thing as you, although I had to move the link pointer one position (I goofed up the first time). That is why you see multiple entries on my screenshot. I also do not have anything set on Z2. 

With that, I suspect the focus of the issue is with the XDS200 + board combination.

I suspect you have done so already, but did you try using another host, Debug Probe or a development kit? I wonder if something out of our sight, such as a ground loop or noise, is getting in the way of the XDS200. Perhaps I am repeating my suggestions, but that is where I believe the issue is happening. 

Just to shave off any possible software settings, please check attached the .ccxml file I am using with my controlCARD and the debug launch configuration. 

You need to copy the .ccxml file to the path of your existing CCSTargetConfigurations (typically %HOMEPATH%\ti\CCSTargetConfigurations) and import the debug configuration using the menu File --> Import --> Run/Debug --> launch configurations.

Before importing, you need to edit this debug configuration in a text editor and change the path of the .ccxml file (currently set to C:\temp\F28377D_XDS200.ccxml) to your existing absolute path. 

After importing, you can launch it by using the menu Run --> Debug Configurations. 

Hope this helps,

Rafael

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/81/F28377D_5F00_XDS200.ccxml

F28377D_XDS200.ccxml.launch.zip

Hi Rafael,

Thank you for posting those files, I used them to test with and unfortunately, I still cannot access the device I have with the XDS200.  The memory captures above were indeed taken with an XDS510 since I cannot connect with a XDS200.

I think the only course of action now is for me to send my controlCARD board to you and ask that you attempt to connect to it with a XDS200.

I will contact Bernd directly regarding this.

Thanks,

Richard.

Hi Rafael,

Thanks for finding this so quickly - it now makes sense why you did not have the problems I was seeing with a supposedly identical setup!

I must confess to never considering looking at the jumpers and their effect.  But in my defence, I've always come from the point of view that it works correctly with an XDS510 without changing the jumpers, so why doesn't it work with the XDS200 without changing the jumpers?

Am I right in thinking that by resetting into 'wait mode', the device does not apply the security settings and hence the board is not secured when first accessed by the XDS200?  If this is the case then the problem remains: how can I connect to a secured DSP with an XDS200?

This also does not help the original problem which was on a proprietary board with no boot mode jumpers.  How can I connect to it with an XDS200 if the DSP is secured?

And finally, there still doesn't seem to be a valid explanation for the differences between the XDS510 and XDS200.

Thanks,

Richard.

Hi Rafael,

One further thought: do you have an XDS510 with which you could try to connect to the secured controlCARD with the jumpers in the initial positions?  I'm still very much interested to understand the differences between the two emulators and how they work with a secured DSP.

Thanks,

Richard.

Richard,

I am still working on this issue. I am testing this on two CCS versions and multiple firmwares loaded to the cores. 

Testbench is:

- Two F28377D controlCARDs connected via XDS200 and XDS510USB (one controlCARD at a time)
- CCSv9.0.1 with TI Emupack 8.1.0.00012 and C2000 Emulation Flash 1.0.0.5 and C2000 Device Support 4.2.7.0
- CCSv9.1.0 with TI Emupack 8.3.0.00003 and C2000 Emulation Flash 1.0.0.5 and C2000 Device Support 5.0.0.0
- Projects used are:
   - blinky_dc_cpu01 + blinky_dc_cpu02 (to validate single and dual CPU usage)
   - adc_soc_epwm_cpu01 (on CPU1) with ESTOP0 commented out (running freely).

For the past few days I was unable to reproduce the issue on both our boards - the debugger was able to connect to the device regardless of the bootmode jumpers. I tried to backtrack any changes and modifications I have done in the test bench to no avail. 

However, about 20min ago it occurred to me to load a different project (adc_soc_epwm_cpu01) and the issue just started to show up again. 

With this, I will be able to resume the diff between the two debug probes - apparently the code may be putting the device in low power run (or perhaps other mode) and only the XDS510USB is able to bring it up from this mode (or perhaps it does not warn the user). 

I will report back to this thread. 

Regards,

Rafael 

Richard,

Now using a different project, I have the same outcome with both the XDS510USB and the XDS200: both can't connect if the bootmode of the controlCARD is set incorrectly. 

I forgot to tell in my previous post that the XDS510USB was being connected via CCSv8.3.1 (not 9.x, which is unsupported). Component versions are: TI Emupack 8.1.0.00012, C2000 Emulation Flash 1.0.0.5, C2000 Device support 4.2.7.0, Spectrum Digital Emulators version 5.2.0.14.

At this point I am almost certain that a borderline difference between the XDS200 and the XDS510USB was amplified by the type of code previously running on the target device. I tried a few different projects with the bootmode set "incorrectly" and it was a mixed bag with regards to connectivity: some connected fine, others failed. 

I can keep trying to evaluate additional example codes and will report back any relevant additional information. 

Regards,

Rafael

XDS510USB failed to connect with bootmode:

XDS510USB successfully connected with bootmode:

Thanks for the continued effort, Rafael, hopefully you can identify the issue and it can be fixed.

I was going to say that I've never been able to connect to a secured DSP that's running code with the XDS200 (a comment on your statement about variability) but then again I've only ever tried with our own software so it's a very limited test.  If there's something that's triggering this behaviour it is very likely to be in our software hence the reason why I could never connect with an XDS200.

Thanks,

Richard.

For others following this discussion: this thread is being worked offline. I will post relevant developments for reference.