Open Discussion #63
Comments
|
A new version of GCC4MBED is available on GitHub at https://github.com/adamgreen/gcc4mbed#quick-start New features include:
|
|
FYI GCC is now supported natively in the mbed project via mbed-CLI. This includes internal extensive testing in both nightlies and for each release. |
Thanks for the link! If mbed-cli works for people, then I definitely recommend that they use it. GCC4MBED was created back in 2011 before there was any official offline support from the mbed team. Why have I continued to maintain it after the mbed team has added this support? Mostly because I still find it useful for my own projects:
|
|
Hi Adam, I am working on NCS36510 cortex m3 based platform and trying to port your working branch https://github.com/adamgreen/gcc4mbed/tree/working and i am stuck. The code fails at the point, SVC_0_1(svcKernelStart, osStatus, RET_osStatus) The disassembly of the above is as follows, At this point pc goes for a toss and has the value ffffffc2. Not sure what is causing the problem. Thanks, |
|
@satish040 First I would recommend you use the master branch as it is the tested one. The working branch contains my work in progress and hasn't gone through a full test pass yet. That said, I doubt your problem is related to that. Can you enter a new issue here to track this problem? In that issue, please try to give me as much information about what you have done to get to this point? You mention that you are "trying to port" so it would be good to say what type of modifications you have made as part of that port. What sample are you attempting to build and run when this happens? Give me enough information in that issue that I can build the same image here to take a look at it to see if I notice anything obvious. |
|
Hi Adam, Can you help me? |
|
@StarCod3 One thing that might cause this is if your makefile is configured to build for devices that don't include LPC1768 since |
|
I tried to include mbed.h and the DigitialOut class is resolved but the rest like Serial, pirntf, LED1, SERIAL_RX, SERIAL_TX could not be resolved and Program "echo" not found in path. My include directory is |
|
@AchmadFathoni The documentation for gcc4mbed usage with Eclipse is out of date and was written before mbed had support for exporting to Eclipse. I recommend you checkout mbed's official Eclipse export features. I hope that helps. |
|
@adamgreen just wanted to tell you that you are doing a wonderful job (y). This project helped us getting hands on with mbed2. Looking forward to mbed5 now. |
|
@adamgreen I was wondring why newlib-nano is used by default in combination with mbed-os 5, because as far as I know newly-nano is not thread save, while mbed-os 5 is promoted as multithreaded, or am I wrong? |
|
@BramOoms I chose to stick with newlib-nano as the default to keep the binaries as small as possible and because mbed-os isn't really all that thread safe with either version of newlib anyway. One of the few things that used to be thread safe in newlib but not newlib-nano were malloc/free accesses to the heap. If memory serves correct, that should now be thread safe as well with more recent versions of newlib-nano. The use of newlib-nano can always be disabled via the NEWLIB_NANO variable in your makefile. |
|
@adamgreen That makes sense! Thanks for the quick reply. Let me explain my situation: I started my project a while ago when the gcc4mbed project was using mbed classic. However, I read about the thread safety issues regarding the standard c libraries Could the faults I'm experiencing be related to the thread safety issues regarding newlib(nano)? Even if I'm not allocating or freeing memory outside the main thread? It seems to be worse with newlib compared to newlib-nano. Thanks for helping! |
Maybe. A few things could lead to such problems. I will say that when working with RTX, the thing which most often caused memory corruption for me was a thread overflowing its stack. This will end up corrupting the contents of another thread's stack or some global variables. This was even more common for me when I used full newlib since newlib-nano required less stack space for local variables. If you don't get to the root cause of your problem soon and want some more help then maybe I could work with you to get me a crash dump that I could debug. |
|
@adamgreen I really appreciate it if you could help me out! The problem I'm facing now is that my watchdog kicks in because the system keeps executing the idle thread (after the system has run ok a couple of days). So I don't have a crash dump. I looked at the thread control blocks and they looked ok, (not corrupted). I made a complete print out of my RAM to my debug UART to find out if I could see any corruption. I noticed a remarkable issue: My main stack (12 kb) looks fragmentated, in the sense that it contains blocks filled with the "magic fill" pattern (0xCCCCCCCC) and other data alternating. This is the case right after start up when the systems runs ok. As far as I know a stack can only be a continuous memory block, is that correct? The stacks of the other threads looks ok: real stack data, followed by a continuous block containing 0xCCCCCCCC until the top-of-stack-magic word. To you have any Idea how this could happen and how I can debug this? |
It typically is ok if the idle thread is running. That just means that no other thread has anything else to do at the moment. Which thread is supposed to tickle the watchdog? Can you dump that thread's stack when the watchdog fires?
That can be expected behavior. If you have a buffer defined on the stack but you don't completely fill that buffer then it could lead to such a pattern of stack usage. For example: {
char buffer[256];
strcpy(buffer, "Small usage!");
}What device are you targeting? When the watchdog kicks in, is it reseting your device or do you have it setup to fire an interrupt from which you can debug the state of the device at the time of the watchdog event? Are you comfortable enough with the GDB command line to start it up and issue commands that I would give you to create a dump that I could debug? I would need access to the .elf file as well. Is your project too confidential for me to have access to the .elf? Usually I don't need access to the source code. |
My code is executed as much as possible from the main thread. I post a callback object in the main thread's queue when a timer expires or when code needs to be executed after an interrupt. The main thread tickles the watchdog every time it processes a message from its queue. I have a about a hand full of timers for ADC conversion and polling data on tcp sockets. The timers expire every 20 ms and are restarted in the timer callback function. void AsyncTask::postCallback(Callback* callback)
{
_queue.put(callback);
}
void AsyncTask::waitForCallbacks()
{
while (true)
{
osEvent e = _queue.get();
if (e.status == osEventMessage) {
irc::Watchdog::WATCHDOG.kick();
Callback* callback = (Callback*)e.value.p;
callback->invoke();
}
}
}
I'm targeting an Atmel SAM4E16C. I have it setup the fire an interrupt when the watchdog expires. I have attached a text file containing a RAM dump made from my watchdog fault interrupt handler. My main thread stack is from 0x20007E64 - 0x2000AE64.
I'm not an GDB expert, but I can launch it and issue commands you give me! I'm using OpenOCD as GDB server and able to connect to it using arm-none-eabi-gdb. I can provide the elf file, no problem! Would you recommend using newlib or newlib-nano? |
|
Discovered that the RAM dump made from the watchdog fault handler seems to contain 7 thread stacks (7 times the magic stack top pattern (0xA52E5AE2), while there suppose to be only 6:
The os_active_TCB array contains only 6 threads when a watchdog fault occurs, so I don't understand why my RAM contains 7 thread stacks. Do you have any idea? I had a look at the task control blocks for each thread during a watchdog fault and it seems that the main thread is waiting for a semaphore (state 7 - WAIT_SEM), however, I'm not waiting for a semaphore in code executed in the main thread as far as I can see. |
Did you have to add this support yourself? I don't see this target supported by mbed-os. The main reason I was asking for the device type was so that I could look at its linker script to get the RAM regions so that I knew what to have dumped. What are the RAM regions for your device? I think it is 128K starting at 0x20000000. If that is the case, these GDB commands should create a crash dump that I can debug: More information on what I am dumping with those commands can be found here. You can email me the resulting crash.dump and corresponding ELF file. I have an electronic mail account at yahoo.com. The alias I use there is adamgrym. |
|
Yes, I've added support for the SAM4E target and you are correct about the RAM regions: 128K starting from 0x20000000. I have tried to create a dump using your GDB commands while my program loops in the watchdog fault handler ISR, but got an "Invalid cast." error while trying to dump the xpsr, floating point and fpscr registers. What could be wrong? |
|
@BramOoms |
|
@adamgreen I have found a situation where the SerialConsole UART is being interrupted while it is receiving by the USB end-point code, and while still in there, it is further interrupted to send on the UART. The result is that in the below code snipped from the MBED library is that the flush(_file) does not actually flush the input (i.e. throw away unread chars), but instead flushes the buffer to UART which I believe is due to the sequence of interrupts. I have spent more that a few days to get to this point!! mbed::Stream::getc() at Stream.cpp:43 int Stream::getc() { I can go into greater details if you want, but the root cause of this appears to be due to Smoothie using an older version of gcc4mbed that itself is using MBED 2 which I believe is not thread safe for Stream, and reading the source code for Stream.cpp in MBED OS 5 it now uses locks and therefore should be thread safe. The latest version on the MBED site: int Stream::getc() { So the question is, what is required to migrate Smoothie V1 to use your latest code base, and can it be done? Cheers |
|
@DouglasPearless It has been a long time since I last touched the Smoothie v1 code base. I don't know what it would take to upgrade it to a newer version of the mbed SDK. I know that they made a few local changes to the SDK code that you would need to maintain during such an upgrade. I have a few comments/questions:
I don't understand this comment. That is what I would expect fflush() to do. Push through all outstanding buffered writes to the UART peripheral before returning to the caller. I hope that helps. |
|
@adamgreen thanks for the quick response.
You are right it may well be a bug about interacting with a Stream from multiple “threads”.
I have discussed the issue with the Smoothie team but not this specific scenario.
The issue I traced with the flush is that it is called in the getc routine and should have discarded the unread input BUT instead flushed the UART input buffer to the output of the UART!
In this instance Smoothie is returning an “ok” but this gets corrupted with characters that are still in the input buffer 😩
…Sent from my iPhone
On 2/12/2017, at 11:54 AM, Adam Green ***@***.***> wrote:
@DouglasPearless It has been a long time since I last touched the Smoothie v1 code base. I don't know what it would take to upgrade it to a newer version of the mbed SDK. I know that they made a few local changes to the SDK code that you would need to maintain during such an upgrade.
I have a few comments/questions:
Is it not a bug that the Smoothie firmware is interacting with the same stream from multiple 'threads' of execution? I thought it tried to maintain single threaded access to generic (Standard C/C++ Library, mbed SDK, etc) features.
It would probably be better to ask the Smoothie team what would be involved in such an upgrade. They have probably tried to do it before and know what hiccups have been encountered. If it was me and I knew that this was really the bug and not the multithreaded access itself, I would just upgrade the parts required to fix the specific issue.
The result is that in the below code snipped from the MBED library is that the flush(_file) does not actually flush the input (i.e. throw away unread chars), but instead flushes the buffer to UART
I don't understand this comment. That is what I would expect fflush() to do. Push through all outstanding buffered writes to the UART peripheral before returning to the caller.
I hope that helps.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I don't think that fflush() would ever discard characters in the input buffer. It is used here to make sure that all outstanding output data on the stream is sent to the user before waiting for input data so that the user knows to what they are responding. |
|
@adamgreen
My thoughts on the fflush are based on:
https://stackoverflow.com/questions/16780908/understanding-the-need-for-fflush-and-problems-associated-with-it
And what I am observed is:
While the MBED library was writing to the SPI interface to read the SD Card, a character arrived from the UART, the getc() routine was called BUT for some reason it was also written to the UART:
serial_putc() at serial_api.c:378 0x3ec88
mbed::Serial::_putc() at Serial.cpp:64 0x3f502
mbed::Stream::write() at Stream.cpp:59 0x3f5e0
_write() at stdio.cpp:195 0x3f97a
_write_r() at 0x47f70
__sflush_r() at 0x44240
mbed::Stream::getc() at Stream.cpp:43 0x3f6de
SerialConsole::on_serial_char_received() at SerialConsole.cpp:46 0xeb3a
void mbed::FunctionPointer::membercaller<SerialConsole>() at FunctionPointer.h:73 0xeb0e
mbed::FunctionPointer::call() at FunctionPointer.cpp:33 0x3f30a
uart0_irq() at serial_api.c:312 0x3e62e
<signal handler called>() at 0xfffffff9
spi_master_write() at spi_api.c:252 0x3fff8
SDCard::_read() at SDCard.cpp:472 0x18904
SDCard::disk_read() at SDCard.cpp:324 0x18972
USBMSD::memoryRead() at USBMSD.cpp:654 0x1931a
USBMSD::USBEvent_EPIn() at USBMSD.cpp:272 0x19388
USB::USBEvent_EPIn() at USB.cpp:281 0xd548
USBHAL::usbisr() at USBHAL_LPC17.cpp:947 0x183ea
Kernel::call_event() at Kernel.cpp:319 0x8d2e
main() at main.cpp:275 0x76b2
I think that USB stuff is not related to the issue (famous last words) as reviewing that code, the buffers etc seem to be in totally different memory locations an relate only to the USB modules.
<signal handler called>() at 0xfffffff9
shows that the ARM core interrupted that because the UART interrupt occurred, and that (eventually) called the
SerialConsole::on_serial_char_received() at SerialConsole.cpp:46 0xeb3a
which is where it starts to get interesting, the
mbed::Stream::getc() at Stream.cpp:43 0x3f6de
looks like:
int Stream::getc() {
fflush(_file);
return std::fgetc(_file);
}
and the fflush(_file) I stepped through and it flushed the contents on the INPUT buffer itself to the UART appears to be the reason Smoothie is now writing BACK to the UART, though I need to understand WHY it is doing that.
I was wondering if Stream is not thread safe as under MBED is 5 it now has locking?
Thoughts?
…Sent from my iPhone
On 2/12/2017, at 1:05 PM, Adam Green ***@***.***> wrote:
The issue I traced with the flush is that it is called in the getc routine and should have discarded the unread input BUT instead flushed the UART input buffer to the output of the UART!
I don't think that fflush() would ever discard characters in the input buffer. It is used here to make sure that all outstanding output data on the stream is sent to the user before waiting for input data so that the user knows to what they are responding.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
As you say, the stream implementation on that version of the MBED SDK isn't thread safe. Whether that is causing your issue, I am not sure. If another 'thread' was writing data to the stream's buffer when a character comes in on the UART then yes, the stream's write buffer could get corrupted because of the fflush() that gets called in the UART's ISR context. Probably best to move this issue over to the Smoothie project. |
|
@adamgreen
Thanks for the pointers.
Cheers
Douglas
… On 2/12/2017, at 3:38 PM, Adam Green ***@***.***> wrote:
As you say, the stream implementation on that version of the MBED SDK isn't thread safe. Whether that is causing your issue, I am not sure. If another 'thread' was writing data to the stream's buffer when a character comes in on the UART then yes, the stream's write buffer could get corrupted because of the fflush() that gets called in the UART's ISR context.
Probably best to move this issue over to the Smoothie project.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADkh-w9EPPHUzVhjGe3gVHxvXGHP7Ev4ks5s8LhAgaJpZM4Nf7ZI>.
|
|
Hello Adam. Is there a way to build gcc4mbed project using CMake? |
|
@VladasZ You can generate a CMake'able mbed project from the mbed online compiler as one of the export options. |
|
@adamgreen Thank you. |
|
This project is no longer under active development. |
Please feel free to use this GitHub issue for general discussion about the GCC4MBED project. If you just want to ask me or the community a general question, then this issue is the place to do it.
GitHub gives you the option of subscribing to get notifications when people post new content to this issue. You should find this subscribe option in the pane on the right-hand side of the issue.
The text was updated successfully, but these errors were encountered: