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.
Hi, Good Day.
I am working on ARM7TDMI core processor from Analog Devices family (ADuC703x). I developed a preemptive scheduler on the same in ARM environment. The functionality of the same is fine and its working well. For the purpose of optimization, i migrated into thumb mode using Keil RV compiler option (by changing the code generation option to THUMB mode and the optimization level option to 3 in C/C++ tab of the target settings option).
After changing the settings my code size is reduced by 2 KB. But, the complete functionality of the software got changed.
Can anybody help me out to get out of this problem? Also, I would like to know why this kind of behavior is occurring... Please let me know your valuable suggesions.
Thanking you in anticipation, Ravi Kumar Desaraju.
Hi Mike,
Yes, you are right. The same thing is happening with ADuC703x. think its the architecture of ARM7TDMI. I read sme where in the ARM core architecture document saying that, the first instruction of your exception handling (FIQ/IRQ/DATA ABORT/PABORT/SWI) should be written with ARM instruction. The ISR exit will automatically switching the ARM mode into THUM mode in my case. The problem is, in context switching code (independent to ISR), I am invoking the THUMB mode using branch instruction which is not happening properly. The other point is, with in ISR and context switching code I am using few 32-bit move instructions for condition checking. Is there any impact for the same, while working on THUMB architecture (THUMB mode doesn't have any 32-bit move instructions)?
The problem is, in context switching code (independent to ISR), I am invoking the THUMB mode using branch instruction which is not happening properly.
More details would help, preferably the code.
The other point is, with in ISR and context switching code I am using few 32-bit move instructions for condition checking. Is there any impact for the same, while working on THUMB architecture (THUMB mode doesn't have any 32-bit move instructions)?
Not sure what you mean. Are you saying you are trying to execute ARM instructions in THUMB mode? If so, of course it won't work.
Make sure your branch instruction is the BX (branch and exchange) allowing branching to ARM or Thumb code.
Hi,
Well, the Keil Real view compiler has an option to interwork with both ARM and THUMB mode. It will convert the code into the corresponding architecture.
I am executing the "BX LR" instruction with least significant bit of the LR register as 1. Also, I observed the state of T bit in CPSR register after executing the above mentioned instruction. Its switching from ARM mode to THUMB mode.
Hi All,
Is there any impact of running the scheduler in FIQ mode?
What is the difference between executing the code in user mode and FIQ mode?
I am running the scheduler in FIQ mode only. The reason for the same is as follows:
The stack for the FIQ interrupt is defined seperately. Hence, in the occurrence of FIQ interrupt, the ISR is referring the stack defined for FIQ instead of currently executing stack. Therefore, I am running the scheduler in FIQ mode only be y executing "BX LR" instruction in the ISR instead of SUBS PC, LR, #4. By executing the scheduler in FIQ mode, I am able to get the current executing stack reference in FIQ mode and my task switching is happening as expected in ARM mode. When I use the same code for THUMB mode it is not working. Is there any difference in executing the code in FIQ mode and user mode?
A major difference is that FIQ is a privileged mode and user mode is not, which affects access to CPSR (user mode can only read it). Why do you plan to execute your scheduling code in user mode? You can of course adjust CPSR while in FIQ mode (as you can from every privileged mode), but why would you? also note that CPSR is not saved automatically if you do that to switch to another privileged mode.
Note: ------ "There are several ways to enter or leave the Thumb state properly. The usual method is via the Branch and Exchange (BX) instruction. See also Branch, Link, and Exchange (BLX) if you're using an ARM with version 5 architecture. During the branch, the CPU examines the least significant bit (LSb) of the destination address to determine the new state. Since all ARM instructions will align themselves on either a 32- or 16-bit boundary, the LSB of the address is not used in the branch directly. However, if the LSB is 1 when branching from ARM state, the processor switches to Thumb state before it begins executing from the new address; if 0 when branching from Thumb state, back to ARM state it goes."
Hi Michel,
Thanks for your response.
You mean to say, scheduler should be running in privileged mode (FIQ) and the tasks should run in User mode right?
Is there any way to switch the modes dynamically....? (i mean can we change the mode setting bits of the CPSR)
Why not run your scheduler in IRQ mode? You only have one FIQ source - are you sure you want to spend it on your scheduler? Basically, your tasks should not run in privileged mode - executing
SUBS PC, LR, #4
from IRQ mode should bring you to the right task assuming your LR is restored correctly. You can switch modes manually while in privileged mode by writing to CPSR. Changing modes while in user mode can only occur by an exception.
Note that FIQ is a privileged mode. But not the only one.
why not compile everything but the context switch code in THUMB, and only the context switch assembly in ARM?
I tried that option using compiler directive #pragma thumb
I converted whole "C" code into THUMB and the assembly code in ARM. Its working fine.
But my specific requirement for this project is THUMB mode with optimization level as 3.
I cannot help you further unless I see your code.
"But my specific requirement for this project is THUMB mode with optimization level as 3."
Exacly why?
to reduce the ROM/code size.....
to reduce the ROM/code size.....<p>
But what if the compiler generated smaller code at optimization level 2 ? Sometimes, the optimizer will do things that are actually counter-productive.