Skip to content
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.

Delayed stdio handle open causes issues. #4

Closed
adamgreen opened this issue Oct 1, 2011 · 1 comment
Closed

Delayed stdio handle open causes issues. #4

adamgreen opened this issue Oct 1, 2011 · 1 comment
Assignees
@adamgreen

Comments

@adamgreen
Copy link
Owner

Reported by Charles Garcia-Tobin at http://mbed.org/forum/mbed/topic/2701/?page=2#comment-13988

Hi all

First let me say thanks for this work. It's amazing to be able to compile off-line. I've been playing around with it and had no problem getting it up and running. However I have a problem with Serial, and I was wondering how much the mbed library is functional when used like this. I confess I know very little about this project as I only looked started playing with it last night. Anyways the issue I had is that at the beginning of my sample program I had written:

...

Serial pc(USBTX, USBRX); // tx, rx

int main() 
{
...
  pc.baud(115200); 
...

When built with the on-line compiler this works and you get all your debug printfs coming out at 115200, however when you use sourcery the UART0 remains stubbornly at 9600. I tried dumping the UART0 registers to a file (great thing that local file system works -interestingly opening for append works equally bad on-line off-line!) and you can see differences in the values between on-line and off-line compiled versions. Any ideas? how can I dig further? Maybe I am doing it all wrong anyways?
@ghost ghost assigned adamgreen Oct 1, 2011
@adamgreen
Copy link
Owner Author

I need to revisit my delayed open of stdio handles since it breaks the functionality pointed out above by Charles.

adamgreen added a commit that referenced this issue May 4, 2016
@adamgreen
Pre-allocate the security manager
187a35a 
Previous to this fix, the BLEHeartRate sample would generate a crash in
GCC4MBED when it attempted to dynamically allocate the security manager
from an interrupt handler.  GCC4MBED catches such allocations and
breaks into the debugger so that a developer can catch incorrect
heap usage early before it leads to future heap corruption. This is
the callstack previously generated:
    breakOnHeapOpFromInterruptHandler () at ../../src/gcc4mbed.c:85
    85	        __debugbreak();
    (gdb) bt
    #0  breakOnHeapOpFromInterruptHandler () at ../../src/gcc4mbed.c:85
    #1  __wrap_malloc (size=36) at ../../src/gcc4mbed.c:92
    #2  0x0001e858 in operator new (sz=sz@entry=36)
        at /depots/gcc-arm-none-eabi/src/gcc/libstdc++-v3/libsupc++/new_op.cc:50
    #3  0x0001a260 in nRF5xn::getSecurityManager (this=0x200020ec <deviceInstance>)
        at ../BLElibs/nRF51822/source/nRF5xn.h:96
    #4  btle_handler (p_ble_evt=0x2000224c <btle_init::BLE_EVT_BUFFER>)
        at ../BLElibs/nRF51822/source/btle/btle.cpp:144
    #5  0x0001c68e in intern_softdevice_events_execute ()
        at ../BLElibs/nRF51822/nrf51-sdk/source/nordic_sdk/components/softdevice/common/softdevice_handler/softdevice_handler.c:157
    #6  0x0001c6e2 in intern_softdevice_events_execute ()
        at ../BLElibs/nRF51822/nrf51-sdk/source/nordic_sdk/components/softdevice/common/softdevice_handler/softdevice_handler.c:96
    #7  0x0001a016 in eventHandler ()
        at ../BLElibs/nRF51822/source/btle/btle.cpp:74
    #8  0x0001c780 in SWI2_IRQHandler ()
        at ../BLElibs/nRF51822/nrf51-sdk/source/nordic_sdk/components/softdevice/common/softdevice_handler/softdevice_handler.c:339
    #9  <signal handler called>
    #10 0x0000d16c in _binary_NRF51822_s110_softdevice_bin_start ()
    #11 0x0000119a in _binary_NRF51822_s110_softdevice_bin_start ()

I added a call to generate the security manager singleton from
main() so that it no longer needs to be allocated from within the ISR.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@adamgreen adamgreen

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@adamgreen