C++ exceptions in cortex-m7 vs. cortex-m4

[dflogeras]

Hi, does anyone know why this might be:

If I compile a simple C++ test program (say RT-STM32F407-DISCOVERY-G++ demo), and make sure to remove "-fno-exceptions" and place the following code in main:

Code: Select all

try {
  throw 1;
}
catch( ... ) {
  // all ok
}

It works as expected. That is, the exception is thrown, caught, and then main gets on with its progress.

Now the clincher. If I do the same thing but target my STM32F7 (starting with RT-STM32F769I-DISCOVERY demo) and add C++ support with exceptions, the same code as above doesn't get into the catch() block, and treats it as an unhandled exception (eventually ending up in the std abort handler and thus chSysHalt() infinite loop).

I've tried this on ChibiOS-18.2.1, with the ARM GCC7-2017-q4-major toolchain.

[Giovanni]

It could be an error in the linker script, you should verify the map file and compare with the one of F4.

Giovanni

[dflogeras]

It could be an error in the linker script, you should verify the map file and compare with the one of F4.

Giovanni

Hi,

After inspecting both map files, in particular the exception handling functions (__cxa_*), I noted that in the F4 they were all in 0x8000000 flash, while on the F7 they were in the 0x200000 (F7 specific ITCM flash).

If I modify the F7's linker file and change the sections that were in flash1 to flash0, the exception handling works as expected. I'm sure this isn't the solution, but it is definitely part of the cause.

[Giovanni]

Moving in bug reports, I need to understand the issue.

Giovanni

[dflogeras]

Thanks!

According to https://stackoverflow.com/questions/40532180/understanding-the-linkerscript-for-an-arm-cortex-m-microcontroller

ARM.extab and .ARM.exidx are related to unwinding. You can find more information here http://infocenter.arm.com/help/topic/co ... index.html.

Also, I think this is related:
https://github.com/espressif/esp-idf/issues/459

and the patch:

https://github.com/espressif/esp-idf/pull/681

I don't pretend to understand but it may help you when you get back to this.

[dflogeras]

Another tidbit, in case it helps you later. Only one of the changes was required in STM32F76xxI.ld to fix the problem I am seeing. Change:

REGION_ALIAS("VARIOUS_FLASH", flash1);

to flash0.

[Giovanni]

Would be possible to setup a very simple example project for this?

Giovanni

[dflogeras]

Absolutely,

This started as a copy of testhal/STM32/STM32F7xx/SPI from ChibiOS_18.2.1

I converted it to c++, then simplified main() to the most basic to show the problem. The way I uploaded it, it uses the default linker script, but I've also included a modified one to show how it changes the outcome (I wont say fixes it since it might just be a band-aid). Just uncomment the linker-script line I left in the Makefile to use the modified one.

I ran it on a F769NI but the original SPI demo was meant to run on a F746 and should be able to try it on that depending on which hardware you have in your arsenal.

I used the gcc-arm-none-eabi-7-2017-q4-major compiler to test with, if you want the exact same environment

exceptions.zip

(15.07 KiB) Downloaded 529 times

Thanks,
Dave

[Giovanni]

bump

[Giovanni]

Hi,

Scatter files received changes for a problem that could be the root cause for this. Would be possible to re-check this using the latest version?

Giovanni