• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 1084 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.

Cannot change syscfg settings

l.wittland
Intellectual 425 points
Other Parts Discussed in Thread: OMAP-L138

I am using a OMAP-L138 microprocessor and Code Composer 4.2.1.00004. Currently I am only using the ARM9 core, not the DSP.

I want to change the pinmux settings in the syscfg module. Since this requires privileged mode I changed the boot.asm to let the ARM core boot in system mode. This seems to work, as the CPSR reads 0x600000DF when entering my main() function.

However, when I try to write the KICK registers, their values are not changed (according to both 'registers' and 'memory' view), neither are any other syscfg registers - including the fault registers, which are set when I boot with the unmodified boot.asm (user mode; CPSR = 0x600000D0).

Any suggestions?

  • 0
    TI__Expert 8785 points

    Can you try running the example available in the QuickStartOMAPL1x_rCSL, http://processors.wiki.ti.com/index.php/QuickStartOMAPL1x_rCSL?

    In these set of low-level ARM program examples, it will set up the ARM into supervisor mode, as well as configure the pinmux registers. 

    --Christina

  • 0 in reply to clam
    Intellectual 425 points

    Hello Christina

    I tried to run the examples, but I had assertion failures in every OMAP138/ARM project and couldn't load them. (I use CCS 4.2.1 and Code generation Tools 4.6.4.)

    Next thing I tried was to use some of the example code in my project. It compiled and ran, but still didn't change the KICK registers. Code follows.

     

    main.c:

    void main(void) { 

      _call_swi(0);                    //Set system mode

      HW_SYSCFG0->KICK0R = KICK_OPEN;  //Should set KICK0R since are now in system mode, but doesn't even set the fault registers.

                                       //In user mode the fault registers will be set correctly.

    }

     

    main.h

    typedef struct

    {

      volatile uint32 REVID;   //Offset 0x0000 from SYSCFG0_BASE

      (...)                    //13 other registers

      volatile uint32 KICK0R;  //Offset 0x0038 from SYSCFG0_BASE

    } syscfg0_regs_t

    #define HW_SYSCFG0    ((syscfg0_regs_t *)(0x01c14000))

    #define KICK0_OPEN    (0x83E70B13)

     

    Assembler code:

    SWI_Handler:.asmfunc  //Entered after swi exception

      PUSH  {R0}

      MRS   R0, SPSR

      BIC   R0, R0, #0x1F

      ORR   R0, R0, #0X1F

      MSR   SPSR_CF, R0

      MOVS  PC, LR 

    .endasmfunc 

     

    Anyway thanks, the examples were quite helpful with some other problems I had.

     

    Yours,

       Björn

  • 0 in reply to l.wittland
    TI__Expert 8785 points

    From your code snippet, it seems like you are only writing to the KICK0 register.  To fully unlock, you'll have to also write to the KICK1 registers.

    Here is an example:

    KICK0R = 0x83e70b13; // Kick0 register + data (unlock)
    KICK1R = 0x95a4f1e0; // Kick1 register + data (unlock)

    Where KICK0R is offset 0x38 from SYSCFG0_BASE and KICK1R is offset 0x3C from SYSCFG0_BASE.

    --Christina

  • 0 in reply to clam
    Intellectual 425 points

    Hello Christina.

    > From your code snippet, it seems like you are only writing to the KICK0 register.

    > To fully unlock, you'll have to also write to the KICK1 registers.

    I know that I have to write both registers; the snippet I send was maybe a little to condensed...

     

    In the mean time I was able to solve the problem myself; it was a combination of

    -the KICK registers not beeing readable (neither the 'registers' view, nor the 'memory' view, nor a read in my code could read anything but 0x00000000). Since the documentation (sprugm7d) states these registers would be readable (which they were in a DSP program) I misbelieved they would not be written for unknown reason.

    -a typo in one of my defines, which caused me to miss the SYSCFG when I attemted to write the PINMUX registers. (the KICKs did work). When I fixed this I could set the PINMUX registers.

     

    Yours,

         Björn

  • 0 in reply to l.wittland
    Prodigy 70 points

    Hey ,

    Am I missing something ??

    I'm writing a kernel module ( that intrrupts the dsp , or at least tries to :) )

    the first thing that I'm trying to do is write to the KICK registers , but with no luck.

    the values does not change .

    I thought that kernel code is in supervisor mode and I can write the SYSCFG REG with no problem ,

    Is it true ?

     

    thanks in advacne,

    H.

  • 0 in reply to RLg
    Intellectual 425 points

    Hi RLg,

    that sounds familiar.

    RLg said:

    the first thing that I'm trying to do is write to the KICK registers , but with no luck.

    the values does not change .

    .

     

    CCS4 doesn't show the value of the KICK-Registers correctly; it always shows 0x00000000 (at least my copy does).

    Try unlocking the KICKs and then editing an other SYSCFG setting, i.e. a pinmux register. If this value changes, you've done everything right.

     

    Yours,

         Björn

  • 0 in reply to l.wittland
    Prodigy 70 points

    Hey Björn,

    thanks for your replay.

    I'm not working with CCS4 ( maybe that is my problem ).

    I wrote a kernel module ( using the example in QuickStartOMAPL1x rCSL   ). 

    this line :  CSL_FINS(sysRegs->KICK0R, SYSCFG_KICK0R_KICK0, KICK0_KEY);

    which suppose to configure the KICK0 registers crashes the kernel and it says: 
    "unable to handle kernel paging request at virtual address 0x1c14038"
    Do you have a clue why ?

     

  • 0 in reply to RLg
    Intellectual 425 points

    Hi RLg,

    I'm sorry but I'm afraid I can't help you. I ran into a lot of more or less obscure problems over the last few months, but your error message wasn't one of them.

    I think the TI staff people can help you onthis problem better then I would.

     

    Yours & good luck,

         Björn