Wednesday, April 25th 2018, 6:30am UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.



Date of registration: Dec 18th 2007

Posts: 44

Location: California


Monday, January 7th 2008, 10:27pm

embOS 3.52e, AT91SAM7X256, IAR: remap error

I am updating a project to 3.52e and going through some startup pains with configuration. I just encountered a problem that is bothering me. Even with a very minimal program, I found that it would crash on the first interrupt with error 0xa2. This code translates to "not a legal system call out of interrupt". However, the call was being made within the OS in the normal way. My configuration is to build a debug version that loads into RAM and executes from RAM.

What I learned is that the problem goes away if I remap RAM to overlay it starting at address 0. My linker command file locates all code and data in RAM at the physical address 0x00200000. RAM is _always_ accessible at that location. No matter, the error persists unless I execute some code to go through the remap procedure. Can someone shed a bit of light on why this is necessary ? My preference would be to avoid the confusion over remapping entirely, so long as I don't need to dynamically change entries in the interrupt table. There seems to be a problem with the IAR-supplied flash programming utility in that it fails to write flash ROM unless that ROM is mapped to zero... but that is another problem.

Any thoughts ?


Date of registration: Dec 20th 2007

Posts: 26


Tuesday, January 8th 2008, 1:02pm


When executing from RAM, the RAM has to be remapped to address 0x00.
If the ARM core receives an interrupt, it allways jumps to location 0x18 and executes the code there.
If your interrupt vectors are not located there, because the RAM is not remapped, the core executes something which resides in Flash.
I think, the OS_Error() handler is called by accident, after the first interrupt which jumped to address 0x18.