tago Posted July 22, 2020 Report Posted July 22, 2020 (edited) 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 Edited July 27, 2020 by tago Quote
tago Posted July 22, 2020 Author Report Posted July 22, 2020 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 Quote
Hawkeye Posted July 22, 2020 Report Posted July 22, 2020 @tago 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 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 Quote
tago Posted July 22, 2020 Author Report Posted July 22, 2020 (edited) Hi @Hawkeye 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 Edited July 22, 2020 by tago Quote
Hawkeye Posted July 22, 2020 Report Posted July 22, 2020 @tago, 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 Quote
tago Posted July 22, 2020 Author Report Posted July 22, 2020 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. Quote
Hawkeye Posted July 22, 2020 Report Posted July 22, 2020 @tago 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 Quote
tago Posted July 23, 2020 Author Report Posted July 23, 2020 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 Quote
tago Posted July 27, 2020 Author Report Posted July 27, 2020 It would be nice if someone who knows a thing or two about the toolchain stuff could look into this. Thanks in advance. 1 Quote
Hawkeye Posted July 28, 2020 Report Posted July 28, 2020 @tago 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. @TK. ?) knows what's the culprit, please shout - i'd otherwise investigate when there is a bit more time. Many greets, Peter Quote
tago Posted July 28, 2020 Author Report Posted July 28, 2020 Thanks for looking into it @Hawkeye ps can't find a like or thank you button Quote
tago Posted March 30, 2021 Author Report Posted March 30, 2021 Any news regarding the Windows compilation issue? Quote
Hawkeye Posted June 22, 2022 Report Posted June 22, 2022 @tago 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 Quote
tago Posted June 23, 2022 Author Report Posted June 23, 2022 Thanks @Hawkeye 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? @TK. What do you think about the situation? Any chance to get it working for Windows/Linux again? Quote
Hawkeye Posted June 23, 2022 Report Posted June 23, 2022 @tagoyup, 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 Quote
tago Posted June 23, 2022 Author Report Posted June 23, 2022 30 minutes ago, Hawkeye said: @tagoyup, 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? Quote
Hawkeye Posted June 24, 2022 Report Posted June 24, 2022 @tago 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 Quote
tago Posted June 24, 2022 Author Report Posted June 24, 2022 @Hawkeye 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. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.