Problem switching from [Eclipse/GNU MCU] to [Visual/VisualGDB]

[Noyb]

Used to work under ‘OpenSTM32/AC6’ using the ‘GNU MCU Eclipse’ plugin with a ‘GDB SEGGER J-Link Debugging’ configuration, I switched to ‘Visual/VisualGDB’ yet I always land into ‘HardFault_Handler’ on starting up the ‘Visual’ build, while the ‘Eclipse’ build boots into ‘Reset_Handler’ successfully.

Attached below the two GDB configurations at startup, which shows some weird behaviors on the ‘VisualGDB’ side, many things are not set up correctly and cannot be unless fiddling with the ‘Debug settings / Advanced settings’ (btw the ‘command line’ input should have word wrapping because if you enter a too long command line…).

I tried to mimic the ‘Eclipse’ debug configuration, but the ‘VisualGDB’ one still try to read at some invalid addresses causing the ‘HardFault_Handler’ to be triggered. What is the way to go ?

Attachments:

You must be logged in to view attached files.

[Noyb]

Here’s the complete debug configurations’ settings

1- Eclipse ST-Link = OK

2- Eclipse J-Link = OK

3- Visual J-Link = NOPE

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Stopping in “HardFault_Handler” usually a problem in the firmware you are trying to debug (e.g. trying to access an invalid memory location).

The most likely reason for this behavior is incorrect memory layout. You can easily diagnose this by creating map files both in Eclipse and VisualGDB and then comparing them (e.g. check locations/sizes of .text and .data sections, stack pointer/etc). If you get stuck, please try attaching both map files here and we will try to check them for common errors.

[Noyb]

Here we go, 3 different generated map files with 3 differents IDE : sources are same, linker script are same, eclipse obviously add its own salt even though I specifically said “No stdlib, you ****”.

Btw, why when we add a path into the ‘Map file name’ entry, something like ‘$(OutDir)$(TargetName).map’, we get a weird named ‘.map’ file into ‘$(ProjectDir)’ ?

Attachments:

You must be logged in to view attached files.

[Noyb]

Just to add some testing using the ‘ST-Link v2.1’ under ‘Eclipse’ and ‘Visual Studio’ with a little trick, replacing the ‘VisualGDB OpenOCD’ version with the one provided by ‘OpenSTM32/AC6/SystemWorkbench’.

I manually set the speed to 480 kHz in ‘VisualGDB’ to replicate what is set inside ‘Eclipse’. Still, many differences and a ‘Error: flash write algorithm aborted by target’ on the ‘VisualGDB’ side that prevent the code from running.

 

Attachments:

You must be logged in to view attached files.

[Noyb]

Tried this morning again, the J-Link under Eclipse (works) and Visual (don’t works) really no not start the target the same way.

Attachments:

You must be logged in to view attached files.

[Noyb]

Made a little video to show you what happens when I first try on Eclipse, then Visual in one shot, same target and same probe attached. Eclipse works, Visual not.

https://ibb.co/iykZj6

 

[support]

Hi,

Thanks for the detailed description. This might be related to an OpenOCD bug in the STM32L4 driver that refuses to program some sections if they are insufficiently aligned (we were not able to reliably pinpoint it though). The file built with Eclipse shows the size of .isr_vector section to be 0x2f8, while the VisualGDB version has 0x2f4 (due to different size of mcu_cpu_systick_Handler). Please try increasing alignment of your sections and see if this works around the programming errors.

[Noyb]

In ‘Visual Studio/VisualGDB’, I am not using ‘OpenOCD’ but the ‘Segger JLink’ directly, I hope their STM32L4 driver to be up to date. To discard an issue out from ‘OpenOCD’, I copied the ‘AC6/OpenOCD’ into the ‘VisualGDB/OpenOCD’ and I get the same faulty behavior, so it is not an ‘OpenOCD’ problem.

I will check my ‘VisualGDB’ compilation options that might differ a bit from the ‘Eclipse’ compilation options.

Is there a way to import an ‘Eclipse’ project to ensure not forgetting any compilation option ?

[Noyb]

Btw, is there a way to request VisualGDB for verifying download, init regs on start, stop reading at weird memory location like 0x1FFEFFFC (which in fact cause the ‘HardFault_Handler’ to be called) before any of my code to be executed ? See the logs…

[support]

Hi,

As long as Eclipse and VisualGDB use different toolchains, the results might be slightly different (e.g. different optimization algorithms). Also using different input file order could affect the order of functions in the final image and might also trigger some strange bugs.

We would advise doing a quick test – replacing the ELF file generated by VisualGDB with the ELF file from Eclipse and trying a VisualGDB debug session without rebuilding. If this works, the problem is in the build settings (which is most likely, but still worth double-checking at this stage). Otherwise, it is related to debug settings.

Weird memory locations usually come from gdb doing some guessing while unwinding the stack and are usually harmless (exceptions caused by the debugger itself don’t invoke HardFault_Handler).

You can verify the FLASH automatically by adding the “compare-sections” command to the additional GDB commands in VisualGDB Project Properties or use the “Verify FLASH memory” button in the GDB Session window (this will display a detailed report on mismatches if any are found).

[Noyb]

Thanks for the reply.

1- different toolchain : I can understand a difference, but if that’s the reason of the bug, like file order, that’s getting tricky and not that much robust. Is there a way to change file order for compilation ?

2- switching ELF files : I’ll do that, but since the mapping is different, I bet I have to put my breakpoints a bit randomly to catch the right ‘Reset_Handler’. If that doesn’t work either, how should I modify the debug settings ?

3- weird memory location : I specified a STM32L476RC which memory is at 0x20000000 and length is 0x18000. With that information, there should be some kind of barrier to avoid the debugger accessing memory outside the valid range.

4- adding commands : cannot these commands be added to the debug UI of VisualGDB, much like the STLink or JLink debug interface under Eclipse ? If I have to add commands, is there a complete list and where to add it ?

[support]

Hi,

You could try changing the file order by manually editing the .vcxproj file, however there might be other minor differences between the 2 toolchains. We would advise trying to understand the potentially impactful differences between the projects (e.g. section size/alignment) instead, as making the output 100% identical may be impossible in reasonable time.

Different mapping should not affect the “Reset_Handler” behavior. Although it might interfere with debugging (VisualGDB will try several workarounds to restore the broken mapping though), it should allow understanding whether the problem is caused by debug settings or some ELF file properties.

With the weird memory location, to answer that definitively you would need to look into the Segger J-Link stub internals to see what kind of filtering they internally use. In our experience this error message comes up frequently when starting debugging and it never interferes with the actual program flow. Also explicitly trying to read invalid memory via debugger doesn’t trigger the fault handler.

You can add the extra commands via VisualGDB Project Properties -> Additional GDB commands.

[Noyb]

OK, tried replacing the VisualGDB generated ELF file (2.15MB) with the one from Eclipse (5.98MB) and it works indeed.

Starting debug using F5, Visual asks me if I want to rebuild, I select ‘No’, and it starts like expected into ‘Reset_Handler’.

Obviously symbols are read from the ELF file because Visual had no trouble remapping the imported ELF from Eclipse.

It appears that debugging the Eclipse ELF doesn’t trigger reading at weird addresses, hence this is the reason of the ‘HardFault_Handler’ being invoked.

Now I have to understand why the size difference (symbols lacking in the VisualGDB build ?) and the reason of reading at weird addresses.

Attachments:

You must be logged in to view attached files.

[Noyb]

Also, when I want a MAP file to be generated, it is put inside the project folder, could it be possible to place it into the $(OutDir) like in Eclipse ?

When I ass the “-save-temps” flags into the “Command Line / Additional Options”, I get I and S files inside the project folder, could it be possible to place them into the $(OutDir) like in Eclipse ?

Since those are per build generated files, I don’t see the point of having them inside the project folder.

[Author]

Posts