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.
>>So are you basically saying "The F0/M0 series doesn't always really work, don't worry about it and use something else instead?"
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.
>>>>>>>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.
=========================
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.