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.

  • Resolved

Cause of hard fault from precise data bus error?

Hello,

I am working with an LX4FS1A on an eval board. I'm running a command line application through the USB port using the CDC Device Class. The program runs fine until I issue a specific command that should enable the PECI0 peripheral. The program enters the FaultISR 100% of the time when the following line is executed within GPIOPinConfigure(GPIO_PJ6_PECITX):

//
// Write the requested pin muxing value for this GPIO pin.
//
HWREG(ulBase + GPIO_O_PCTL) = ((HWREG(ulBase + GPIO_O_PCTL) &
                                                                      ~(0xf << ulShift)) |
                                                                       ((ulPinConfig & 0xf) << ulShift));

The GPIO_PJ6_PECITX passed in is 0x00081801. Here is what I have learned from some NVIC bits:

The forced hard fault is set:

NVIC_HFAULT_STAT_FORCED      1     Forced Hard Fault

There is a precise data bus error:

NVIC_FAULT_STAT_PRECISE     1     Precise Data Bus Error

The bus fault address is:

NVIC_FAULT_ADDR      0x4003D52C          Fault Address

But there is nothing in memory at that address:

0x4003D52C        00000000             00000000             00000000             00000000             00000000             00000000

The program counter is:

PC 0x0000668A Program Counter [Core]

Memory around this address:

                           $C$L3
                           46014770 88898848 4001EA40 60024770
                           210060C1 60416081 F7FF4770 4770B96B
0x00006688    NmiSR, $C$DW$L$NmiSR$2$B, $C$L1
0x00006688    E7FEE7FE
                           IntDefaultHandler, $C$DW$L$FaultISR$2$E, $C$DW$L$IntDefaultHandler$2$B, $C$L3
                           2204E7FE F102FB11 47705840
                          GPIOPinWrite
                          FB112304 5042F103 B5084770 FFCFF7FF
                          BD08B2C0
                          IntMasterEnable

It may be noting that I have a similar project that uses the UART for the communication instead of USB and I do not get this error. There is not too much different between these two projects, so I can't seem to find what is causing the hard fault. I have been banging my head against a wall for some time now. Any help would be appreciated.

Thanks,

Casey

  • My first thought is that the GPIO Port J peripheral has not yet been enabled.  The fault address (0x4003D52C) is the Port Control register for Port J.  Before writing to this register, GPIO port J should be enabled (using a call to SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ)).

    --Bobby

  • In reply to Bobby Bradford:

    You're right, it would probably be a good idea to enable the port before trying to use it... oops.

    This fixes the problem, thanks!

  • Guru 11940 points

    In reply to Bobby Bradford:

    Bobby Bradford

    My first thought is that the GPIO Port J peripheral has not yet been enabled.  The fault address (0x4003D52C) is the Port Control register for Port J.  Before writing to this register, GPIO port J should be enabled (using a call to SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ)).

    --Bobby

    Is this really the case ?

    Interesting to know. My experience with Cortex M controllers of other vendors told me that accesses to peripherals in off-state mostly go by silently.

  • In reply to f. m.:

    The peripheral implementation is up to the manufacturer, and really has nothing to do with whether or not the microcontroller has a Cortex-M or other processor family at its core.

    In all Stellaris devices (as of 12/20/12), if you access a peripheral register when clocking is not enabled for that peripheral, you will get a fault.

  • Guru 11940 points

    In reply to slandrum:

    The peripheral implementation is up to the manufacturer, and really has nothing to do with whether or not the microcontroller has a Cortex-M or other processor family at its core.

    But with the implementation of the vendor - that's why I asked.

    Such accesses never threw a hardfault on STM32 or LPC1xxx controllers I dealed with.

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.