I am trying to create an RTX project to run on the A2F-EVAL-KIT. I have three tasks running, two of them have a priority of 1 and use os_evt_set and os_evt_wait_or to take turns executing. This runs properly. Task 3 has a priority of 2 and uses os_evt_wait_or to wait for isr_evt_set in an ISR. Every time the isr_evt_set is called in the ISR, there is a runtime error and the os_error function is called in RTX_Conf_CM.c. This is the only ISR and the only isr_ call that is made. The returned value of err_code is 2, which appears to be a OS_ERR_FIFO_OVF. I tried increasing the ISR FIFO Queue size to 96, however the runtime error still occurs ever time. I also created another project following this example as closely as possible.
www.keil.com/.../rlarm_ar_inter_funct.htm
I still encounter the same error. I imagine that there some be some configuration that I am missing. I am running uVision 4.2, but I had the same problem with the previous version. Also, I am using the ULink2 programmer.
Thanks in advance, Brandon
Interrupts and preemption are very important features to us, so I sent my project to support. I will post back if I learn anything.
I had the OS on a ARM7 crashing due to something similiar:
If you are using os_itv_wait() to establish a fixed frequency loop then use a os_evt_wait_event()function, the isr_evt_set() will corrupt the loop delay interval and force it to run continuously. They briefly mention "don't do this" in the docs somewhere.
One fix is to rewrite the os_itv_wait() fn to be a bit less brain dead.
Perhaps I am the only person that wants to have a more or less fixed frequency loop and be able to have a ISR signal that it is done doing something that takes a few mS.
Chad
Update: Looking at the disassembly and the file installed in: C:\Keil\ARM\RL\RTX\SRC\CM\rt_HAL_CM.h
I was able to see what is happening. Execution enters the top do while loop and loops until the FIFO (count) is full and it return and enters the runtime error function indicating buffer overflow. I do not know what the purpose of this would be.
//********************************************************************
#if defined(__TARGET_ARCH_7_M) || defined(__TARGET_ARCH_7E_M)
do {
if ((cnt = __ldrex(count)) == size) {
__clrex();
return (cnt); }
} while (__strex(cnt+1, count));
c2 = (cnt = __ldrex(first)) + 1;
if (c2 == size) c2 = 0;
} while (__strex(c2, first));
#else
__disable_irq();
if ((cnt = *count) < size) {
*count = cnt+1;
c2 = (cnt = *first) + 1;
*first = c2;
}
__enable_irq ();
#endif
return (cnt);
Another question is that I am using the Smartfusion which has a Cortex M3, based on the if def statement specifying the ARM 7, should this code even be complied into the project? The settings for the device appear to be correct.
I would be grateful for any suggestions. I have still not received an answer from Keil on this.
Actel did not implement the exclusive access instructions (LDREX/STREX/CLREX) in their Cortex-M3 SmartFusion devices which causes the RTX problems you are seeing.
Cortex-M3 device should implement the ARMv7-M architecture which includes also exclusive access instructions. RTX is taking advantage of those instructions (no interrupts disabling …).
Current RTX bypass for SmartFusion is to prevent using the exclusive access instructions.
Modifying RTX (MDK-ARM V4.20) for SmartFusion requires following steps:
1. Edit file "Keil\ARM\RL\RTX\SRC\CM\rt_HAL_CM.h" Replace two occurrences of
with
#if 0
2. Edit file "Keil\ARM\RL\RTX\SRC\CM\rt_MemBox.c" Replace three occurrences of
#if !(defined(__TARGET_ARCH_7_M) || defined(__TARGET_ARCH_7E_M))
#if 1
3. Rebuild RTX library (project Keil\ARM\RL\RTX\RTX_Lib_CM.uvproj)
4. Copy the new RTX library RTX_CM3.lib into folder Keil\ARM\RV31\LIB
5. Rebuild your project
Robert,
Thank you! This was right on. Problem solved. We may be able to use RTX after all. The only advice I would give for other people who are new to uVision like myself, make sure when you open the the project (Keil\ARM\RL\RTX\RTX_Lib_CM.uvproj), to select the correct target. In my case I needed to select CM3_LE. I got hung up a little on this.
Thanks again.