• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 11302 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.

Cause of hard fault from precise data bus error?

Casey Anderson
Prodigy 40 points


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

  • 0
    TI__Genius 10040 points

    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

  • 0 in reply to Bobby Bradford
    Prodigy 40 points

    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!

  • 0 in reply to Bobby Bradford
    Guru 11940 points

    Bobby Bradford said:

    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.

  • 0 in reply to f. m.
    Mastermind 9890 points

    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.

  • 0 in reply to slandrum
    Guru 11940 points

    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.