Why program get into Endless loop at end of startup file?

[ylor]

I am working on stm32f205RBT. I have an IAP loader from ST from EVAL board that I made my adjustment. Loader works great on other devices with other adjustments. program goes to main after the loader like it should and works good until I'm trying to communicate with UART. The problem that appears is that it get into some endless loop written in the end of startup.s file after all interrupt lists and before User Stack and Heap initialization. I have never seen program reached this area, does anyone have any idea what is this? What may cause this? and how can I solve it?

Thanks in advance.

[Bob S]

Just to make sure I understand - you have your loader and your application. Now you are trying to add UART communications to which - the loader or the application? And when you do, which program hangs in the startup code - the loader or the application? Did this combination of loader and application and hardware ever work (like before you added the UART code)?

Could this be some hardware that the loader initialized and failed to de-initialize? Perhaps an interrupt that is still enabled?

I don't have the startup code for the F2xx series handy, but for the families I do have, the startup code sets the stack pointer, copies the initialized data, zero-fills the uninitialized data, calls SystemInit(), initialized the c run-time library and calls main. You can find the startup file (called something like Startup_STM32F205.s) either in your project directory or in your STM32Cube repository (on Windows typically in C:\Users\YourUserName\STM32Cube\Repository\.....).

[Tesla DeLorean]

The Default Handler is a dumping ground for interrupts you fail to provide service routines for.

Deinitialize any peripherals/interrupts you are using in the loader but not in the application.

[ylor]

Sorry for late answer, I had other urgent project.

@Bob S​ :

I have both loader and app, loader at 0x08000000 and app at 0x08004000.

Uart worked fine when only app was on the MCU at 0x08000000, and when I added loader and tried to send UART message when debugger went to my app, it got into this endless loop.

Both loader and app has startup code, and this loop is in loader startup.

This combination is working on other devices with same MCU, the only difference is which UART it is using, and I made all necessary changes.

@Community member​ :

The only thing I'm using in the loader is UART, but with no interrupts, only polling. I make sure that all Interrupts are disabled when loader starts.

Thanks again.

[Tesla DeLorean]

You need to make a specific determination about where it is, there are several infinite loops

Default_Handler

HardFault_Handler

Error_Handler

etc

[ylor]

It's nothing of this default handlers. It's in almost end of startup file, after all interrupt lists and before User Stack and Heap initialization.

I have no idea and never seen program get into this part of file.

[Tesla DeLorean]

Well then you're going to have to check clocks and flash wait states, and step your code until you understand how it gets there.

Not much to work with here.

[ylor]

Thanks

[ylor]

I am working with Keil uVision5, I looked at Call Stack tab and it showed Default_Handler and xPSR register in ISR field showed 68, which is UART4 I think.

IT's make sense, because it get into this loop immediately after I send a message to the MCU, But why dosent it handle it in my program like it should and like it is on my other devices?

Maybe with this information you could help me?

[Tesla DeLorean]

DMA2_Stream5 or ETH would be more probable