Problems writing to Kick registers in CSLR Gpio_example

OK folks. I am picking my way through the TI maze of documentation hodgepodge and have found the following possible scenarios.

1. The DSP must not be in supervisor mode since I cannot write to the Kick registers.

2. The ARM appears to be in supervisor mode since his CPSR.M = 0x13. So, how do I get the DSP into supervisor mode??

3. The OMAP-L138 System Reference Guide (sprugm7d, p49) says:

ARM and DSP CPU instruction and data accesses have a privilege level associated with them. The

privilege level is inherited from the code running on the CPU. See the TMS320C674x DSP CPU and

Instruction Set Reference Guide (SPRUFE8) and the ARM926EJ-S Technical Reference Manual (TRM),

downloadable from http://infocenter.arm.com/help/index.jsp for more details on privilege levels of the DSP

and ARM CPU.

4. So looking at sprufe8, page 704, I find the following in section 8 "CPU Privilege"

8.2.2 Execution Mode Transitions

Mode transitions occur only on the following events:

• Interrupt: goes to Supervisor mode and saves mode (return with B IRP instruction)

• B IRP instruction: returns to saved mode from interrupt

• Nonmaskable interrupt (NMI): goes to Supervisor mode and saves mode (return with B NRP

instruction)

• Exception: goes to Supervisor mode and saves mode (return with B NRP instruction, if restartable)

• Operating system service request: goes to Supervisor mode and saves mode (return with B NRP

instruction)

• B NRP instruction: returns to saved mode from NMI or exception

Huh??? "mode transitions occur"???? How do I MAKE mode transitions occur? Or, *do I* want to make a mode transition occur?? All I want to do is write to the Kick registers. How do I do this??

Thx,

MikeH

MikeH said:

All I want to do is write to the Kick registers. How do I do this??

Mike, a Power On Reset (POR) to the device will put the CPU in privledged mode. You should be able to write to the KICK registers post a POR. The code shows this, as it writs to the kick registers immediately in Main.c.

Does the example code not run in your board? If the example code runs, this means that the KICK registers were unlocked and the PINMUX was set up.

Mike,

The ARM-side rCSL examples here also demonstrate how to enter Supervisor Mode: http://processors.wiki.ti.com/index.php/QuickStartOMAPL1x_rCSL

-Tommy

Mike

Are you sure the DSP is not in supervisor mode? Typically if you are using DSP/BIOS, it will never automatically put DSP in user mode. A quick way to confirm whether DSP is in user or supervisor mode would be to look at the TSR register (CPU register window in CCS), the TSR bits 7:6 will tell you the DSP state , user vs supervisor

TSR register definition on Pg 57 in the following guide

http://focus.ti.com/lit/ug/sprufe8b/sprufe8b.pdf

Rgds

Mukul

Drew,

I am working with an OMAP-L138. I am under the impression that after a power-on reset the ARM is the supervisor, which is what I find in the ARM CPSR.M register:

2. The ARM appears to be in supervisor mode since his CPSR.M = 0x13. So, how do I get the DSP into supervisor mode??

I have just tried a power-on reset of my board and the kick registers values do not change when I write to them from the DSP code. The procedure I am using is:

1. Power off/on the board.

2. Connect to the ARM processor, load it's initialization code, run the init code (sets up peripheral devices like DDR).

3. Connect to the DSP, load the Gpio_example.out file. Begin stepping through the code while watching the KICK0R and KICK1R registers. The values do not change when I execute the following code:

    /* Key to be written to enable the pin mux registers for write            */

    sysRegs->KICK0R = 0x83e70b13;

    sysRegs->KICK1R = 0x95A4F1E0;

Mukul,

Here is what I find in TSR.

TSR = 0x00000000

_RESV = 0x0

IB = UNBLOCKED (0x0)

SPLX = NOTEXEC (0x0)

_RESV = 0x0

EXC = NOTEXEC (0x0)

INT = NOTEXEC (0x0)

_RESV = 0x0

CXM = SUPERVISOR (0x0)

_RESV = 0x0

DBGM = EMU_ENABLE (0x0)

XEN = DISABLE (0x0)

GEE = DISABLE (0x0)

SGIE = 0x0

GIE = DISABLE (0x0)

The CXM (bit 7:6) indicate that DSP is in supervisor mode, so DSP not being able to configure kicker registers being in user mode is not your issue. Can you make sure your intialization code from ARM side is not already writing to kicker registers, if that is the case then writing it again from the DSP side might be causing it to lock out the SYSCFG registers.

Following post might help

https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/29241.aspx

This is assuming you have OMAPL138 silicon that PG1.1/PG1.0.

Regards

Mukul

When I run the rCSL GPIO example that is provided in the PSP package, I see the value of zero for the KICK0 and KICK1 registers in the memory window (even when I write values to unlock it).  However, the PINMUX registers do get unlocked.

Assuming you are running the same program, you can try the following steps to confirm if the PINMUX registers are locked/unlocked.

• Set a breakpoint before the KICK register unlock sequence
• Open a memory window to confirm that you can't write to a PINMUX register (e.g. PINMUX1 is 0x01C1 4124)
• Set a breakpoint after the KICK register unlock sequence and run to the breakpoint
• You should be able to write to the PINMUX registers now

One thing I noticed is in this code...

sysRegs->PINMUX1 = ((CSL_SYSCFG_PINMUX5_PINMUX5_7_4_GPIO2_14)
                         << (CSL_SYSCFG_PINMUX5_PINMUX5_7_4_SHIFT));

I see that you are trying to set PINMUX5 values, but you are writing to PINMUX1 register.  Is that the source of the issue?

--Christina

Wow.....lots of support today! I love it.

1. Error on my side. 

clam said:

One thing I noticed is in this code...

sysRegs->PINMUX1 = ((CSL_SYSCFG_PINMUX5_PINMUX5_7_4_GPIO2_14)
                         << (CSL_SYSCFG_PINMUX5_PINMUX5_7_4_SHIFT));

I see that you are trying to set PINMUX5 values, but you are writing to PINMUX1 register.  Is that the source of the issue?

Yes, exactly! Good eye. I just changed the PINMUX1 to PINMUX5 and can properly set my PINMUX register. I can also set each port and pin in bank 2 to the proper values. 

clam said:

• Set a breakpoint before the KICK register unlock sequence
• Open a memory window to confirm that you can't write to a PINMUX register (e.g. PINMUX1 is 0x01C1 4124)
• Set a breakpoint after the KICK register unlock sequence and run to the breakpoint

I have done this and I am still puzzles as to why I cannot see the values of the kick registers change. They always read 0x00000000 in either memory view or register view. This is moot since I *am* in supervisor mode, and *can* write to the PINMUX registers.

Unfortunately, I still have some debugging to do since I am still not generating interrupts and my GPIO pin is not changing state. 

Thx,

MikeH

All,

I am still unable to get consistent behavior out of this cslr example. I have tried this example on two different pins on my board just in case there was a hardware issue with the board. However, neither of the GPIO ports seem to be properly responding to the cslr functions.

Here is my code, with the 3 different GPIO pins commented in or out so that I could test each one.

1. GPIO bank 0 pin 7 -

The first example in each function call is the original cslr Gpio_example which exercises GPIO bank 0 pin 7. This code works and interrupts are generated. However, since this pin is not brought out on my Logic PD SOM, I could not watch the voltage level on the pin change so I changed the code to GPIO bank 2 pin 14, which I can monitor with a scope.

2. GPIO bank 2 pin 14 -

When stepping through this example I can observe PINMUX5_7_4 getting correctly set to 0x8 (GPIO2_14). However, I do not see DIR23.GP2P14 toggle to 0x0 (out). Nor do I see OUT_DATA23.GP2P14 toggle to 0x0, nor do I observe the voltage on the pin go to zero volts. So to rule out a hardware problem on my board, I changed the target GPIO pin to GPIO bank 1 pin 14.

3. GPIO bank 1 pin 14 -

When stepping through this example I can observe PINMUX2_7_4 getting correctly set to 0x8 (GPIO1_14).  However, I do not see DIR01.GP1P14 toggle to 0x0 (out). Nor do I see OUT_DATA01.GP1P14 toggle to 0x0, nor do I observe the voltage on the pin go to zero volts.

Here is my code. If you eagle-eyed folks could look this over and let me know if you see anything obviously wrong, I would greatly appreciate it.

/*============================================================================*/

/*                          FUNCTION DEFINITIONS                              */

/*============================================================================*/

 

void main (void)

{

    /* This function will configure an GPIO pin as an interrupt pin           */

 

    /* Key to be written to enable the pin mux registers for write            */

    sysRegs->KICK0R = 0x83e70b13;

    sysRegs->KICK1R = 0x95A4F1E0;

 

    /* enable the pinmux for the GPIO bank 0 pin 7                            */

//    sysRegs->PINMUX1 = ((CSL_SYSCFG_PINMUX1_PINMUX1_3_0_GPIO0_7)

//                        << (CSL_SYSCFG_PINMUX1_PINMUX1_3_0_SHIFT));

 

//    sysRegs->PINMUX5 = ((CSL_SYSCFG_PINMUX5_PINMUX5_7_4_GPIO2_14)

//                        << (CSL_SYSCFG_PINMUX5_PINMUX5_7_4_SHIFT));

 

    sysRegs->PINMUX2 = ((CSL_SYSCFG_PINMUX2_PINMUX2_7_4_GPIO1_14)

                        << (CSL_SYSCFG_PINMUX2_PINMUX2_7_4_SHIFT));

 

    /* lock the pinmux registers                                              */

    sysRegs->KICK0R = 0x00000000;

    sysRegs->KICK1R = 0x00000000;

 

    /* first enable the GPIO in the PSC                                       */

    gpioPowerOn();

 

    /* Configure GPIO0_7 (GPIO0_7_PIN) as an output                           */

//    CSL_FINS(gpioRegs->BANK[0].DIR,GPIO_DIR_DIR7,0);

//    CSL_FINS(gpioRegs->BANK[2].DIR,GPIO_DIR_DIR14,0);

    CSL_FINS(gpioRegs->BANK[1].DIR,GPIO_DIR_DIR14,0);

 

    /* set the GIPO0_7 value to 0                                             */

//    CSL_FINS(gpioRegs->BANK[0].OUT_DATA,GPIO_OUT_DATA_OUT7,0);

//    CSL_FINS(gpioRegs->BANK[2].OUT_DATA,GPIO_OUT_DATA_OUT14,0);

    CSL_FINS(gpioRegs->BANK[1].OUT_DATA,GPIO_OUT_DATA_OUT14,0);

Thx,

MikeH

Each GPIO set contains 16 pins.  However since the OMAP-L138 is a 32-bit architecture, GPIO0 and GPIO1 combined make up BANK0, GPIO2 and GPIO3 are BANK1, etc.

The GPIO header file is located here, C:\Program Files\Texas Instruments\pspdrivers_01_30_01\packages\ti\pspiom\cslr\cslr_gpio.h.  In the header file, you'll see the following:

#define GP0  0
#define GP1  0
#define GP2  1
#define GP3  1
#define GP4  2
#define GP5  2
#define GP6  3
#define GP7  3
#define GP8  4

#define GP0P7  (1 <<  7)
#define GP2P14 (1 << 14)
#define GP1P14 (1 << 30)

So, if you want to toggle GP1[14]...

CSL_FINS(gpioRegs->BANK[GP1].OUT_DATA, GPIO_OUT_DATA_OUT30, 0);

--Christina

Christina,

clam said:

Each GPIO set contains 16 pins.  However since the OMAP-L138 is a 32-bit architecture, GPIO0 and GPIO1 combined make up BANK0, GPIO2 and GPIO3 are BANK1, etc.

Then I must be totally mis-interpreting the following table from the GPIO User Guide (sprufl8b, page 12). Can you explain further?

The "BANK" register name is probably causing the confusion.  In the header file, the "BANK" register refers to the register_name under the Control Register column, not the Bank column.  From the table, you'll see that both GPIO0 and GPIO1 uses register_name01, which is BANK[0] in the header file.

--Christina

Christina,

clam said:

  In the header file, the "BANK" register refers to the register_name under the Control Register column, not the Bank column. 

Wow, that's unfortunate. EVERYWHERE else in the GPIO document "Bank" refers to the...ummm..... Bank.

I'm afraid I give up on the PSP and CSLR due to documentation deficiencies.....

Moving on the coding registers directly.

Thanks for your help.

MikeH

Hey all, 

Can anyone help me understand how do I configure the KICK registers.

I'm writing a kernel module ( am I inside supervisor mode ?!?! ) 

which writes to the KICK0 REG.

I get kernel OOPS/ CRASH ...

anyone knows why ?

Hello,

I was stuck on the same problem last year and I noticed a struct declaration error into the file "cslr_gpio.h" that belongs to the rCSL package 2.0. Look that:

If you comment these lines the address the DIR and OUT_Data regs get the right position in the memory bank. REVID and BINTEN regs are already defined into the "CSL_GpioRegs" struct.

I hope this information can be helpful to the future rCSL users.

Janio Gabriel