mbed-os 5 Thread::start creates osErrorResource on LPC1549

[ptpaterson]

mbed-os 5 Thread::start creates osErrorResource on LPC1549

• Type: BUG

I cannot even get the sample program to execute correctly on the LPCXpresso1549 board. Is there something easy I am missing, like, "oh yea, this is totally not suppose to work for LPC1549!"? Platform specific help is hard to come by for mbed.

---

Bug

Target
LPC1549

Toolchain:
GCC_ARM (Also online compiler)

Toolchain version:
(latest as of 10/1/16)

mbed-cli version:
0.9.10

Expected behavior
Receive osOK back from Thread::start

Actual behavior
Thread::start is only returning osErrorResource (0x81). I have reduced the stack size to just about nothing, and it that doesn't help.

Steps to reproduce

Run this sample program. I don't have any other platforms to run on:

#include "mbed.h"
struct Foo {
    void work() { printf("Foo::member_work()"); }
};

void free_work()
{
    printf("free_work()");
}


int main()
{
    Thread member_function_thread(osPriorityNormal, 256);
    Thread free_function_thread(osPriorityNormal, 256);

    Foo foo;
    osStatus err = member_function_thread.start(callback(&foo, &Foo::work));
    if (err) {
        printf("   ERROR:  0x%x\r\n", err);
    }

    err = free_function_thread.start(free_work);
    if (err) {
        printf("   ERROR:  0x%x\r\n", err);
    }
    member_function_thread.join();
    free_function_thread.join();
}

[bridadan]

@ptpaterson you're right, it's not supposed to work on the LPC1549. Unfortunately, getting at the supported list of targets is a bit cumbersome. You need to be in an mbed project and then run mbed compile -S. You'll see that the LPC1549 isn't in the supported list. Sorry for the confusion!

[ptpaterson]

Ah. I let myself forget that because I have been using CLI with classic embed - I guess I didn't realize that the supported list was only for OS 5, so the fact that I've had it working meant I ignored it. Anyway...

I have worked with lpc15 on bare metal a lot and would be willing to dig into this. I'll check out the contributing/porting guides again, and get familiar with yotta!

We'll see - it's a lot of memory for a chip limited to 36k RAM. The program I excluded compiles to use just over 10k and that presumably doesn't have everything included.

[bridadan]

@ptpaterson We actually use mbed CLI with mbed OS as well now, so no need to learn yotta!

This platform just hasn't had much attention lately, so if you have luck getting it working that'd be great!

To enable it for mbed OS 5, you just need to add "5" to the release_versions field in targets.json: https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L228. This will signal to the tools that this is an mbed OS 5 capable target.

I'm going to go ahead and close this just because its an expected failure but feel free to post follow-up questions if you have any here.

[JojoS62]

I ran also into the problem that I couldn't allocate a memory block of 2k although mbed_stats_heap_get() reported about 28k free mem. That caused also a the problem with thread.start() because it wants to allocate the thread stack of 4k.
The problem that the LPC1549 does not work correctly with mbed 2 and 5 is a wrong setting of __StackTop in the linker script. The ram contains 3 areas, this was extended sometime from only the first 16k block to 16k+16k+4k. But __StackTop is still set to 'ORIGIN(Ram0_16) + LENGTH(Ram0_16)'. So the memory allocation fails at the check newheap <= __getMSP();
It works with:

__StackTop = ORIGIN(Ram0_16) + LENGTH(Ram0_16) + LENGTH(Ram1_16) + LENGTH(Ram2_4);

But I'm not an expert for linker scripts, so it should be checked by someone else.

[0xc0170]

@JojoS62 Can you send a pull request ? Should be simple fix

[JojoS62]

The PR is #8978
with 36 kB of ram and 256 kB flash the target is also able to run mbed-os. Changes are required only in the target.json. I guess this should be called in another PR?