cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIDE v1.12.0 disassembly addresses change

JWend.1
Associate II
  • Bug Report

When I look at the disassembly of my code, the addresses seem normal. As soon as I scroll through the disassembly, all the addresses change from even to uneven. Further scrolling does not change the addresses back. We look at the disassembly with our students and this is very disorienting.

  • Additional Info

We use an Nucleo-L073RZ with the built in ST-Link V2. (Version: V2J41M27)

The STM32CubeIDE Version is v1.12.0 on Windows 10.

The Project is not Optimized. (O0)

The Project is generated with the built-in CubeMX using the default configuration.

Attached is a video demonstrating the problem and the main.c file that is used to generate the assembly.

Any help is appreciated.

2 REPLIES 2
Rim LANDOLSI
ST Employee

Hello @JWend.1​ and welcome to the community,

I have tried to reproduce this issue but everything works fine from my side with CubeIDE version 1.12.0 and CubeMX version 6.8.0. If I have well understand your issue when you scroll through the disassembly the addresses change.

Thanks,

Rim

I observe a very similar issue. Disassembly window shows incorrect addresses: uneven base addresses for instructions not matching disassembly in .list file.

STM32CubeIDE Version: 1.16.0 Build: 21983_20240628_1741 (UTC)

STM32F103

I used -O2, tried both -g and -g3.

 

Disassembly in .list file (correct):

const char *ShellCmd_t::get_str_arg(const char *s, int arg_idx)
{
for (int i = 0; i < arg_idx; i++)
8000158: 2200 movs r2, #0
while (*s != 0 && (*s == ' ' || *s == '\t'))
800015a: 7803 ldrb r3, [r0, #0]

Disassembly in STM32CubeIDE window: (incorrect):

08000156: bx lr
_ZN10ShellCmd_t11get_str_argEPKci:
08000158: movs r2, #0
_ZN10ShellCmd_t11get_str_argEPKci:
08000159: movs r2, #0    <---- duplicated instruction with address shifted by one
0800015b: ldrb r3, [r0, #0]

imiron_1-1721776261470.png

Debugger then steps incorrectly over these instructions that show incorrect addresses.

It happens randomly at different functions, even library functions like __do_global_dtors_aux or frame_dummy.