{"action":"created","issue":{"url":"https://api.github.com/repos/mbedmicro/mbed/issues/1631","repository_url":"https://api.github.com/repos/mbedmicro/mbed","labels_url":"https://api.github.com/repos/mbedmicro/mbed/issues/1631/labels{/name}","comments_url":"https://api.github.com/repos/mbedmicro/mbed/issues/1631/comments","events_url":"https://api.github.com/repos/mbedmicro/mbed/issues/1631/events","html_url":"https://github.com/mbedmicro/mbed/issues/1631","id":143600090,"number":1631,"title":"Serial broken with Nucleo F303K8 on GCC-ARM","user":{"login":"ducky64","id":1069863,"avatar_url":"https://avatars.githubusercontent.com/u/1069863?v=3","gravatar_id":"","url":"https://api.github.com/users/ducky64","html_url":"https://github.com/ducky64","followers_url":"https://api.github.com/users/ducky64/followers","following_url":"https://api.github.com/users/ducky64/following{/other_user}","gists_url":"https://api.github.com/users/ducky64/gists{/gist_id}","starred_url":"https://api.github.com/users/ducky64/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ducky64/subscriptions","organizations_url":"https://api.github.com/users/ducky64/orgs","repos_url":"https://api.github.com/users/ducky64/repos","events_url":"https://api.github.com/users/ducky64/events{/privacy}","received_events_url":"https://api.github.com/users/ducky64/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/mbedmicro/mbed/labels/TARGET_ST","name":"TARGET_ST","color":"c7def8"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2016-03-25T21:14:35Z","updated_at":"2016-03-26T07:38:01Z","closed_at":null,"body":"Deploying code exported to GCC-ARM from the mbed online compiler using Serial causes the microcontroller to freeze and end up in `WWDG_IRQHandler()`.\r\n\r\nIf compiled against the mbed library (at tag mbed_lib_rev116) from scratch (as opposed to the pre-compiled .a supplied from the online compiler export), stepping through has it failing in\r\n`_file = std::fopen(buf, \"w+\");` (mbed/common/Stream.cpp:24)\r\n\r\nThe instruction call stack looks like (inside the std::fopen call):\r\n`Serial uart(SERIAL_TX, SERIAL_RX);`\r\n`mbed::Stream::Stream()`\r\n`_fopen_r()`\r\n`__sfp()`\r\n`__sinit()`\r\n`std.isra.0`\r\nwhere the last instruction executed is:\r\n`08005376:   str     r3, [r0, #0]`\r\n(where register r0 = 0, presumably what causes the hardfault)\r\n\r\nNote that manually invoking the serial API functions seems to work:\r\n```\r\nserial_t obj;\r\nserial_init(&obj, SERIAL_TX, SERIAL_RX);\r\nserial_putc(&obj, 'x');\r\n```\r\nso the root cause of the problem doesn't appear to be the serial HAL, but rather the interaction of the system libraries with ... something ...\r\n\r\nI'm using `gcc version 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848] (GNU Tools for ARM Embedded Processors)`.\r\n\r\nPossibly related to this issue:\r\nhttps://developer.mbed.org/forum/bugs-suggestions/topic/25983\r\nwhich is 24 days old without a resolution."},"comment":{"url":"https://api.github.com/repos/mbedmicro/mbed/issues/comments/201723925","html_url":"https://github.com/mbedmicro/mbed/issues/1631#issuecomment-201723925","issue_url":"https://api.github.com/repos/mbedmicro/mbed/issues/1631","id":201723925,"user":{"login":"ducky64","id":1069863,"avatar_url":"https://avatars.githubusercontent.com/u/1069863?v=3","gravatar_id":"","url":"https://api.github.com/users/ducky64","html_url":"https://github.com/ducky64","followers_url":"https://api.github.com/users/ducky64/followers","following_url":"https://api.github.com/users/ducky64/following{/other_user}","gists_url":"https://api.github.com/users/ducky64/gists{/gist_id}","starred_url":"https://api.github.com/users/ducky64/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ducky64/subscriptions","organizations_url":"https://api.github.com/users/ducky64/orgs","repos_url":"https://api.github.com/users/ducky64/repos","events_url":"https://api.github.com/users/ducky64/events{/privacy}","received_events_url":"https://api.github.com/users/ducky64/received_events","type":"User","site_admin":false},"created_at":"2016-03-26T07:38:01Z","updated_at":"2016-03-26T07:38:01Z","body":"I attempted to do some debugging (with GCC 5.2, but hopefully results are still applicable), and found:\r\n- std::fopen fails because malloc fails\r\n- malloc fails because the static heap pointer (in mbed/common/retarget.cpp: _sbrk) is past the stack (well, actually past the range of valid SRAM addresses)\r\n- This is also the case with the initial invocation of _sbrk, but presumably whatever called it had more graceful error handling.\r\n- The static heap pointer in _sbrk is getting clobbered in SystemInit. In particular, NVIC_SetVector in TARGET_NUCLEO_F303K8 thinks there are 101 interrupt vectors (from cmsis_nvic.h), but the linker script only allocated space for 98. This causes the first few bytes of the .data segment to be overwritten.\r\n- Changing the NVIC number of vectors to 98 solves the problem."}}