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.
I'm not sure how intelligent the 'ARM/THUMB interworking' facility is. Hopefully, it detects all function calls and converts them appropriately. I would check the ISR, though. I don't know how interrupts are handled in ADuC703x, but in the MCU I'm dealing with the interrupt handling code enters the ISR in ARM mode.
- mike
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.
The IDE has a specific check-box for "Optimize for Time", but no corresponding "Optimize for Size".
Many compilers starts to generate larger code for the highest optimization levels, because a higher priority is given to speed. Unrolling small loops can give great speed improvements, at the cost of size.
Depending on cache architecture, many compilers also starts to use a larger align value for really high optimization levels.
I think that's an either-or thing. It optimizes for size by default, but will optimize for time if the user requests it. So a separate check-box for "Optimize for size" is not necessary.
It makes sense to use Thumb "as much as you can" to optimize for size.
on an ARM7TDMI you CANNOT run with thumb code exclusively, you must have SOME ARM code. It really cannot be done so don't try to.
That being said, I would assume that having working code is more important than the size. Because it is much easier to get a scheduler to work in ARM code than Thumb code, you should write you scheduler in ARM code. I would also write it to be run though the SWI execption handler. This will put you into a priviledge mode AND into ARM mode. When you return from this you can have the USER registers all set up/restored and return to either thumb or ARM mode directly, without using a BX instruction.
Robert,
you wrote
I would also write it to be run though the SWI execption handler. This will put you into a priviledge mode AND into ARM mode.
I thought that all exception code is executed in ARM, even if the non-exception code runs in thumb? it is possible to switch to thumb in the handler, of course.
Yes, all exception/interrupt code has to start in ARM mode, since the processor does not know anything about the code when entering the exception handler.
I think he is trying to say that an SWI handler is an easy way to get into priviledged mode and into ARM mode. No need to consume the FIQ handler.
Yes, All the exceptions must be written in ARM mode. While you exit from the exception, the statement (return) itself switches the control back to THUMB mode. No need to execute a branch exchange instruction again to switch back to THUMB mode. This I experimented in FIQ handler and IRQ handler. I think it is same for all exceptions.
Well, coming to running the scheduler with SWI, how sure you are maintaining the performance of your scheduler with in the tolerance range. My application is to execute few tasks on a specific timing interval/periodicity. That's why I opted for a FIQ (using timer interrupt).
why then not use a periodic timer that uses an IRQ? IRQ has a higher interrupt priority than SWI:
Exceptions Priority I bit F bit Reset 1 1 1 Data Abort 2 1 - Fast Interrupt Request 3 1 1 Interrupt Request 4 1 - Prefetch Abort 5 1 - Software Interrupt 6 1 - Undefined Instruction 6 1 -
I may require few peripheral interrupts in my application. I dont want to use those interrupts in FIQ since, FIQ holds the higher priority than IRQ. Therfore, I am using the FIQ handler for scheduler. In future, if I require any peripheral interrupts in my application, I can configure the same in IRQ handler.
think of this: what is more important to you - switching a task in a timely manner or servicing a peripheral at a timely manner? I don't know about you, but unless what you are writing is truly time critical and has clear deadlines (per task), servicing a peripheral sounds more important to me (so: keep the FIQ for a peripheral). You are aware that the difference between FIQ/IRQ servicing is one branch instruction at most, as the FIQ is the last entry in the vector table hence the servicing code can be placed in the table itself. is your application that time critical? and don't be stubborn - do as you are told :-)
Mine is safety critical system. For this kind of application, we feel its better to use FIQ service handler (since it has the high priority).
The tasks in this system must run over a specific periodicity. No latencies are allowed and the scheduler must be built with hard realtime concept. These are the key requirements which are forced me to go for FIQ. Yes, I do agree your opinion about the peripheral interrupts. In our case, the priority is task switching over the specific periodicity.
Apart from this, I would like to know few points about the ISRs in ARM7TDMI core processors.
My FIQ handler was developed in ARM code and the CPU mode is switch from THUMB to ARM in case of FIQ interrupt. After leaving the handler, CPU mode is switching from ARM to THUMB. There is no problem in executing the interrupt service. My question is, is it suggestible to implement the context switching with in the ISR....?
if you are writing a safety critical system you are probably much better off with a real RTOS rather than writing you own scheduler. Your expectations of having no interrupt latency are not realistic, I am afraid, as there is usually a trade-off between interrupt latency, throughput, and processor utilization. One way of the other, high system load will cause some delays and there is no way around it. As to your final question - have you seen this link? http://www.keil.com/forum/docs/thread12635.asp
Hmm... I'm afraid the system in question cannot qualify as 'safety critical': it appears some basic problems have not been sorted out yet. I agree with Tamir, why not look around for a 'tried and true' third-party RTOS? After all, you are not trying to develop your own compiler, shouldn't the same apply to an RTOS?
Hi Mike and Tamir,
I do agree with you ppl about using the IRQ handler instead of FIQ. As I explained earlier, my system is a safety critical thats the only point which forced me to work with FIQ. Moreover, my scheduler is working fine with all the timing considerations in ARM mode. I am facing the problem with THUMB mode only.
The reason why we did not prefer to go with already available RTOS is memory consideration... This particular chip is having 30KB of FLASH and 4 KB of SRAM. So.. we are developing our own scheduler with minimum functionality (viz., we don't have resource sharing concept in this project, so no need to develop mutex and seam phore etc... In a broad way we are implementing the RM algorithm in our scheduler).
In ARM mode the size of my code is 3 KB. When I convert and build the code in THUMB mode, I observed that the scheduler code is occupying just 1.8KB. So, I thought its better to go for THUMB mode to reduce the code size further (worst case, it would become 2 KB. which saves 1 KB of FLASH memory....).
Tamir,
I referred the link which you have provided. Its really useful... thanks a lot.
Keil's RTL has all the features you want, plus more that you do not need AND meets your tight space requirements. (That if 2K or less of ROM space for the kernel is a requirement) It also works in ARM or Thumb Mode. You can also buy the source code so that you can modify it if you need too (I believe it is still under $5k US to buy). One of the ways they keep the code size small is that if you do not use a feature, it will not link in that feature (i.e. Semaphores, Mailboxes, Mutexes...). You can just use the Real Time Task Scheduler... that works. If nothing else by buying the source that works, you might be able to figure out what you are doing wrong. It never hurts to understand more.
Make that $5k for each user who need to be able to work with the project.
View all questions in Keil forum