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.

No privileged mode in main()

Other Parts Discussed in Thread: AM3359

Board: BBB, A6 with processor XAM3359AZCZ100
AM335X_StarterWare_02_00_01_01
CCSv5.5, Windows7
XDS100v2
linker command file: AM3359.cmd


Hello everybody,


when creating a new empty project and loading the .out-file with the debugger (CCSv5.5) the core is in user
mode, not privileged mode as stated in the StarterWare User Guide. That prevents me from writing to some
hardware registers (pin multiplexing).
I would not mind calling CPUSwitchToPrivilegedMode(), but that function does not return.
Most likely the problem has something to do with the way the project is created, because the example project
gpioLEDBlink starts in privileged mode.

So the most important question is how to make a project that starts in privileged mode.
Alternatively, how can CPUSwitchToPrivilegedMode() be called reliably? (setting an interrupt vector somewhere?).

Any help is highly appreciated.

Thank you.

Martin

  • Moving this to the Starterware forum.
  • Martin,

              The mode (user/prev) is set by the startup code which runs before you get the control to main().

              In StarterWare this is configured in init.s file (present in system config lib). But while creating ccs project seems the this file is not getting included and ccs takes its default configuration which might set the mode to user mode.

              I guess you have not linked system_config lib from StarterWare- can you check and confirm this ?

    The following links might help you,

    http://processors.wiki.ti.com/index.php/StarterWare_Project_Creation

    http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Environment_Setup#TMS470_from_CCS_project

    Regards

    Baskaran


  • Hi Baskaran,

    thanks for your response.

    Yes, it is linked.
    The following path had been added to the linkers search path,
        "C:\Pr\TI\AM335X_StarterWare_02_00_01_01\binary\armv7a\cgt_ccs\am335x\system_config\Debug"
    Besides that
        "${SW_WURZEL}\binary\armv7a\cgt_ccs\am335x\system_config\Debug\system.lib"
    had been added to the "Include library file or command file as input" window.

    In the system project (where the library is created) is a file 'init.asm' (not init.s).
    It contains code to switch to privileged mode.

    Trying to set a breakpoint at 'Entry' (in the final project) is refused as 'Entry' cannot be resolved. According to the .map file,  the .txt section  does not seem to contain code from init.asm.


    Meanwhile I found an interesting thread at
        http://e2e.ti.com/support/arm/sitara_arm/f/791/p/207053/735133.aspx#735133.
    But I can't see how it can help me.

    Regards,
    Martin

  • Martin,

               Thanks for confirming that you are linking system_config lib. Can you let me know which linker script file (.cmd) are you using ?

               You need to use the one that comes with StarterWare package  \\build\armv7a\cgt_ccs\am335x\<board>\<example app>\

               This ensures the Entry symbol is linked.

    Regards

    Baskaran

  • Hi Baskaran,

    I had been using
    C:\Pr\TI\CCS\ccsv5\ccs_base\arm\include\AM3359.cmd

    Now that I am using gpioLEDBlink.cmd, A8 is in privileged mode.
    Thank you very much for your fast response and the precise support information. That solved the problem.

    One more remark:
    Switching from privileged to user mode is ok.
    But using CPUSwitchToPrivilegedMode() to switch back to privileged mode is not (I watched CPSR in the registers window) . However, the function at least
    returns.

    Regards,
    Martin

  • Martin,

               Regarding CPUSwitchToPrivilegedMode(). Actually the code for this API is correct and it is working correctly.

               The debugger typically relies on svc_handler for its operations. And we also rely on this handler for switching back to privilege mode. So during debug process the debugger takes control and the expected behavior is not seen. you can confirm this by 2 methods,

    • Run the code standalone (with out debugger connected)
    • Before executing CPUSwitchToPrivilegedMode() from CCS, do free run (menu -> run -> free run). In this case CCS wont use svc_handler and you can see the expected mode change. I confirmed this by free run for below code. and when the control hits while(1), the system is in svc mode.

     CPUSwitchToUserMode();
     CPUSwitchToPrivilegedMode();
     while(1);

    regards

    baskaran

                

  • Hi Baskaran,

    how would I proof that the CPU really is in priviledged mode when it reaches the while(1) loop?
    Now with the new command file, CPUSwitchToPrivilegedMode() also returns in debug mode.

    Thanks!

    Regards,

    Martin

  • The API will definitely return but the mode will be changed to privilege mode. To confirm you need to check the mode in cpsr register.

  • Hi Baskaran,

    sorry, my question has not been precise.

    I am aware that CPSR has to be checked. But how is that register accessed from C/C++?
    Is it mapped to memory? I did not find any hint in the manual.

    Thank you!

    Martin

  • it is not memory mapped. You can use the below code to read the cpsr reg.

    unsigned int CPUReadCpsr(void)
    {
        asm("    mrs     r0, CPSR");
    }

    the return value from this function will have the contents of cpsr.

    Regards

    Baskaran

  • The function works fine, but the compiler complains about a missing return statement.

    Is there a chance for suppressing this warning for just that one function?

    Thank you!

    Regards,

    Martin