• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 22 subscribers
  • Views 1145 views
  • Users 0 members are here
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

start debugging at 0x00000000.... why?

J. M. R. Bressán

Hello, I'm starting using the uVision3 and I want to know how to start running from the address that I want.

I have a board which is similar to the Revely100ms, that's why I've created a new project and choosen the LH75401. My board has an external ROM which is located at address 0x40000000. I want to start debugging from this address, and each time I choose Start Debug Session, the pointer starts at 0x00000000 and I have to move the PC manually at 0x40000000. When I've just moved the PC at this location, and I try to execute my "helloWorld"

*** error 65: access violation at 0x4400000C : no 'write' permission
.... Then I got to open "Debug/Memory Map" window and add my external RAM too (located at 0x44000000) each time I enter in debug mode because it doesn't remember the already done settings. Ahp, I've added the memory areas in the "Options for Target 'Target1'" and in the Linker tab I've checked the item "Use Memory Layout from target dialog". What can I do?

Parents
  • 0

    An ARM always starts executing at address 0. In real life, without the benefit of an emulator to change the PC, you're going to need some valid code at that address when the system is powered on. Most likely that code will be "jump to 0x44000000". (Perhaps your variant has a way to alter the start address?)

    Since that's also where the interrupt vector table lives, most of the ARM systems I've worked with alias the ROM to both 0 and some other address, and the memory controller gets reprogrammed during boot to swap the ROM out of address 0 and swap in RAM instead. This gives you writable interrupt vectors at address 0, at the cost of some address decoding complexity.

Reply
  • 0

    An ARM always starts executing at address 0. In real life, without the benefit of an emulator to change the PC, you're going to need some valid code at that address when the system is powered on. Most likely that code will be "jump to 0x44000000". (Perhaps your variant has a way to alter the start address?)

    Since that's also where the interrupt vector table lives, most of the ARM systems I've worked with alias the ROM to both 0 and some other address, and the memory controller gets reprogrammed during boot to swap the ROM out of address 0 and swap in RAM instead. This gives you writable interrupt vectors at address 0, at the cost of some address decoding complexity.

Children
  • 0 in reply to Drew Davis

    Mhhh, "you're going to need some valid code at that address when the system is powered on" sounds ok. But I've worked with MULTI (GHS) and CrossStudio (CrossWorks) and when I specify each section and it's placement, then the program starts executing at the real position, not at 0x00000000. So I can watch all the code in the real position. And I didn't have to do any "jump code". That's why asked so. But If there's no other solution... the yours fits just fine :-)

    But... how can I save that information about each memory and it's access' permissions? (I'm talking about the last question I did in the previous post)

    Thanks in advance.

  • 0 in reply to Drew Davis

    Well, now I'm using an ini file in which I place the debug commands specifying the memory regions and their access' permissions.

    Now I got another question... Is there any way to make a download with a wiggler connection?

    Thanks.