• Locked Locked
  • Replies 8 replies
  • Subscribers 119 subscribers
  • Views 4962 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unexpected address range accesses from bare metal code

Rich Podraza
Note: This was originally posted on 12th September 2012 at http://forums.arm.com

My test system (Carbon SoCD running a Cortex A9 model) has a memory map with entry point 0xFFFF0000, with a valid memory range from 0xFFFF0000-0xFFFFFFFF, as well as 0x50000000-0x8FFFFFFF where some stack, heap, data, etc. lives. My code is a simple dhrystone app and makes some printf calls to display the app's actions and status. However, I am strangely seeing access to low memory, reads going to 0xA or 0x38 for example. I've tried to debug where these are coming from but whatever is happening is hidden in some system library. Using the disassembly and my .map linker output I see that the code is in flsbuf.o or printf_char_common.o at the time. Depending on whether I comment out certain printf statements, the place/time the out of range access occurs is different. Does anyone have any clues as to what might be happening? Or more information that I can provide to help debug this?

If I comment out all the printfs, none of the out of range accesses occur. Also, if I adjust the system memory to be valid at those low memory addresses, the program executes and completes just fine. So I have a workaround of sorts but I want to make sure this won't be a problem for actual hardware.

Thanks,
Rich
Parents
  • Note: This was originally posted on 12th September 2012 at http://forums.arm.com


    Hmm - when I see this normally on my platforms it's because I've given printf a corrupt pointer to print as a string or something like that.

    *EDIT* One other thought is that printf can sometimes use quite a bit of stack (not sure how your version is implemented), so might be worth checking your available stack size and seeing if you underflow the low extent.


    My stack size is 0x10000 bytes or .0625 MB. Does that seem on the order of too small? Nothing exception about these printfs, less than 100 chars, 0-2 arguments each. I've checked out the argument pointers they seem valid.
Reply
  • Note: This was originally posted on 12th September 2012 at http://forums.arm.com


    Hmm - when I see this normally on my platforms it's because I've given printf a corrupt pointer to print as a string or something like that.

    *EDIT* One other thought is that printf can sometimes use quite a bit of stack (not sure how your version is implemented), so might be worth checking your available stack size and seeing if you underflow the low extent.


    My stack size is 0x10000 bytes or .0625 MB. Does that seem on the order of too small? Nothing exception about these printfs, less than 100 chars, 0-2 arguments each. I've checked out the argument pointers they seem valid.
Children
No data