• State
  • Locked Locked
  • Replies 23 replies
  • Subscribers 53 subscribers
  • Views 1185 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

Example DSS Debug Server & Client not connecting

DSS writeData command

Stephen Coshatt
Prodigy 20 points
Other Parts Discussed in Thread: TMS320F28335

We have just setup up a DSS test server that is linked to a CCS instance.  When using writeData from a DSS client to set a flag, CCS pauses.  However, when we set the same flag using CCS, it does not pause.  Any idea what causes this?

Thanks

Stephen

  • 0
    TI__Guru**** 464431 points
    Stephen Coshatt said:
    When using writeData from a DSS client to set a flag, CCS pauses

    What do you mean by "CCS pauses"? Are you saying that the target is halted when the write occurs?

  • 0 in reply to Ki
    Prodigy 20 points

    Correct.  It halts.

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points

    What device are you working with? 

  • 0 in reply to Ki
    Prodigy 20 points

    The MCU we are using is TMS320F28335. The debugger is XDS100V3. Let me know if you need more information.

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points

    This device support real-time mode and should allow real-time memory access by default. When the writeData occurs, does the target remain halted or is it a temporary halt and then the target resumes quickly after? 

  • 0 in reply to Ki
    Prodigy 20 points

    It remains halted

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points

    I cannot reproduce this behavior. I have the IDE up when running test server and I do not see the target halt when a writeData command issued. The data is written successfully and the target is never halted. I did use a different device but the behavior should not vary per device.

    See my video example:

    my writeData command simply writes the value "2" to address 0x20000300. You can see that when (and after) the value gets written, the target is still running.

    Did you make any other modifications to the TestServer script besides the call to launch the IDE?

    Can you step through the test sever script via Rhino after the writeData command is executed and see if the target is halted right after the command is executed? 

  • 0 in reply to Ki
    Prodigy 20 points

    Changes were directory entries to match ours and we loaded out .out file.  I'll double check tomorrow afternoon and then get back to you.

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points
    Stephen Coshatt said:
    Changes were directory entries to match ours and we loaded out .out file.

    These changes were not made to TestServer.js, correct?

  • 0 in reply to Ki
    Prodigy 20 points

    may have been test_server.js that calls TestServer.js, but I don't have access to the lab atm.  I'll check tomorrow and verify.

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points

    Also, please check what happens when you step over the js source line when the command is executed like in my video. See if the target halts then.

  • 0 in reply to Ki
    Prodigy 20 points

    Attached is a video of the issue.  Note that we use a batch file to setup our various scripts/code.  Note in video, once we have the server running, out python code calls a short javascript file that loads our program into the devices memory.  Later when we write to a flag, (change the value from 0 to 1), the program halts and we have to hit "resume" in the top left.  

  • 0 in reply to Ki
    Prodigy 20 points

    Attached are the javascripts.  We're having some issues with Rhino.  Appears to be permission issues and are coordinating with our schools IT department.Coshatt-Files.zip

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points
    Stephen Coshatt said:
    Attached is a video of the issue. 

    Ok there are few more things happening in this video. I'll need some time to go through this.

  • 0 in reply to Ki
    TI__Guru**** 464431 points

    Note that it is a holiday here and the office is closed. I will try to take a look at this sometime next week.

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points

    Can you try adding the writeData command to the perl_load_program.pl also and see if that also results in halting the target?

  • 0 in reply to Ki
    Prodigy 20 points

    If i write from the perl_load_program.pl the value changes but the progam does not run.  If I add a run command in the script before the write, the value does not get written, nor can I write any other values either in the script or by calling another one.  Here is where things get stranger.  I run the load program script without the run or the write, but I hit run from CCS, I can write values as many times as I want, but it halts, and I must hit resume after every write.  I may try with asynchronus run later to see if that makes a difference.

    Here is the code:

    BEGIN {
        # Add the @INC path the directory where the DSSClient module is found.
        #push ("/Users/by51849/workspace_v12/Control_ACIM_F28335_v1/", "dss");
    }
    use strict;
    use warnings;
    use DSSClient;



    my $client = new DSSClient("127.0.0.1", 4444);
    my $cmd = undef;
    my $result = undef;

    # Connect to the CCS json server.
    $client->open();

    #Send commands to DSS Test Server
    #----------------

    # Connect to the target.
    $cmd = {
        "name" => "connect",
    };
    execute_command($cmd);

    # Load program to memory
    $cmd = {
        "name" => "load",
        "program" => "C:/TestBed/Control_ACIM_F28335_v1/Debug/Control_ACIM_F28335_v1.out",
    };
    execute_command($cmd);

    $cmd = {
        "name" => "run",
    };  
    execute_command($cmd);

    # Write a 32 bit value to memory
    $cmd = {
        "name" => "writeData",
        "page" => 0,
        "address" => 0x0000C00C,
        "value" => 1,
        "typeSize" => 32,
    };
    execute_command($cmd);

    # We are done now.
    #$client->close();

    # execute command
    sub execute_command
    {
        $result = $client->execute($_[0]);
       
        if (defined $result) {
            print "$_[0]{name}: ". $result->{"status"} . "\n";  
            # If there is a message, print it
            if (exists $result->{"message"} ) {          
                print "  message: " . $result->{"message"} . "\n";
            }
            # If a value was returned, print it
            if (exists $result->{"value"} ) {          
                print "  value: " . $result->{"value"} . "\n";
            }
        } else {
            print "$_[0]{name} execution failed\n";
        }
    }
  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points

    I tried a similar client script as above but I still cannot reproduce the issue. The writeData does NOT halt the target. For me, I have a timeout set so that the synchronous run returns. Then the subsequent writeData command executes correctly without halting the target.

    Any luck getting the rhino debugger to work? It would very helpful to see at which exact line in the js server script is in when you observe the target halt. 

  • 0 in reply to Ki
    Prodigy 20 points

    Yes, we've been using the debugger.  It still is not clear why the program halts after executing commands.  Do you have time to possibly setup a Zoom meeting?

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points
    Stephen Coshatt said:
    Yes, we've been using the debugger.  It still is not clear why the program halts after executing commands.

    Do you know at which line the halt occurs? Is it the same line as in my video?

    Stephen Coshatt said:
    Do you have time to possibly setup a Zoom meeting?

    I may have some time next week. I will let you know

    On a different note, we have developed a python client example. I recall you had interest in a pure python client implementation. If you wish to try it out, you can extract the attached zip into the DSS TestServer folder. Similar to the perl example, there is a client script example and a DSSClient.py file that gets leveraged.

    3872.TestServer.zip

  • 0 in reply to Ki
    Prodigy 20 points

    Will try this tomorrow morning.

    Thanks

  • 0 in reply to Ki
    Prodigy 20 points

    The python code works better than the perl code.  When we run our scripts and run our program after loading it using the rpc command (run or runAsync), the program will not accept write from the client.  If we run our program manually from the CCS console that we open, it will accept write commands and it will not halt execution as the perl scripts did.

    Any idea as to why running our program from CCS behaves differently than when we try to run it using client commands?

  • 0 in reply to Stephen Coshatt
    TI__Guru**** 464431 points
    Stephen Coshatt said:
    Any idea as to why running our program from CCS behaves differently than when we try to run it using client commands?

    On devices that support real-time memory access, the debugger can typically access memory non-intrusively. There are some special cases where memory accesses can be blocked. For example, when in a critical section of code setting the DBGM (Debug Mask) bit in status/control register will block accesses. But that is likely not the case in your environment.

    Do you get some message from the debugger about the blocked write attempt?