Core unresponsive after app upload (current toolchain not working correctly anymore)

[tago]

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

[tago]

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

 

[Hawkeye]

@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

[tago]

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

[Hawkeye]

@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

[tago]

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.

[Hawkeye]

@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

[tago]

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

[tago]

It would be nice if someone who knows a thing or two about the toolchain stuff could look into this.

Thanks in advance.

[Hawkeye]

@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

[tago]

Thanks for looking into it @Hawkeye

ps can't find a like or thank you button

[tago]

Any news regarding the Windows compilation issue?

[tago]

Any news on this? @Hawkeye

[Hawkeye]

@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

[tago]

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?

[Hawkeye]

@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

[tago]

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?

[Hawkeye]

@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

[tago]

@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.