10 years ago.

Is mbed-rtos expected to work when exported to KDS?

In my quest to solve a memory utilization issue with mbed-rtos, I decided to try another approach in parallel, which was to export my simple test app to KDS and then inspect the remaining heap size there. Importing and building was not a problem. In fact, it was interesting to see that in the KDS-compiled code, my available heap was 260k vs 60k when running the mbed-built code. (Note: I had more detail in my question regarding the heap size here: http://developer.mbed.org/questions/5570/mbed-rtos-memory-utilization/. The simple test entails merely importing mbed-rtos and immediately losing 200k RAM)

I then thought I should try a simple mbed-rtos call, like Thread::wait(150). In this particular case, the program would hang rather than blinking. I paused execution and found myself in the disassembler:

SVC_Handler:
00000e5a:   b.n 0xe5a <SVC_Handler>
00000e5c:   b.n 0xe5c
00000e5e:   b.n 0xe5e
00000e60:   b.n 0xe60

The problem here is that it's an infinite loop. I then implemented SVC_Handler(), and it sure enough, it executed my code.

extern "C" void SVC_Handler(int R0)
{
    GreenLed = 1;
    RedLed = 1;

    BlueLed = 0;
    wait( 0.1);
    BlueLed = 1;
}

Single-stepping through this code, I could see that it worked. But that also made it clear that my program was no longer freezing - since SVC_Handler is now implemented (and doesn't hang), main continues to execute. The problem is that Thread::wait(150) isn't waiting 150ms - apparently, SVC_Handler is supposed to take care of this somehow by looking at the argument that gets passed in?

I took my contrived example a little further and added in a Semaphore. Here's my new main:

int main()
{
	Semaphore lock(1);
	GreenLed = 0;
	RedLed = 1;
	unsigned long heapsize = heapSize();
    while (true) {
    	lock.wait();
    	GreenLed = 1;
    	RedLed = 1;
    	BlueLed = 0;
        //Thread::wait(100);
        BlueLed = 1;
        //Thread::wait(100);
        lock.release();
    }
}

While stepping through the code for lock.wait() and lock.release(), everything sure seemed normal. That is, until it hit any of these in rt_CMSIS.c:

SVC_2_1(svcSemaphoreWait,    int32_t,       osSemaphoreId,      uint32_t, RET_int32_t)
SVC_1_1(svcSemaphoreRelease, osStatus,      osSemaphoreId,                RET_osStatus)

Then it just goes to SVC_Handler, which of course just blinks an LED at this point. SVC_2_1 look like macros that handle a variety of arguments and ultimately generate assembly calls. I have to construct the code and look at it, but I'm not an assembly expert, and by glossing over it, I don't see how the meat of the operation is ultimately generated from within SVC_Handler.

I'm not sure where to go from here, but since by default SVC_Handler isn't implemented in the project than mbed exports, my conclusion is that anything but the simplest of mbed projects cannot be expected to export in a usable state. I would definitely appreciate any feedback and/or suggestions!