System boot mode and Go command STM32f103rbt6

[bob239955]

Posted on March 14, 2008 at 06:23

System boot mode and Go command STM32f103rbt6

[bob239955]

Posted on May 17, 2011 at 12:26

The following re-written post relates to stm32f103rbt6 rev B bootloader v2.0 ID=0x06 41 00 41 Go command documented in AN2606 revision 2 section 2.5 page 19 at

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

.

when I use the Go command to jump to code at 0x080003c8 (or 0x080003c9) it never gets there. Does anyone know what I am doing wrong below and what I can do about it?

Background details;

At the start of flash at 0x08000000 we have ;-

20005000 (initial SP )

080003c9 (initial PC=Reset_Handler)

Which works fine when booting from flash (pin boot0=0,boot1=1).

At the start of the bootloader ROM at 0x1ffff000 we have;-

20000200 (initial SP )

1FFFF749 (initial PC=start of CODE in system boot mode ROM)

Which works fine when booting in system-boot-mode (pin boot0=1,boot1=0).

Indeed commands tried so far work well at 115200 baud. I have read 64k of flash in 16 seconds - which is faster than the bootloader demonstrator v1.0.

However when I use the Go command to jump to 0x080003c8 (or 0x080003c9) it never gets there. Yet if I use the Go command to jump to 0x08000000 - which should be a silly thing to do (jumping to a table) - my breakpoint at 080003c8 is reached. Weird!

This is exactly what I do. Notice ACKs are received indicating success;-

To make the bootloader Go from 0x080003c8 I send/receive UART1 the following at 115200;- (> means sent to UART1, < means received from UART1)

>0x7f (tx autobaud)

>0x21 (tx go command)

>0xde (tx check byte [it is complement])

>0x08 (tx MSB of address to go from)

>0x00

>0x03

>0xc8 (tx LSB of address to go from)

I appreciate to exit from boot mode one should reboot with the system boot0 and boot1 pins at 0 and 1 respectively (and that works)- but I should still be able to GO from the start of the loaded code in flash by specifying the address of the Reset_Handler in the Go command. The code I am attempting to Go from does work, I just cannot GO from it. It seems it never gets reached. The address is not rejected by the GO command. There is valid code at the go address (0x2d 0xF0 0x07 0x01 == bic.w r1, sp, #7).

[ This message was edited by: bobz on 12-03-2008 15:33 ]

[lanchon]

Posted on May 17, 2011 at 12:26

maybe ''GO adr'' actually jumps to the following void* address?

*(((void**) adr) + 1)

if that's the case you should GO 0x08000000, see

http://www.st.com/mcu/forums-cat-6315-23.html

. someone should really disassemble the bootloader...

[bob239955]

Posted on May 17, 2011 at 12:26

The problem is still NOT resolved but I notice there are a number of errors, in AN2606, and in the bootloader.

1) In AN2606; figure11 wrongly shows two consecutive ACKS axpected from the stm32 after sending the GO command 0x21 0xDE.

2) The bootloader 2.0 firmware GO command handler; does not respond by sending a NAK (0x1f) if you give an invalid start address like 0xC8030008 (ie the correct address the wrong way round) [However it DOES respond correctly with a NAK (0x1f) if you send the wrong check byte after the 4 address bytes. So if I were sending a silly start address to GO from I would never know']

3) In AN2606; it says the comms settings use even parity 7 data bits. However my application only works if I use No Parity 8 data bits.

4) In AN2606; it should say that the GO command and ACK should be followed by the address of a table containing [0] the desired SP, [1] the desired PC. It may also be true that the bootloader 2.0 firmware expects to be given the address of a complete vector table, without being able to see the source code it is hard to tell. Please ST show us a bit more flesh so we can ensure that the code we GO to conforms to the requirements of the bootloader.

5) In AN2606 Table 2. It says Systick timer is used for baud detection. It does not say whether the interrupt vector is used and active and more importantly if it is disabled when the GO command is used. Finally is does not say if the application reached by the GO command can or should disable sys tick for its own use.

[ This message was edited by: bobz on 14-03-2008 13:23 ]

[lanchon]

Posted on May 17, 2011 at 12:26

I've never tried the bootloader, but I'm thinking that you can't just jump to the reset handler to launch a cortex app. the cortex is special in that it loads the SP from the vector table during reset, so the reset handler might expect the right custom SP to be loaded (though some of the startup code I've seen loads the SP again with the same value).

so the GO command should actually be something like ''GO stack_pointer reset_handler_adr''. but if the GO takes a single address (for whatever reason it was made that way... compatibility?), then it'd make sense if ''GO adr'' did something like this:

SP = *((int*) adr);

PC = *(((int*) adr) + 1); // and handling the thumb LSB thingy here...

this would fit with the post I linked to above.

so to jump at an arbitrary address you'd need 8 bytes in ram: write the SP and PC values there and GO to them. please tell us if you try this.

[lanchon]

Posted on May 17, 2011 at 12:26

''but it limps along without updating the pointer on the stm32 primer hardware''

I don't understand what you're trying to say, please explain. BTW, it's common that launch guaranties of bootloaders are less stringent than powerup reset guaranties. but being so easy to reset peripherals in the STM32 it's surprising it's not done, if indeed that's the case.

[bob239955]

Posted on May 17, 2011 at 12:26

yes, It's hard to believe that AN2606 can be quite SO wrong here after a second revision. GO should indeed -it seems- be supplied with the address of a table containing

desired SP

desired PC (where to jump to) )(+1)

GO should NOT be given the address to jump to directly as AN2606 EXPLICITLY sayes. ST please correct this in the next revision of AN2606. Notice also that its not good enough for GO to be given the address of a location that contains the desired PC, you HAVE to give it the address of the table conaining the desired SP followed by the desired PC - which is actually rather good - if only AN2606 actually said that!!.

in other words it's fine to give it the address of the start of the vector table already likely to be in flash.

The only trouble I have with that is that the application starts, but it limps along without updating the pointer on the stm32 primer hardware I am trying this on - as if the application is making wrong assumptions about initial values of some peripheral registers because it ran the bootloader first.

Lanchon; thanks for pointing me to Dales post, Good to see it was not something silly I'm doing for once since AN2606 is actually wrong in this case, as you can see from my first post I had discovered that giving the GO command 0x08000000 seemed to work, but the document kept insisting I was wrong - for once I'm not.

ST; the bootloader is really 8-)GREAT8-) and I hope it will always be there, but PLEASE correct the errors in the GO command documentation by the next revision. Thanks.

[ This message was edited by: bobz on 13-03-2008 16:08 ]

[bob239955]

Posted on May 17, 2011 at 12:26

Quote:

''but it limps along without updating the pointer on the stm32 primer hardware''

I don't understand what you're trying to say, please explain.

Basically the program starts as expected, but it does not continue to run 'exactly' as expected.

The pointer is like a display cursor driven by the output from an accelerometer so that it moves when you move and tilt the device.

When I start the firmware application using the bootloader GO command the pointer fails to move when I move the device. It relies on the sys tick interrupts and the SPI (polled).

Therefore you may be right about the vector not being reached. Or it could simply be that the firmware application assumes reset values apply to all registers which may be a wrong assumption when starting it from the bootloader GO command. :-]

[ This message was edited by: bobz on 14-03-2008 12:52 ]

[lanchon]

Posted on May 17, 2011 at 12:26

I'm thinking of what could be going wrong in your case, maybe I've got an idea. the chip aliases either flash, system memory or ram into a range starting at address zero, depending on the BOOT0/1 pins. now I don't remember seeing any way to alter this setting by software, so maybe the loader is forced to launch with sys mem aliased at 0. any dependence on this address range aliasing the flash will make your software incompatible with the bootloader.

I'm thinking, where's the core's vector table offset register pointing to in your app? if you didn't initialize it, it'd be 0, pointing to the alias range. this works for booting from flash but not form the bootloader. if this is the case, try:

NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0);

if you're running from flash. the fwlib samples do this:

void NVIC_Configuration(void)

{

#ifdef VECT_TAB_RAM

/* Set the Vector Table base location at 0x20000000 */

NVIC_SetVectorTable(NVIC_VectTab_RAM, 0x0);

#else /* VECT_TAB_FLASH */

/* Set the Vector Table base location at 0x08000000 */

NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0);

#endif

}

so you can define VECT_TAB_RAM from the makefile. but i think the best option is this:

NVIC_SetVectorTable(vector_table, 0x0);

where vector_table is whatever symbol your startup+linker files use to identify the vector table.

[lanchon]

Posted on May 17, 2011 at 12:26

''NVIC_SetVectorTable(vector_table, 0x0);''

that lib function checks args, I'd use this for more generality:

SCB->VTOR = vector_table;

in the end it seems it's a bug in the bootloader design, since you have to make an effort to render your code compatible with the bootloader, and the default isn't. the GO should have been designed to set SP, PC, *and* the vector table.

or you can consider the fault was in hardware design:

-either they should have made the boot aliasing configurable by software

-or maybe the alias shouldn't exist at all. instead the BOOT0/1 pins would just need to load the proper constant into the vector table offset reg prior to reset.