MDot hangs when using mbed5 EventQueue.

[Tom Hill]

I have an application, where the MDot behaves as an SPI slave, and Nordics NRF52 is the SPI master. Every 30 seconds the MDot uses the EventQueue to wake the NRF52 to via a wake pin on the NRF52 and NRF52 begins SPI transmission and this works for a few iterations and then the MDot hangs.

I am using MBED os 5.2.3.

1) Is there any limitations using the MBED5 EventQueue on the MDot?

2) I am not sure if it has anything to do with the stack size, since I noticed a warning of default stack size on MBED5, which has been reduced both for the main thread and any other new thread created. In the same warning there was an example of increasing the stack size of any new threads created. How do I increase the stack size of the main thread to the levels it used to be prior to MBED 5?

Thanks,
Yogesh

[Mike Fiore]

Yogesh,

I don’t believe the mDot has smaller than normal stack sizes. You might be thinking of the xDot, which does.

We haven’t used the EventQueue, so we can’t speak to any compatibility issues with the mDot library at the moment. Do you see any RTX error messages when the hang occurs? Usually if there’s a stack overflow or the system runs out of memory (new() fails, etc), you’ll see an error message come out the debug port.

Can you debug the issue and see exactly what is causing the mDot to hang? We have some info about setting up debugging on the our mbed wiki page.

https://developer.mbed.org/teams/MultiTech/wiki/Using-Eclipse-and-mbed-5-for-MTS-Devices

Cheers,
Mike

[Tom Hill]

Hi Mike,

Thanks for taking the time to respond. However I think I have the hang resolved for now, however it is not clear to me why it resolves it, may be you may have better insight to why its working.

If I run the SPI communication on the main thread, within a few deep sleep cycles, the mdot hangs on an SPI call, and I have turned on the logging level to the highest, which is TRACE_LEVEL and nothing is written out to the debug o/p.

So I ran the SPI calls from a thread spawned during startup and infact the deep sleep is called within the thread as well and now it no longer hangs. The priority of this thread is the default which is Normal. So not sure why this works, but not on the main thread. Also other thing I noticed while making SPI calls, I can’t seem to use any of the logging API’s or printf statements that would end up hanging the MDot as well. So I had to store the debug values and once I was done with the SPI transactions, I then write out all the debug o/p.

Also regarding the default stack size, the mdot page on the mbed site has a clear warning clearly called out. It seems like it is an mbed 5 change. Does this not apply for the MDot?

Thanks,
Yogesh

[Mike Fiore]

Correct, stack sizes changed from mbed 2 to mbed 5, but the mDot continues to use the standard mbed 5 stack sizes.

I’m not sure why SPI transactions in one thread work. Debugging the lockup with GDB would definitely help you to figure out what’s going on. It’s possible some kind of error condition is being encountered and the system is sitting in a while(1) loop somewhere.

Cheers,
Mike

[Tom Hill]

Hi Mike,

I have not changed anything except for the fact the method was called directly by the main thread and now the same method is called when the thead.start method is called. I will see if I can get GDB to work on my windows 10 machine, I have had little luck setting this up in the past.

So when you say that MDot uses stand mbed 5 stack sizes, that would mean the stack sizes have reduced for the main thread and the child thread.

Thanks,
Yogesh

[Mike Fiore]

When compared to mbed 2, yes. I don’t think the standard stack sizes have changed between mbed 5 versions.

Cheers,
Mike

[Tom Hill]

Thanks Mike. I did try to increase the stack size of the child thread to 4k as suggested on the mdot page on the mbed web site and I got an RTX error code: 0x00000001 and I think this supposed to be stack overflow error. So on the MDot can I not allocate more stack space for a new thread I create? Btw this is the first thing I do in the main.cpp file as shown below.

int main() {
    //serial debug
    Serial  pc(USBTX, USBRX);
    pc.baud(19200);
    
    // create a 4kB stack for the spi thread
    uint8_t th_stack[4096];
     
    // create the thread with custom stack
    Thread tProcessSPIMessages(osPriorityNormal, sizeof(th_stack), th_stack);
    
    OSPISlave oSPISlave(spiSlave, pc, eventQueue);
    oSPISlave.Initialize();

    //start the SPI processing....
    tProcessSPIMessages.start(callback(&oSPISlave, &OSPISlave ::processSPIMessages));

     eventQueue.dispatch_forever();
}

Thanks,
Yogesh

[Mike Fiore]

Yogesh,

You’re allocating the stack for your worker thread off the main thread’s stack. As soon as your main thread attempts any other operations that require stack, it’ll overflow its stack.

You need to new() your work thread stack from the heap or allocate it statically in the global space before main.

Cheers,
Mike

[Tom Hill]

Thanks Mike :). Not sure what I was thinking, Yeah that would definitely cause an overflow.

Thanks,
Yogesh

[Tom Hill]

Hi Mike,

Just a follow up question. So based on the mdot page on the mbed website, the main thread has a stack size of 4kb.

1) Can this be increased to levels in mbed os 2? I am assuming the stack size in mbed os2 was higher?
2) What was the stack size of the main thread in Mbed os2?
3) Any global objects would be allocated on the main thread stack right? I am wondering if because of this the stack is overflowing on the main thread?

Thanks,
Yogesh

[Mike Fiore]

Yogesh,

Take a look at the mbed 2 and mbed 5 memory models.

mbed 2: https://developer.mbed.org/handbook/Memory-Model

mbed 5: https://docs.mbed.com/docs/mbed-os-handbook/en/latest/concepts/memory_model/

Cheers,
Mike

[Author]

Posts