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

NVIC_Hard_Fault in Reserved Memory

Serkan
Intellectual 800 points
Other Parts Discussed in Thread: TM4C123GH6PM

Hello Everyone

In my project, I am getting Precise Data Bus Error and Bus Fault Adress Register Valid faults.

I read Diagnosing Software Faults in Stellaris® Microcontrollers document. I looked at the NVIC_FAULT_ADDR shows 0x41000000. This memory adress is reserved in Tiva TM4C123GH6PM MCU. 

I understand in app note that for wrong accesing peripherals gives this error and we can see by looking at the related register. But in this case I mean if the problem is related with the reserved memory location, What should I do ?

For 3 days, I am searching forum to get general understanding but I couldnt yet.

Thanks in advance

Serkan

  • 0
    Guru 11940 points

    I understand in app note that for wrong accesing peripherals gives this error and we can see by looking at the related register. But in this case I mean if the problem is related with the reserved memory location, What should I do ?

    Simple - not accessing reserved areas.

    'Reserved' in this context means not used or not implemented on this device, but possibly on later one's. I'm pretty sure the manual says "DO NOT ACCESS RESERVED AREAS". The address range you mentioned is "empty", i.e. there are no peripherals - the fault is a logical consequence.

  • 0 in reply to f. m.
    Intellectual 800 points
    Hello f.m

    Thanks for ur reply. You are right.

    So, How should I draw on this problem ? What steps should I do ? Because there is a problem that causes and makes code enter Fault_ISR because of NVIC_FAULT_ADDR 0x41000000.

    Regards

    Serkan
  • 0 in reply to Serkan
    Guru 11940 points

    I don't know your code, but I guess it fails when trying to initialize non-existing peripherals.

    If it's not obvious from the datasheet or comments in the code, I would single-step through the application in the debugger. If it's not a direct issue (writing to a non-existing peripheral register), things might get more complicated, and the fault happen at "run time" (during cyclic operation). Common sources here are stack overflow, access to run time calculated addresses (like array indices), DMA buffers on stack, or DMA increment on peripheral addresses.

    Presenting some code might be helpful. (I am not a TM4C expert myself, though ...).

  • 0 in reply to f. m.
    Intellectual 800 points
    Hello f.m

    I am sure about there is not related with peripheral initilizating. Bacuse my code enters ISR after some time. It becomes randomly.

    As u said maybe I should look at stack overflow and other issues.

    Serkan
  • 0 in reply to Serkan
    Guru 11940 points

    There is also the "backward" way. Catch your application with the debugger in the fault handler, and read the system registers to get some indication what happened, and where. Didn't have to do it myself the last month, so I can't cite the appropriate registers and status flags by heart ...

    But in case of a stack overflow, this might lead nowhere, because the fault context changes every time. If your IDE (or RTOS, if you use one) has some stack-check option, enable them. But stack size estimation by static code analysis is nearly impossible, so don't trust your IDE / Project wizard here. Rather set a comfortable value yourself. My toolchain (Crossworks) used a default size of 128 bytes, which crashed applications quite early in the development process. Increasing this to (at least) 512 byte is one of the very first things I do when setting up a new project.