# Core unresponsive after app upload (current toolchain not working correctly anymore) **URL:** \ **Category:** MIOS programming (C)\ **Created:** [July 22, 2020, 12:57pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835 "2020-07-22T12:57:36Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [July 22, 2020, 12:57pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/1 "2020-07-22T12:57:36Z")
Hi, i compiled an unaltered NG app and uploaded it to the core ( STM32F4). MIOS Studio told me it was uploaded successfully. During upload i could see ‘bootloader mode’ on the display. But now the core is unresponsive and MIOS Studio doesn’t find it anymore. One red led is blinking the other is permanently on. A green led near the micro USB port is on as well. The Display which is connected to the core shows nothing. How can i check what’s wrong? Thank you   ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [July 22, 2020, 1:20pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/2 "2020-07-22T13:20:28Z")
This is the NG app compilation output: ``` make rm -f project.hex ------------------------------------------------------------------------------- Application successfully built for: Processor: STM32F407VG Family: STM32F4xx Board: MBHP\_CORE\_STM32F4 LCD: universal ------------------------------------------------------------------------------- arm-none-eabi-size project\_build/project.elf text data bss dec hex filename 294048 224 173520 467792 72350 project\_build/project.elf 20000000 D \_\_ram\_start 2002a6b0 B \_\_ram\_end ```   ---
**Author:** ![Hawkeye](https://forum.midibox.org/user_avatar/forum.midibox.org/hawkeye/32/223_2.png) [@Hawkeye](https://forum.midibox.org/u/Hawkeye)\ **Post date:** [July 22, 2020, 1:25pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/3 "2020-07-22T13:25:42Z")
which OS did you compile on? Might it be linux? If so, I have a similar problem with the linux toolchain - i believe this happens because the NG project uses “upper memory”, the extra 64KB of RAM that is available on the F4s. Somehow currently the Linux toolchain produces an executable that won’t run, at least for me. If you compile your modified app with the toolchain on MacOS (or i also believe on Windows), all is right. Suggestion to solve your problem right now: jumper the core to bootloader hold, then MIOS Studio sees the core in bootloader mode, then reupload either the NG version from [ucapps.de](http://ucapps.de) or a version self compiled under MacOS. I’ve yet got to find out what causes the problem with the Linux toolchain, if anyone has any clues why compilation of apps using this upper memory segment is problematic there, please shoot :). Hopefully this was at least a bit helpful, even if it is not a full solution. Many greets, Peter ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [July 22, 2020, 1:30pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/4 "2020-07-22T13:30:54Z")
Hi thanks for your fast response. I’m using Windows 10. I’ve done it successfully before on Win 10. The only thing that works now is starting all over and uploading the bootloader via ST-Link again and then a precompiled NG app via MIOS Studio. (i haven’t tried the bootloader hold trick yet) Greetings ---
**Author:** ![Hawkeye](https://forum.midibox.org/user_avatar/forum.midibox.org/hawkeye/32/223_2.png) [@Hawkeye](https://forum.midibox.org/u/Hawkeye)\ **Post date:** [July 22, 2020, 1:39pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/5 "2020-07-22T13:39:50Z")
, no problem! The bootloader hold should work, but if you have an ST-Link, that is perfect as well. Strange it does not work under windows, too. I’ve not set up compilation on a Windows box yet, can only state that i have the problem under Linux and that’s why i currently have reverted to a MacOS compilation machine (which was standing around doing nothing anyways :)). Sorry, can’t currently say what’s causing it, other than that i would also very much like to know why it is happening and that you could solve it probably with compilation on a MacOS box. Best regards, Peter ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [July 22, 2020, 3:08pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/6 "2020-07-22T15:08:13Z")
I tried an older altered NG app hex file which still works. It really looks like it doesn’t compile correctly anymore. But what has changed? I think my toolchain hasn’t changed. Unfortunately i don’t have a Mac at my disposal. ---
**Author:** ![Hawkeye](https://forum.midibox.org/user_avatar/forum.midibox.org/hawkeye/32/223_2.png) [@Hawkeye](https://forum.midibox.org/u/Hawkeye)\ **Post date:** [July 22, 2020, 5:09pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/7 "2020-07-22T17:09:22Z")
as far as i understood, more RAM was required to drive new WS2812 LEDs, e.g. for LED-ring applications with hundreds of LEDs.  As NG already requires some RAM, this then required access to the “high memory” part of the STM32F4 - its main memory is segmented in a 128kb main memory and a 64kb (“high mem”) block. I guess your old NG apps that still work well don’t have this addition (number of supported LEDs increased). Our toolchains in Linux and Windows seem to have trouble building an app like that - i’d guess it must be something simple like a compiler flag or such. As a solution for you and if your app does not depend on these LEDs, you could look for the git commit raising the number of these LEDs and reverting it back (just for your own app, of course). It would then require less RAM and should work again when built on Windows/Linux. Not guaranteed though, but maybe worth a try :). But this is of course no good solution - so, if someone is able to find out why it won’t work under Windows/Linux (e.g. by looking at the differences to the Mac toolchain), this bit of insight would also be highly welcome from my side, as i currently need two machines for building apps that require more than 128kb of RAM :). Many greets, Peter ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [July 23, 2020, 10:34am UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/8 "2020-07-23T10:34:37Z")
Thanks Peter, reverting back before the WS2812 change works. If i only had some experience with C, i 'd be glad to help. But that’s defnitely too complicated for me. I hope there will be a better solution. Best ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [July 27, 2020, 9:56pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/9 "2020-07-27T21:56:37Z")
It would be nice if someone who knows a thing or two about the toolchain stuff could look into this. Thanks in advance. ---
**Author:** ![Hawkeye](https://forum.midibox.org/user_avatar/forum.midibox.org/hawkeye/32/223_2.png) [@Hawkeye](https://forum.midibox.org/u/Hawkeye)\ **Post date:** [July 28, 2020, 7:43am UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/10 "2020-07-28T07:43:51Z")
fully agreed! Looked into it a bit more, I think it is probably a simple linker config setting that is different between Mac/Linux/Windows - e.g. the newest LoopA version accesses a 64KB RAM block of core-coupled memory available on the STM32F4. When building on Linux, the extra RAM usage is put into the “data” segment, which is wrong: ``` arm-none-eabi-size project\_build/project.elf text data bss dec hex filename 220080 59040 123592 402712 62518 project\_build/project.elf 20000000 D \_\_ram\_start 2002c968 B \_\_ram\_end ``` This will crash the app, but it can be recovered from bootloader hold. On a Mac build, the extra RAM used properly goes into the bss segment and a ram\_start\_ccm linker memory region appears that is used: ``` arm-none-eabi-size project\_build/project.elf text data bss dec hex filename 220112 1440 181192 402744 62538 project\_build/project.elf 10000000 B \_\_ram\_start\_ccm 1000e100 B \_\_ram\_end\_ccm 20000000 D \_\_ram\_start 2001e868 B \_\_ram\_end ``` This then executes fine on the STM32F4 - if anyone (e.g. ?) knows what’s the culprit, please shout - i’d otherwise investigate when there is a bit more time. Many greets, Peter ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [July 28, 2020, 1:26pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/11 "2020-07-28T13:26:45Z")
Thanks for looking into it ps can’t find a like or thank you button ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [March 30, 2021, 7:52pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/12 "2021-03-30T19:52:10Z")
Any news regarding the Windows compilation issue? ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [June 21, 2022, 11:20am UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/13 "2022-06-21T11:20:03Z")
Any news on this? ---
**Author:** ![Hawkeye](https://forum.midibox.org/user_avatar/forum.midibox.org/hawkeye/32/223_2.png) [@Hawkeye](https://forum.midibox.org/u/Hawkeye)\ **Post date:** [June 22, 2022, 11:04pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/14 "2022-06-22T23:04:11Z")
i switched to a Mac m1 a while ago and never looked back, it’s awesome, as powerful as my 8-core i7, which cost a lot more, using a fraction of the electrical power at a higher single-core speed (a lot more responsive). You can still get a mini m1 for a bit above 600€, which is a steal for the offered package. The existing (old) toolchain/compilation works fine here, also working with 64kb “upper RAM” for the STM32F4. Upgrading the toolchain to the newest release would be some work, so i’d recommend going the established route - i had used a “free” Hackintosh before, so it’s also a possibility to build e.g. MIDIbox NG on most common PC hardware, too. The MIDI implementation on Mac is also way better than anything Windows, so i did not investigate further. Best regards and enjoy! Peter ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [June 23, 2022, 10:42am UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/15 "2022-06-23T10:42:00Z")
Thanks A pity Windows is not supported anymore. I think that’s makes it lesser accessible to us Windows people. Is there really no one in reach who has the chops to update the toolchain? For the love of the Midibox project. If i only had an idea about those things, i would do it. Maybe i can go the Hackintosh route, but that sounds like much work better invested in other things. So with a Hackintosh i can compile the most recent NG app?   What do you think about the situation? Any chance to get it working for Windows/Linux again? ---
**Author:** ![Hawkeye](https://forum.midibox.org/user_avatar/forum.midibox.org/hawkeye/32/223_2.png) [@Hawkeye](https://forum.midibox.org/u/Hawkeye)\ **Post date:** [June 23, 2022, 6:41pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/16 "2022-06-23T18:41:00Z")
yup, i’d either recommend a hackintosh or a cheap used mac machine, it will also give you a lot more stable USB MIDI drivers. Many greets, Peter ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [June 23, 2022, 7:16pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/17 "2022-06-23T19:16:04Z")
> 30 minutes ago, Hawkeye said: > > yup, i’d either recommend a hackintosh or a cheap used mac machine, it will also give you a lot more stable USB MIDI drivers. > > Many greets, > Peter Do you mean stable USB drivers for development purposes? I’d only use a Hackintosh/Mac to be able to compile an app, not for music making, if there is no other way around it. Do you know who did the original Windows toolchain? ---
**Author:** ![Hawkeye](https://forum.midibox.org/user_avatar/forum.midibox.org/hawkeye/32/223_2.png) [@Hawkeye](https://forum.midibox.org/u/Hawkeye)\ **Post date:** [June 24, 2022, 12:50pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/18 "2022-06-24T12:50:56Z")
Thorsten released the Windows toolchain - and it is working, just accessing the 64KB extra memory region of STM32F4 will crash the app, maybe it is a simple linker setting, but i investigated a while back and found no easy solution. On top, under windows, USB MIDI transfers are often very unstable, i.e. when flashing new firmware releases when developing you often have to either rescan MIDI ports or restart MIOS Studio for continuous uploads, which is really frustrating when developing. That is not necessary on a Mac, so you know my recommendation - you can get a used macbook air for ~300€ - while it’s not as fast as an M1, it will do the job - imho for that price, it’s not worth trying to improve the windows situation with the upper 64kb block, as the Windows USB stability situation cannot be fixed by us. Many greets, Peter ---
**Author:** ![tago](https://forum.midibox.org/letter_avatar_proxy/v4/letter/t/e8c25b/32.png) [@tago](https://forum.midibox.org/u/tago)\ **Post date:** [June 24, 2022, 3:44pm UTC](https://forum.midibox.org/t/core-unresponsive-after-app-upload-current-toolchain-not-working-correctly-anymore/20835/19 "2022-06-24T15:44:11Z")
Thanks for providing more details and trying to fix this issue. I know what you mean by rescanning/reconnecting the Core after uploading via MIOS Studio. It’s not ideal but workable. I really hope Thorsten will look into it and update the toolchain. Getting an additional computer is really a hassle. This hobby is already expensive enough. It should also help to get more people onboard with MidiBox, having lower hurdles.