Search Results

Thanks for this explanation Armin. Your paragraph that explains how the supervisor stack reuses the no longer needed system stack is what I could not pick up from the ARM-specifics manual. Perhaps you could add it to the docs for a future release. George

Env: IAR 4.41, embOS 3.52e, LPC2138, libmode DT I want to use malloc to allocate a couple of buffers before calling OS_start(). I am calling OS_INIT_SYS_LOCKS after OS_InitKern as recommended. This is before my call to malloc. The malloc call does not return because it ends up calling OS_LockSys, which calls some trace macro. I lost track of the final call that bombs, but it leads to OS_ERR_ILLEGAL_IN_TIMER. I can get around this by delaying my call to OS_INIT_SYS_LOCKS() until after I do the ma…

I seek to better understand stack usage in the emBOS ARM world. My current application is on an NXP ARM7, the LPC2138. I am working with IAR 4.41 tools. The ARM-specific documentation that came with emBOS says that emBOS internals run in SUPERVISOR mode, and tasks run in SYSTEM mode. This doc also seems to equate SYSTEM and SUPERVISOR stacks in section 6.2, which would be incorrect if that is the implication. The stack initialization included with embOS for this processor (and a few others that …

I'm working with embOS 3.52e on LPC2138/01, IAR 4.41 toolkit. The application is fairly simple, and currently is running with four tasks. When I look at the CPU utilization, all tasks are typically sitting at less than 0.5%. Several times per minute the utilization of one task goes way up and often sits at 100% for many seconds. There are also periods of "noise" where the utilization only goes up a few percent and maybe spikes to 10%. I have tried to test the system responsiveness by typing into…

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 …

Thanks for taking the time to respond. The explanation that something else was overwriting the stack had eluded me since I had incorrectly guessed that the error would have moved when I put a pad in front and behind the stack space. As soon as I implemented a write breakpoint on that area I found the problem. I still don't understand exactly why the fault location did not change when I padded memory before and after the stack, but that is only a curiosity now. George

embOS 3.32e ARM (AT91RM9200) Lib SP I have some code in a low pri task that calls OS_GetStackSpace, cycling through a list of all tasks. After I exercize my program a bit, this test pops out an error saying that a specific task is down to 16 bytes of stack. This is surprising because the task is not being activated at all, it is always waiting on an OS event. Although the stack should have been more than enough, I tried adding a large amount to it and the error only changed to say that it was do…