Need help with STM32 Assembly Instruction

[rcbuck]

I have an application for a STM32F103C8T6 that I made changes to for testing purposes. Now three weeks later I wanted to revert all the code back to the original code. I have a chip that is programmed with the original code and am using it to compare the new generated code. I have everything matching except for one address.

I don't have any knowledge of STM32 assembly code. I am using STM32CubeIDE for the development platform. If there is a way to show the C code next to the assembly code that is generated I haven't been able to find out how to display that view.

The attached image shows the address that is different. The code on the left is the new generated code. The red address on the right is the code that is programmed in the STM32. I'm fairly sure it is a GPIO difference that I am missing. But maybe not.

If there is anyone who programs in STM32 assembly can tell me the difference between the two addresses I would greatly appreciate it.

[ataradov]

It would be hard to tell without knowing if it is code or data.

Do you have corresponding ELF files? At least for the build you have now? If so, run "arm-none-eabi-objdump -d file.elf"  and see what is at that address. Or attach it here if there is nothing secret there.

The difference is in one bit, so it may be a GPIO difference, but it does not have to be an instruction. It may be a data word that is loaded into a register.

[rcbuck]

ataradov, nothing secret. Just a large digit GPS clock I am working on.

The elf file is attached. I had to zip it as the forum wouldn't let me attach a file with a elf extension.

[ataradov]

Here are instructions at this address:

Code: [Select]

80004b0: 482e      ldr r0, [pc, #184] ; (800056c <main+0x1b4>)
 80004b2: a90c      add r1, sp, #48 ; 0x30
 80004b4: e9cd 340c strd r3, r4, [sp, #48] ; 0x30
 80004b8: 940e      str r4, [sp, #56] ; 0x38              <-------------- affected part
 80004ba: f000 fc77 bl 8000dac <HAL_GPIO_Init>
 80004be: 2303      movs r3, #3
 80004c0: 482c      ldr r0, [pc, #176] ; (8000574 <main+0x1bc>)
 80004c2: e9c8 0300 strd r0, r3, [r8]

0x940e is encoding T2 of the STR instruction. 0x950e would be "str   r5, [sp, #56]". It is normal for some temporary registers to be reassigned, but I don't understand how you can have the rest of the program to be the same.

Edit: wait no, it makes sense. r4 and r5 hold values 0 and 2. This code is a part of a big chain of calls to HAL_GPIO_Init(), so one of them is different.

You should have a sequence of calls like this:

Code: [Select]

HAL_GPIO_Init();
............
HAL_GPIO_Init();
HAL_GPIO_Init();
HAL_GPIO_Init(); <----- this is the different GPIO
HAL_IWDG_Init();


[rcbuck]

Alex, I finally figured out how to run the "arm-none-eabi-objdump -d file.elf" command and I see what you show. If I understand you correctly, you are saying the 4th HAL_GPIO_Init() call is where the difference is.

That makes sense as those were the GPIOs I was modifying. The 4th init call looks like this:

Code: [Select]

  /*Configure GPIO pins : UTC_Pin DST_Pin TZ2_Pin TZ1_Pin */
  GPIO_InitStruct.Pin = UTC_Pin|DST_Pin|TZ2_Pin|TZ1_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_PULLUP;
  HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
I was specifically playing with the pullup resistors. I could swear I had them all back to the original settings. I will investigate further and also compare my old and new schematics. I was modifying the GPIOs to match the new board and then modified it back to match the old board. I missed something somewhere. I may have one of the 4 pullups turned on that was turned off originally.

Thanks for your help.

[ataradov]

There are 6 HAL_GPIO_Init(); calls and before that there are a bunch of HAL_GPIO_WritePin() calls. The one that fails is the last one - one before a call to HAL_IWDG_Init();

[rcbuck]

Thanks Alex. I will investigate further tomorrow.

[DavidAlfa]

Goddamnit, use some kind of version control, at least make a daily zip file with the project contents to never run into this issue again

[SiliconWizard]

Goddamnit, use some kind of version control, at least make a daily zip file with the project contents to never run into this issue again

Well yeah. This should at least serve as a lesson for not doing the same mistake again...

[Siwastaja]

OTOH such mistake is a great way to force oneself in the rabbit hole full of interesting and useful skills, including ARM assembly...

[rcbuck]

I don't use version control since my hobby projects aren't that important. I have a NAS that I use for nightly backups. I keep 2 weeks of data on the drive. Since the original code in the MCU is at least 3 weeks old (could be as old as 6 weeks), I don't have that data on the NAS.

The main changes between the current code and the old code is basically the GPIO changes. I use different GPIOs on the new boards and have a current backup of the new code. Out of curiosity I was temporarily converting the new code back to the old code from memory. The old code will never be used again and the old board will be put in a box with all my other old boards in a couple of weeks.

Alex, the last HAL_GPIO_WritePin() call is this:

Code: [Select]

  /*Configure GPIO pin Output Level */
  HAL_GPIO_WritePin(GPIOB, UnusedB2_Pin|Colon_Pin|SecT_Pin|SecU_Pin
                          |HrsT_Pin|HrsU_Pin|UnusedB5_Pin|MinT_Pin
                          |MinU_Pin, GPIO_PIN_RESET);These are all output pins so my pullup guess was wrong. Looking at this code, I suspect the UnusedB2_Pin is the culprit. I don't think I used that pin in the original code.

Unfortunately I cannot confirm that until after 2 AM local time tomorrow morning. DST change occurred in the U.S. at 2 AM this morning. I was watching the clock at that time to confirm my DST code is working properly. The final confirmation of the code will be 2 AM tomorrow morning. I cannot read code from the MCU until after that time as a read causes a MCU reset. I don't want to reset the MCU until after the final code confirmation. I am using the old board to confirm the DST code as I have other minor changes on the new boards. After the confirmation is finished I will only use the new boards and new code from this point forward as the DST code is the same as used on the old board.

I spent hours trying to determine how to handle DST changes. I have everything working properly with one minor gotcha that I didn't address. The clock time information is received from GPS. If the clock is not running due to a power failure at 2 AM local time on DST day, the DST change will not take place until 2 AM the day after DST. If there is a power failure anytime after 2:00 AM DST day the clock will be off by one hour until 2:00 AM day after DST.

I will probably work on the DST code on the new board to try and  solve the gotcha problem. I think I can do it with comparisons of zone offset from UTC and date comparisons between local time and UTC time. I have another board that I use to simulate sending GPS NEMA data to the clock board. That board can send any data I need to simulate time, date and year GPS time. That allows me to test the GPS code on my clock.

Siwastaja, I may pursue learning some ARM assembly for debugging purposes. But I would never want to use assembly to write an application on an ARM MCU. I do use assembly sometimes when I am using the Microchip PIC10F series parts. I switched to C for all my projects about 10 years ago.

[rcbuck]

I found the difference between the old code in the MCU and my modified new code.

I found a copy of the old source code from Sept 30th that I had on a USB drive that I sometimes use for a quick backup. The difference is the old code had a GPIO_PULLDOWN setting vs a GPIO_NOPULL for the new code.

I programmed a spare blue pill board with the old code and compared it to the new code. I saw the single diffence at 0x80004b8 that I was seeing on the MCU running the clock board. I then modified the new code with the same GPIO_PULLDOWN and flashed it to the blue pill. Another comparison run shows no difference between the old code and new code.

Old code from Sept 30th:

Code: [Select]

  /*Configure GPIO pin : PPS_Pin */
  GPIO_InitStruct.Pin = PPS_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_PULLDOWN;
  HAL_GPIO_Init(PPS_GPIO_Port, &GPIO_InitStruct);
New code before pulldown change:

Code: [Select]

  /*Configure GPIO pin : PPS_Pin */
  GPIO_InitStruct.Pin = PPS_Pin;
  GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(PPS_GPIO_Port, &GPIO_InitStruct);
Thanks Alex for pointing out where to look for the difference. I will now revert back to the new code before I started the "from memory modifications" since that is the code the new clock boards will run.

[brucehoult]

Goddamnit, use some kind of version control, at least make a daily zip file with the project contents to never run into this issue again

+1.

Basic use of git is Just Not That Hard.

Code: [Select]

cd <project directory>
git init
vi .gitignore   # add any file types or directories that should not be saved e.g. .o build
git add .
git commit -m "Initial commit"

And then between each change repeat the last two commands (with appropriate message).

[DavidAlfa]

I also a lot of hobbie stuff, and usually make a local git when possible, most IDEs support it...
While you can lose a whole day trying to revert something or finding which recent change is causing a bug, using git takes seconds or minutes.
I also started using it this year, you can't imagine how much it improves the programming pain.

[thm_w]

In addition to version control, if you use Windows, it has a built in incremental backup feature which will let you easily recovery specific older versions of files (File History).
No screwing around with USB drives, etc.