Issue executing programed firmware on STM32 uCs onboard custom PCBs

[rsoc]

Hi, I am running into an issue running developed firmware an STM32L452RE uC on a custom PCB. I am able to program the uC fine, and the debugger can open (I am running Keil). However, the firmware does not execute. It sits at a random memory position, and I dont understand why. 

As an aside, things that i know are correct -- the boot pin in hardware is tied correctly, the programmer is wired correctly (as I am able to program memory and verify the programming via a separate tool), and i know the developed firmware works as I have been running it on a L452 nucleo board for the last two weeks. 

 

I have tried all the normal things (power reset, software reset, toggling the reset line of the uC, restarting keil, etc etc etc), but none of this gets by the issue. When debugging, this is what the core registers list as:

 

I have no idea why it is doing this, nor how to get by this issue. Can someone chime in if they have experienced this? Thank you

[Tesla DeLorean]

So suggests that IT IS running your code..

Look at a .MAP or create a listing file with FROMELF -csd Project.AXF >Project.LST

Correlate PC/LR with functions and code within your project.

Instrument you code so if it goes off to die in HardFault_Handler() or Error_Handler() you know about it.

Uncheck "run to main()" in debugger if it doesn't get to main() via the first break-point. Debug where it's stuck. Instrument so you understand flow. Get a UART or GPIO working early so you can communicate absent a debugger.

Check flash wait states vs speed you're attempting to run the MCU at.

Check it's not in an infinite IRQ storm, where it stays in interrupt context continuously due to not clearing the source.

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

[rsoc]

Hi, I have the code instrumented for hard fault handling, and the handler itself is never hit. I dont think the vector table is getting programmed properly, but i dont understand how that can be. My reasoning for that thought is VTOR is 0x00000000 when reading back registers via the cube programmer. 

 

I just used a known good image from the stm32 cube for the l452 to see if that would program and execute, and I ran into the same issue of VTOR not being populated. It would make sense if the system is hard faulting due to VTOR not being written, but I cant understand why that would not occur. it is my understanding that VTOR is written in based on the firmware programmed, and is mapped using the standard startup script/linker file for the chip. Is there something there that could be an issue (hardware or software)?

[Tesla DeLorean]

Ok, so the Cortex-M default is to reset SCB->VTOR to zero, it subsequently gets changed in SystemInit() in system_stm32l4xx.c. ST uses #define, my preference is to use the linker symbol for the vectors.

On the STM32 the zero memory is mapped as FLASH, ROM or RAM based on the BOOTx pins, so it should shadow, and then immediately vector to where the code lives natively.

You're seeing 0x08000000 range addresses from your execution. If the ROM were mapped you'd see 0x1FFxxxxx type addresses.

Check the address of your initial SP, needs to be in RAM, 32-bit aligned and also autodecrements, so 0x20008000 would be workable for 32KB RAM device.

Like I said, if you uncheck "Run to main()" in the Keil debugger pane, you can step in from the first instructions in Reset_Handler.

If I have the .AXF and the PC/LR values I'd look at the disassembly and try and understand where it is, and how exactly it would have got there.