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.

Hardfault error while accessing GPIO, again

Genius 3300 points

1. This is code which I have written , code goes into hardfault.

SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOF);
while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOF)));
GPIOPinTypeGPIOOutput(GPIO_PORTF_AHB_BASE, GPIO_PIN_1);
while(1)
{
GPIOPinWrite(GPIO_PORTF_AHB_BASE,GPIO_PIN_1, GPIO_PIN_1);
SysCtlDelay(13333333);
GPIOPinWrite(GPIO_PORTF_AHB_BASE,GPIO_PIN_1, 0);
SysCtlDelay(13333333);
}

2. If I do my APB bus, then no error.

3. Without library it was solved earlier here:

e2e.ti.com/.../407965

  • Hello Vindhyachal,

    To access the GPIO via the AHB base address, it must be ensured that the SYSTCL.GPIHBCTL register bit be first set before doing the AHB access.

    Regards
    Amit
  • Hi Amit,
    My small group has made (past) use of the AHB bus - I have NO recollection of our having any awareness of: "SYSTCL.GPIHBCTL register bit being (earlier) set!" (such usage w/LX4F (via StellarisWare 9453) 

    Might this (tad obscure) "bit management" have been "automated" w/in that past StellarisWare - or is this a requirement enforced by the newer MCUs?   Does this guidance appear anywhere w/in the MCU manual?    Thank you.

  • Hello cb1,

    My mistake, forgot to add the "O" in the register name SYSCTL.GPIOHBCTL. I believe this was added in the TM4C123 before migrating the GPIO to full AHB bus on the TM4C129.

    Regards
    Amit
  • Hi Amit,

    Thank you - again we definitely "succeeded" w/AHB bus - and had "no knowledge whatsoever" of such an obscure, "bit-set requirement."

    For others here - is this point listed (anywhere) w/in the MCU manual - so that others may avoid this, "trapped by obscurity" plight?

    I note that o.p. mentioned "not using library" - perhaps this (obscure) bit is (properly) handled w/in the "normal API" - shielding the user from such "fine detail."

  • Hello cb1

    This method during the LM3 to TM4 transition was very much debated. It was meant to provide a seamless transition of SW, but not meant to clearly demarcate the new development.

    Regards
    Amit
  • Hi Amit,

    1. As you can see in original post I had already used a function : SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOF);
    which sets the GPIOHBCTL.
    I have checked the same in keil's system viewer also. Bit gets sets properly.

    2. Although if I use , system works fine without any problem.
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOF)));
    GPIOPinTypeGPIOOutput(GPIO_PORTF_BASE, GPIO_PIN_1);
    while(1)
    {
    GPIOPinWrite(GPIO_PORTF_BASE,GPIO_PIN_1, GPIO_PIN_1);
    SysCtlDelay(13333333);
    GPIOPinWrite(GPIO_PORTF_BASE,GPIO_PIN_1, 0);
    SysCtlDelay(13333333);
    }
  • You may wish to download (ancient) StellarisWare 9453 - and see how that (past) library managed the AHB bus.

    We did not comply (knowingly) - ever/at all - with the "obscure bit set" suggested here - yet our scope revealed increased GPIO output speed.   (indicating that we had - indeed - successfully transitioned to "fault-free" AHB bus...)   Your review of that library may describe a means to "automate/avoid" such obscure settings...

  • Hello Vindhyachal,

    I too saw the same thing and got confused. When SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOF); is called the function SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); still needs to be called. Using the former function shall only set the bit for AHB bus access. The latter function is required to enable the clock to the peripheral and only then AHB bus access can be performed.

    Regards
    Amit
  • Thanks Amit,

    it is working now. I have done like this,


    SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOF);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOF)));
    GPIOPinTypeGPIOOutput(GPIO_PORTF_AHB_BASE, GPIO_PIN_1);
    while(1)
    {
    GPIOPinWrite(GPIO_PORTF_AHB_BASE,GPIO_PIN_1, GPIO_PIN_1);
    SysCtlDelay(13333333);
    GPIOPinWrite(GPIO_PORTF_AHB_BASE,GPIO_PIN_1, 0);
    SysCtlDelay(13333333);
    }


    Actually I have restarting learning TM4C mcus. As you can see my previous post was abt 5 months ago.
    Earlier I had thought of direct register accessing method. But I found that it was too cumbersome.
    Now I have decided that for initialization I will use libs. But after that in code, I will use direct accessing because of speed issues.
  • Hello Vindhyachal,

    One forum user away from the DRM is one more small victory. The DRM is cumbersome when it comes to writing professional applications. A lot of time spent identifying the register and bit and more mistakes in coding and debugging.

    Regards
    Amit
  • May I suggest that poster, "Accomplish the code mission" first (always) w/the library - and only (then) attempt DRM version. Modern C compilers - in many cases - will come close to DRM in execution speed.

    Should poster be w/in "profit making/seeking" community - time to market proves most critical. DRM (worse still - ASM) insures that you arrive LATE - when profits are minimized & (early/advanced) (i.e. library using) competitors have "eaten" the rich/rare/bulk EARLY Arrival profits...