tago

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

11 posts in this topic

Posted (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 by tago

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

Posted (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 by tago

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Thanks in advance.

1 person likes this

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

Thanks for looking into it @Hawkeye

ps can't find a like or thank you button

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now