This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS5.4 Debug with JTAG incorrect ADC register flags LM3S8971

Guru 51365 points

Spent 3 days to wonder was loosing my mind but managed to work around ADC registers source stepping F5/F6 all appear cross wired in debug however behave correctly on the peripheral when disconnected from JTAG. 

Also had numerous crashes (Win7 program stop responding message) during debug load program flash. Crashes occur after changing computer IP address and not allow Eclipse firewall access to internet. Expecting to change the IP back when finished, why modify the firewall tables adding a static IP address bound to the NIC (security risk). Sharing data in the same computer memory space as debug and Ethernet console GUI, the target was running allowing verify & clear fault condition and test ADC measured analog voltage values set properly. Ended up having to trial and error low/high conversion values,  PANIC was easily tripped during the FOC ramp velocity.

Has the ADC register status flags been fixed in CCS5.5 or has anyone else see this behavior?

Cross posted code and issue verified in Stellaris forum.

  • The error log in CCS5 shows many attempts to connect to local host being refused. This may be Eclipse or GIT trying to open the channel to phone home after being denied access at the Windows firewall.

    BTW: TI Resource Explorer was closed.

  • The comments/feedback you have posted here as well as in the other thread that are related to ADC coding/functionality are best addressed by the Stellaris team, so the Stellaris forum where you have already posted is the correct place.

    As you noted, single stepping source code that has been optimized can sometimes be tricky to navigate as source lines may be rearranged by the optimizer. The key thing to look for is that the results are as expected.

    Brett Price said:

    Has the ADC register status flags been fixed in CCS5.5 or has anyone else see this behavior?

    Is there still an outstanding issue/bug in CCS 5.5? If there is a consistently reproducible bug, please provide more details and a simple test case and exact steps to reproduce the issue so we can submit a bug report.

  • Hi AartiG,

    That means ADC (Register plots) for other TI processors are simulating FIFO status flags correctly during an XDS100v2 debug simulation when one of any number of sequencer is configured TRIGGER_PROCESSOR?

    That SS0-3 trigger was also and originally configured to post an interrupt, sequence complete for what ever reason. I had to use another sequencer first 2 than 1 because there was some kind of hardware issue and documented errata with sequencer 3. In that with you I agree there might be a monkey inside the die looking for a banana.

    Find it difficult to point a finger at the Stellaris group when the debug simulation is not correctly processing the data received from the XDS100 emulator even with a reduced JTAG speed setting. The steps needed to reproduce this issue were posted in the Stellaris link. Two CCS5 screen shots showing the debug behavior in the yellow high lighted bars being asserted for the wrong register SS0-0 when SS0-1 was asserting code. The absence of any FIFO full or empty flag change was typical for sequencers 1-3. Source stepping code that should assert sequencer 1 was actually asserting sequencer 0 register status changes. The SS0-1 FIFO empty & full flag being (if) tested remained always as (empty 1) for any tested sequencers 1-3 even for a sequence ((full) guessing) but the source stepping would conditionally branch as if the flag was true. Sequencer 0 was toggling both empty & full flags upon source stepping code for SS0-1. Sequencer 0 was configured trigger an hardware interrupt when PWM0 counters reach zero and all the PWM generators Debug switch are set to Run when JTAG connected. That PWM0 interrupt would explain some of the random yellow highlight but not all, especially when source stepping code not related to unrelated ADC registers.