I've seen multiple threads around the internet about the issue I'm having with no solution. So here's another thread:
I can't get the ST-Link/v2 debugger to work. When I compile the project in uVision 5 and flash a board with the STM32F070CB I'm using this all works great.
But when I try to debug the debugger doesn't go into main() in startup_stm32F070xb.s, instead it goes through all of the lines below (past main) to where the arrow is:
IMPORT SystemInit LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 <--- ENDP
I've tried everything, I checked all the project settings at least a 1000 times.
This is code that was generated straight from STM32CubeMX using HAL but no OS.
I can get debugging to work on the STM32F0Discovery board with the example project. But I can't get it to work when I try to create my own project on that same devkit with the exact same project settings. When I do that I have the exact same problem as described above.
>>>>>>>No, I'm saying if you are stepping through assembler code to understand why your code isn't working that you need to be sufficiently familiar with the CPU, tool-chain and the debugger for it to be useful. That there isn't a one-to-one relationship between assembler and high-level source code shouldn't be surprising. Stepping through high-level source will also be non-linear in many cases.
Loading R0 with __main isn't calling anything.
=========================
Ah ok, that's useful to keep in mind of course. Perhaps I wasn't clear in my explanation earlier: I wasn't trying to step through assembler code. It's just that when I set breakpoints in C code earlier it wouldn't get to the C code and instead stop at that part of the assembler code; that's all it had to show me...
Again, for people who missed it: the reason was the debugger tool couldn't see the object files (that where there) because they were on a networked drive (Windows OS). The solution was to put the whole project on the drive of the local machine.