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.

TM4C123GH6PM: Pointer is assigned an incorrect value

Part Number: TM4C123GH6PM


Hello everyone,

I'm using Keil v5. 
I have this piece of code, which works fine, but when put it in a loop I get Hard Faults, caused by memory issues. Increasing stack and heap doesn't help. Inside while(1) I have this function, which calls a couple of other functions, and the last instruction of the last function, called by the function, has *returnValue = sum (an example). The thing is that returnValue = 0xA0007C70, which can't be valid on my 32KB uC. If I remove that, I have memcpy after the function, which is going to fail (if I remove that memcpy, no errors, but everything is useless).  

There are other lines inside while(1), but when I had only the function, increasing stack and heap helped.

This kind of errors had made me redo everything, but last time I had issues where memcpy was copying wrong values. I would get insanely large values, where I expected something between 0 and 1.

What is causing these memory problems? I'm running at 80MHz, could that be the problem? Or is it something in the startup?

EDIT: Well, changing it to 40MHz did not help...

  • May it be asked, "Why - a returned value (sum - in your example) - is believed to be "restricted" - on (or by) your 32KB µC?

    I must note that firm/I (often) encounter "returned values" - far in excess of our (even smaller memory capacity) - ARM MCUs. (some of these being 16KB)

    The fact that MCU memory may be limited - to my knowledge - places little restriction upon general, "returned values!"      

  • Hey,

    returnValue is a pointer, it points to a nonexisting address.

  • That would (then) be a problem.      (I just noted:   " *returnValue = sum")

    Without seeing your (earlier) management of the erring function - I'm unable to fully assist...

    As your code is described as a "recurring loop" - and should the error (always) be an illegal pointer value (too high)  -  might that suggest an improper or inadequate  "clearing of key variables"  and/or an unexpected variable or function, "roll-over?"

    What happens if you "seed your erring function" with known, very small values?      Are the illegal pointer addresses (still) produced? 

    And - have you allowed "memcpy" sufficient time to "complete?"      It would seem useful to perform a,  "Step by Step" monitoring of the function's performance - looking very closely  (ever so closely) for the, "Onset of an illegal value."

  • Thanks,
    I was just about to post that in the main() my non-initialized integer had value different than 0, which I haven't noticed. And then delete the post. But before that I wanted to ask, since I had many issues with memory, do you think they are, ever, just hardware/compiler fault?

  • Please go back to my last post -  our posts just crossed -  during which time I've slightly expanded mine - and which (may now) describe conditions which caused your issue - and in fact may resolve - as well.  

    I firmly believe that a proper "KISS-based" approach - in which you input, "small, known values" and look carefully for the  VERY FIRST, "illegal processed value to result" - will guide you to success.    

    Such is a standard KISS process - and most always - provides a fast/safe,  "Train to Success!"

    Wish you well...

  • Savo Pejovic said:
    I was just about to post that in the main() my non-initialized integer had value different than 0, which I haven't noticed.

    Why would you expect it would be zero?

    Savo Pejovic said:
    But before that I wanted to ask, since I had many issues with memory, do you think they are, ever, just hardware/compiler fault?

    User and user designed hardware first. Micro and compiler a very distant second.

    Robert

  • Robert Adsett said:
    User and user designed hardware first.

    Indeed - especially so when,  "User designed"  is "code" for:  "Rushed, Parts on hand, Exceeding Spec... "

    Your use of,  "A (very) distant second"  absolutely  "nails it!"