• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1258 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.

Beaglebone Pinmux Registers Appear to be Locked

vikesfan
Prodigy 170 points
Other Parts Discussed in Thread: AM3359

I have a Beaglebone (Rev A3) connected to Code Composer 5.2 using the onboard USB/XDS100v2 JTAG emulator.  I've run and modified several of the StarterWare examples such as gpioLEDblink and UARTecho.  I'm now trying to enable the GPMC interface to the P8 expansion header for interfacing to an FPGA.  I'm able to successfully configure most of the internal AM3359 registers (GPMC_CONFIGx, etc.) but an unable to change the values of the pin muxing registers for the GPMC interface (CONF_GPMC_AD0, etc.).

The code I'm using is copied from the NANDPinMuxSetup function from the NAND libraries as follows:

HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_AD(0)) =
( 0 << CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_MMODE_SHIFT) |
( 0 << CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_PUDEN_SHIFT) |
( 1 << CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_PUTYPESEL_SHIFT) |
( 1 << CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_RXACTIVE_SHIFT);

This should be setting the CONF_GPMC_AD0 register (0x44E10800) to a 0x00000030 (Mode 0).  However when I look at the value at that location via the memory viewer in the CCS debugger, I see the value is: 0x00000027 (Mode 7).  I thought perhaps the debugger is causing a reset of the board when the code halts which would change the value to a initial condition, so I added a read of the CONF_GPMC_AD0 register immediately before and after the above write and the value doesn't change from the 0x27 (Mode 7) value.

Is there a way these register can be "locked" from modification?  Is there anything else I should be checking?  Thank you.

  • 0
    Expert 1120 points

    They can appear locked if you're in user mode. You need to be in privileged mode to be able to change those registers.

  • 0 in reply to Frank Van Hooft1
    Prodigy 170 points

    Frank,

    Thank you for your reply.  I did verify that I was in user mode.  Changing to Priviledged or Supervisor Modes allowed me to change these pinmux register values.

    One thing I discovered in my troubleshooting of this issue.  In Code Composer, when I connect to the target (beaglebone in this case), the ARM core stays in Privildged mode.  When I Load a Program, the ARM core is sometimes placed in user mode.  If I import a project from one of the StarterWare examples, compile and load that program, the ARM core remains in priviledged mode.  If I create a new CCS project, copy over the same code, compile and load the program, the ARM core is placed in user mode.  I'm assuming there's somethin in the "cinit" code that gets executed prior to main() that setting this to user mode.  I haven't had a chance to dig into this yet.  Does anyone else have some insight on this?

  • 0 in reply to vikesfan
    TI__Guru* 86820 points

    I think what is happening is that when you create the new project, you are using the original rts library that comes with CCS, which puts the processor in user mode before getting to main().  You can see this in boot.asm.  I believe Starterware is using its own cinit code which has been modified to stay in privileged mode.

    Regards,

    James

  • 0 in reply to JJD
    Expert 1120 points

    To follow-up on what James said, the starterware code examples I've played with do configure the processor into user mode, in the cinit code. This has obviously caused problems for some of those examples, and hence somebody at TI wrote a "hack" to get around that problem for one of the starterware examples. The hack is the file super_startup.asm, which simply jumps over the first few bytes of the cinit code (which the author obviously knew was where the processor is put into user mode). Not pretty, but it works, at least in this case, and I've used that file in some of my own test code. I wouldn't suggest using it for production code, because if the cinit code changes, super-startup.asm may not work any more. Changing boot.asm would probably be a safer bet.