TMDSEMU110-U: tmdsemu110-u Energy Trace not working correctly

Hi,

Interesting; I recall from my older experiments that the very low currents can be influenced by the amount of powered on subsystems on the device. In this case, did you try to use EnergyTrace without a debug session active? The reason is that the Debug subsystem on the device may be raining the low power level.

I also recall that, in launchpads, I had to remove the jumpers that connected the power to the upper part of the board that contains the Debug Probe. This helped reduce leakage.

In more rare cases when LPM5 was used, I actually had to power cycle the device so as to avoid the influence of any subsystems that were previously powered on (such as the debug subsystem used to flash the code to the device). I suspect this is not true anymore, as long as you put the code to do a "Free Run" (menu Run ==> Free Run).

I will think about other possible scenarios that could be influencing your measurements and report back if I find any additional details.

Hope this helps,
Rafael

Thanks Rafael,

I have tried with and without debug session - it is the same. All jumpers have been removed since I have the same setup when using my battery emulator. I know that this same board with the code flashed and running, external power supplied at the same terminals, measures 2.3uA. But for the ET I get 500-600uA minimum (with or without HDR)

Are there any diagnostics or tests that can be performed ?

Thanks Rafael,

I have tried with and without debug session - it is the same. All jumpers have been removed since I have the same setup when using my battery emulator. I know that this same board with the code flashed and running, external power supplied at the same terminals, measures 2.3uA. But for the ET I get 500-600uA minimum (with or without HDR)

Are there any diagnostics or tests that can be performed ?

Hi,

There are no diagnostics per se that can be performed, but I just recalled something that may be misconfigured in your environment.

Did you set your the EnergyTrace Range Selector to low current? That may make a different in the lower end of its range.

Tomorrow I will test my XDS110 + HDR on a CC1352 Launchpad and see how low it goes. I may need to ask for your project depending on the results I get. 

Regards,

Rafael

H Rafael, yes I have this set. I have followed all the procedures.
I think I will get a new one if this does not seem normal to you.

Well I got a new EMU box, it seemed to be working better, measuring around 30uA. Then I plugged in the HDR, back to 500-600uA. Now the EMU has the same symptoms with or without the HDR - 500-600uA. Seems that the HDR is defective and destroying the EMU's. So now have 3 faulty boxes !

HI,

Sorry; I wasn't able to reply earlier.

Yesterday I did a series of tests with the pinShutdown project and found a very high power consumption that I am currently blaming on the project itself. However, I did not experience such persistence in erroneous readings.

For example, I read between 81mA and 87mA depending on the "shutdown" status of the processor - that using a TMDSEMU110-U + a TMDSEMU110-ETH on ET mode and no JTAG connection (nor jumpers connected on the target). These measurements were confirmed with a DMM. 

What do you read if you simply disconnect one of the wires to the target? Do you get near zero Amps? That is what I get when using the Low current mode: 

In high current mode I get a perfect zero Amps (due to the lower resolution applied). 

If you still see the 600µA under these conditions, something seems indeed out of order. 

In addition to that, what do you see when you fully disconnect and then reconnect the pod from the USB port? Does it return to the lower 30µA range? I suspect there may be something else playing a part in holding your pod "hostage" to a prior run. 

You can also shutdown CCS, disconnect the pod and simply remove all temporary files under the directory %HOMEPATH%/.TI-trace

I couldn't get a project that goes down too low (the 30µA range). If you can share the project you have, that would be helpful to try and reproduce this here. 

I will keep doing some other tests here and see if I there are scenarios where I can reliably reproduce some sort of "persistence". 

Regards,

Rafael

Hi Rafael, 

Unfortunately removing the device wires doesn't make it go to 0, it stays at the 500-600uA mark. So definitely an issue. 

To get to the 30uA, take the BLE simple peripheral, and disable the advertising (GapAdv_enable). There should be 2 lines that need commenting. 

So I guess no-one has seen this issue of HDR unit destroying the EMU before. 

Greg,

Rafael is out this week.  He will try again to reproduce when he is back next week.

Regards,

John

HDR-issue.pdf

Thanks John.

Hi Rafael, 

Some progress to report.

1) I reflashed the XDS110 probes with the latest firmware.bin from CCS9, and after downloading the program to the board, removing the JTAG connector - then with the XDS110 alone I get reasonable results - measuring mean current values down to 2uA etc. So no longer the 600uA problem. 

2) However the HDR module is problematic. It doesn't seem to add anything to the resolution of the measurements as it stops working after 4-6secs. Both HDR modules that I have seem to have the same issue. It stops logging with data stream error or energy trace current exceeded. This is on the same current measurement that the XDS110 alone was working fine on. In addition the start-up current is high. I have screen shot the good and bad situ's for your view - will upload. Do you know what this could be ? Is it possible to update the FW on the HDR ? 

Thanks.

 

Thanks for the analysis Rafael. 

I will look at the HDR's again to see if I have missed something. 

For the uA measurements - interesting that you do get a delta between different FW versions. Also in turns out that you need to keep the RXD header connected on the 1352 LP due to some leakage - not well documented ;)

Thanks again ... will look at your 600uA post now.