• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 29 subscribers
  • Views 776 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.

Enabling PortK for GPIO outputs on EKS-LM4F232 using CCS5.1

John Osen
Genius 3585 points

I am trying to use some unused pins on the EKS-LM4F232 eval kit.  See the code below for specifics.  I have two questions:

1) There is not much on PortK in the UG.  What am I doing wrong?

2) The comments in FaultISR indicate that by looking at the system state, I can deduce what the fault was.  How do you do that?  The UG references [HMBU]FAULTSTAT, but I am not finding them in the register window.

I also get while loading:

CORTEX_M4_0: Trouble Reading Memory Block at 0x400ff000 on Page 0 of Length 0x4: Debug Port error occurred.  Is it possible the memory map is incorrect?

-----------------------------------------------------------------------------------------

// Enable the port and enable PK0-3 as outputs

SYSCTL_GPIOHBCTL_R = 0x20;

GPIO_PORTK_DIR_R = 0x0F;

GPIO_PORTK_DEN_R = 0x0F; 

// this last line jumps to

startup_css.c:

//*****************************************************************************

//

// This is the code that gets called when the processor receives a fault

// interrupt. This simply enters an infinite loop, preserving the system state

// for examination by a debugger.

//

//*****************************************************************************

static void

FaultISR

(void)

{

//

// Enter an infinite loop.

//

while(1)

{

}

}

 

  • 0
    Guru 117855 points

    John Osen said:
         SYSCTL_GPIOHBCTL_R = 0x20;    // Enable the port and enable PK0-3 as outputs 

    Suggest that you check the following:

    a)  The GPIOAFSEL register is the mode control select register. If a bit is clear, the pin is used as a GPIO and is controlled by the GPIO registers.

    Is it possible that this port defaults into other than GPIO mode?  Advice above allows your review.

    b)  No delay is evident between SYSCTL...  and following instruction to that same port.  Datasheet asks for 3-5 clock delay post SYSCTL... instruct.

  • 0 in reply to cb1_mobile
    Genius 3585 points

    Thanks for the reply.

    I am basically duplicating the blinker demo (the simplest demo there is) but rather than using PG2 in the example, I am using PK0 and have just added my on LED to the EKS-LM4F232.  This may be a debugger issue and not a Stellaris issue.  My additional comments/questions

    1) your a) above led no where, I clear the bits now with no change

    2) for my current code (below), the first time I run the app in the debugger I end up at the fault ISR in a forever loop.  I then stop the app and restart.  The second time through I get to my main loop and the LED is blinking.  Why should the first time through after starting a debug session gag, and the subsequent runs work?

    3) In the register window, I cannot see anything for any PORT register.  Why is that?  This is a major function of the debugger.  (I am using CSS 5.1).  How do I look at PORT registers?

    4) When I do get to the main code, I replicate the write to PG2 for PK0.  At the instruction the writes or clears the bit, the debugger just hangs.  Stepping into, out of changes nothing in the debugger.  Your PC bluish arrow just stays at the instruction

    GPIO_PORTK_DATA_R &= ~(0x01)

    5) your b) above refers to a delay.  I do not see such a delay mentioned for this register.  I found delays mentioned for other registers.  Would you point me to where this delay is specified?

    6) I still cannot figure out how to find what fault got me to the fault ISR.  How do I figure that out?

  • 0 in reply to John Osen
    Guru 117855 points

    John Osen said:
    I clear the bits now with no change

    If these bits are clear (w/in AFSEL Reg) your port is configured for GPIO operation which is your desire.

    John Osen said:
    Why should the first time through after starting a debug session gag

    Very carefully read & understand your start-up file and related mechanisms.  Are you configured to execute start-up and run to "main?"  Appears that some initialization has been missed or improper on your "failing" 1st run.  Firm/I use paid IAR - unfamiliar with CCS.  (and we work with other ARM MCUs - not supported by CCS)

    John Osen said:
    I cannot see anything for any PORT register.

    W/in IAR - when the Register Window is open - we can select from among multiple GPIO Ports (both AHB and APB) - see if yours works in that manner.  Further - if you have not properly clocked/enabled these other Ports no valid data will be available.

    John Osen said:
    I do not see such a delay mentioned

    Delay questioned must follow SysCtlPeripheralEnable() function.  Your basic blinky program should show this - certainly your StellarisWare DRL-UG does.  As your Port "K" is fast/high performance - this may be especially susceptible to failure to provide adequate delay between the time you enable a port and then access it...

    Both this forum and Joseph Yiu's book, "Definitive Guide to Cortex M3" explain Fault ISR resolution methods.  #1 suspect is failure to initialize a peripheral before its access...