STM32F103VBT bootloader reset different to flash reset.

[rael]

Posted on June 13, 2009 at 08:10

STM32F103VBT bootloader reset different to flash reset.

[rael]

Posted on May 17, 2011 at 13:14

Hi all, I'm making a bit more progress lately, but have encountered some curiousities in running the chip after a bootloaded code reset.

I get incorrect values appearing in RAM values that I've loaded as part of the reset process, and unreliability, yet if I switch to flash boot load, my program runs fine. What pheripheral features does the bootloader use, and how does the boot load reset differ from a normal reset button reset into flash ? I know the serial port is used, but what state is it left in after bootload controlled reset ? Are any interrupts enabled that need to be shut down, or handled in specific ways ? Does the stm32f10x_rcc.h vector table completely overwrite any boot load vectors ? Are any watchdogs enabled that need to be handled ? [ This message was edited by: rael on 11-06-2009 11:15 ]

[swhite]

Posted on May 17, 2011 at 13:14

From Table 2 in

http://www.st.com/stonline/products/literature/an/13801.pdf

Feature/Peripheral State Comment Clock source HSI enabled The system clock is equal to 24 MHz using the PLL USART1_RX pin Input PA10 pin: USART1 receives USART1_TX pin Output PA9 pin: USART1 transmits SysTick timer Enabled Used to automatically detect the serial baud rate from the host. USART1 Enabled Once initialized the USART1 configuration is: 8-bits, even parity and 1 Stop bit RAM - 512 bytes starting from address 0x2000 0000 are used by the bootloader firmware System memory - 2 Kbytes starting from address 0x1FFF F000, contain the bootloader firmware BTW it would be unwise IMO to make ANY assumptions about what the bootloader does or doesn't do. Manufacturers can and do change bootloader code. I'd specifically reset the peripherals the bootloader uses and reinitialize them. [ This message was edited by: swhite on 11-06-2009 14:27 ]

[rael]

Posted on May 17, 2011 at 13:14

Thank you swhite,

I'll have a go at specifically resetting those pheripherals tomorrow. I'm using SysTick, it could be an odd mode on that I'm not aware of, or the USART. Hopefully it's not more obscure !

[rael]

Posted on May 17, 2011 at 13:14

I'm still having problems, and they are pointing more towards the bootloader itself making assumptions about it's ability to correctly reset the chip properly.

The problem isn't watchdog, because I tried enabling that in options, and it had the expected behaviour. I tried putting a port clock setup+port config and LED on code very early on and there is no response from the micro following the bootloader reset, however the code will still load to flash. The most likely explanation simply seems to be that something is blocking the STM32 from resetting, following loading of code. It's not something in my code within the boot process, because that occurs just fine with a fresh reset. The boot code is not loading and then returning to booloader readiness state either, because the bootloader becomes unresponsive until my next boot mode reset. I've tried moving a small block of code to turn on an LED from the beginning of main.c all the way to within a block of code run within my main program loop after lots of pre initialisation and enabling of systick, and it's not until I place this block within the main loop, that everything else fails to initialise. Considering that all this block does is to initialise port A, set bit 7 in pushpull, high, and then loop: while(1){;} , and that everything prior to this either works, or doesn't, based on subtleties of it's placement within the first 5K, I think it's highly probable that STM's factory bootloader is inadvertently using a constant from my code region, instead of their own hard coded memory. As STM have not released their bootloader, this would be hard to definitively test without placing sample values within the suspect region, and then experimenting with boot behaviour as the memory within that region is manipulated. If I'm right, then I hope the error is not due to a mistake in any published STM libraries ! :-?

[rael]

Posted on May 17, 2011 at 13:14

Thanks ST7,

This is all new to me. after looking in the raisonance project for linker related information, I found a map file with the project's name. I can see .isr_vector starting at 0x08000000, and then there are a whole lot of what look to be function names and addresses following. (my functions) Exception handlers seem to start at 0x080011e0 right after the last of my functions addresses are shown, but I don't know if this is normal, or if my functions are being written into an address that conflicts with the exceptions and interrupt handlers. If so, that might explain the problems I'm having, if I've now got enough code that the end of it is overwriting interrupt vectors. I don't know how to change this though. I presume code entered into an interrupt handler between the { } brackets has space to work because there is a pointer to the content, at the interrupt vector table ? Confused :o

[rael]

Posted on May 17, 2011 at 13:14

A further note, If I experiment with code changes in the area that is affecting my reset from bootloader, then I can cause erratic operation of my code in interrupt which operates my motors.

If I were using the STM32 for an assembler program, I would be taking particular care to set interrupt vector tables, RAM locations, and start positions for code space. I can see in my main.c template a NVIC_Configuration selection for RAM or Flash, but I can't find anything for the beginning codespace. Is this set by default somewhere behind the scenes, or do I need a specific instruction and vector to set it from within main.c ? :-?

[st3]

Posted on May 17, 2011 at 13:14

Quote:

I can't find anything for the beginning codespace.

That would be in your Linker settings...