Problem calling function from SRAM

Jon's reply isn't actually very helpful. On the ADuC702x the RAM is within BL range of any FLASH address, so that's not the problem.

For what you want to do, Hameed, it is not enough to merely assign the code to another section - that section also needs to be in the linker script (I just tried to add a section without it in the linker script, and the linker discards the contents).

You also need to set pointers in the linker script to know where the LMA of the code is, and assign the VMA to RAM. The reason that you need to do this is because you can't necessarily guarantee that the code will not have internal absolute references. On the ARM this will only occur if the constant data address is more than a 12-bit number from the PC (4K - code size > 4K). - Since the RAM is only 8K in you device, I would doubt that you would have this problem. If the code did have internal absolute references then they must point to the VMA (which they would if the linking is done properly).

Next you need to copy the code from FLASH to RAM in the same way that the .data section is copied. This RAM needs to be allocated for this purpose lest you clobber some .data, .bss or stack/heap RAM.

If you do all of this then it should work, except that I have had aproblem doing the same, because the output (.hex) file seems not to include the stuff to be relocated. I think that the issue I have is that the linker is not correctly setting attributes of the code so that objcopy is not including it in the output - this is despite the fact that the VMA and LMA of the section are correct. If I figure out the problem/solution I'll let you know.

The alternate option is to compile a file containing your code at the intended execute address, do an objcopy/objdump on it, convert that output to an initialised array of data (not constant) and have it copied to RAM with the .data section at startup. You will need to modify the linker script to ensure that it will be stored in the correct RAM locations, and call the function by a type cast of the array pointer. Not a pretty technique, and you'll need to redo it with every mod to your code (which you won't be able to debug easily), but will work. Note that it gets messier if you have ARM/Thumb internetworking issues.

Jon's reply isn't actually very helpful. On the ADuC702x the RAM is within BL range of any FLASH address, so that's not the problem.

For what you want to do, Hameed, it is not enough to merely assign the code to another section - that section also needs to be in the linker script (I just tried to add a section without it in the linker script, and the linker discards the contents).

You also need to set pointers in the linker script to know where the LMA of the code is, and assign the VMA to RAM. The reason that you need to do this is because you can't necessarily guarantee that the code will not have internal absolute references. On the ARM this will only occur if the constant data address is more than a 12-bit number from the PC (4K - code size > 4K). - Since the RAM is only 8K in you device, I would doubt that you would have this problem. If the code did have internal absolute references then they must point to the VMA (which they would if the linking is done properly).

Next you need to copy the code from FLASH to RAM in the same way that the .data section is copied. This RAM needs to be allocated for this purpose lest you clobber some .data, .bss or stack/heap RAM.

If you do all of this then it should work, except that I have had aproblem doing the same, because the output (.hex) file seems not to include the stuff to be relocated. I think that the issue I have is that the linker is not correctly setting attributes of the code so that objcopy is not including it in the output - this is despite the fact that the VMA and LMA of the section are correct. If I figure out the problem/solution I'll let you know.

The alternate option is to compile a file containing your code at the intended execute address, do an objcopy/objdump on it, convert that output to an initialised array of data (not constant) and have it copied to RAM with the .data section at startup. You will need to modify the linker script to ensure that it will be stored in the correct RAM locations, and call the function by a type cast of the array pointer. Not a pretty technique, and you'll need to redo it with every mod to your code (which you won't be able to debug easily), but will work. Note that it gets messier if you have ARM/Thumb internetworking issues.

The Keil CARM compiler + linker knows about the fact that calls are far away and inserts the correct call sequence (direct or indirect depending on the distance).

So you should try this with the Keil CARM compiler.

Reinhard

I haven't solved the linker problem yet.

What I did was define a funtion (with the same prototype) to be in a RAM section, and just copied the real function from .text to RAM. Since my function is assembly language I was assured that the internal references were correct. It works fine, but I wish I knew what I'd done wrong with the linker script.

Having spent $$$ on the GNU tools (with Keil debugging capability) just prior to the release of CARM I couldn't really justify the cost of upgrade to my superiors. CARM would ease this problem, but introduce others of its own.

Having spent $$$ on the GNU tools (with Keil debugging capability) just prior to the release of CARM I couldn't really justify the cost of upgrade

How much time will you spend trying to work around a problem a tool upgrade would fix? How much is that time worth? (Rule of thumb: 2.5x your salary expressed as an hourly rate.) What are the risks of delay in the project, and how much would that cost?

The cost of software development tools is usually a pretty minor factor in the overall cost of development.