STM32F205 fails after setVectorTable call

[vneff]

Posted on April 04, 2014 at 22:43

There is something basic I am overlooking but haven't been able to figure out what.

I've written a bootloader that seemed to work, but maybe it just happened to fall into the new program. I seem to loose control after I specify a different location for the vector table. For my testing, I display a string before and attempt to display a string after the vector table change. Here is the code snippet. Why does it not work.

RCC->CIR = 0x00000000;
USART3_OutString(''About to setVectorTable'');
SCB->VTOR = FLASH_BASE | (addressBegin & 0x1FFFFE00);
USART3_OutString(''after setVectorTable'');

The first string prints OK, the second does not. The print routine is a standard polling print. It should not matter where the vector table has been moved at this time. I'm guessing I am not turning off interrupts properly. Than

[Tesla DeLorean]

Posted on April 04, 2014 at 23:02

Lose control of it too where? Is a debugger enlightening?

How about you print out the value you're about to set it too, and print out a list of vectors contained there?

What interrupts might be occurring? SysTick, HardFault?

What's the base address? Is it on a 512 byte boundary?

[vneff]

Posted on April 04, 2014 at 23:20

Thanks for the response. I have verified the addresses and the data. But, that is not currently the point. I'm just trying to figure out why the program doesn't seem to reach the 2nd print statement. It seems that if the interrupts are off, it should not matter what I do with the vector table pointer. So, I guess the real question is:

Does this statement:

RCC->CIR = 0x00000000;

turn off the interrupts? If it doesn't, then I can understand why the 2nd print does not work. Incidentally, I wasn't able to get debugging to work, so I use the uart for debugging. Vance

[Tesla DeLorean]

Posted on April 04, 2014 at 23:51

Does this statement: RCC->CIR = 0x00000000; turn off the interrupts?

It turns off a selection of interrupts related to the RCC device/peripheral, I don't believe it does anything particularly useful in the context you are using it in.

You generally want to teardown any existing interrupts you have running, by say disabling the peripheral, or disabling the interrupts coming from that peripheral, or disabling them in the NVIC.

There are things like __disable_irq() too. But its a bit of a cop-out if you aren't servicing them, and don't plan too, the boot loader should turn things off, or hand control to the app with things in an equitable state.

So I'll ask again, what interrupt do you have running? Do you service those routines? Does the Hard Fault handler in your new vector table do any thing? Perhaps if it is just has a while(1); loop, you could replace that with a USART output of some description. That way you'll know if it ended up there.

[vneff]

Posted on April 05, 2014 at 20:50

Thanks again Clive!

Yes, there was an interrupt still running, a timer tick.  I do have print statements in the Fault handler, but apparently, it wasn't being triggered.  I'm guessing that in the case of the application that wasn't starting, the undefined interrupt loop was probably being ran.  In the case of the application that did start, there was a timer interrupt defined and so the bootloader was able to finish executing.  I now disable the timer interrupt and then call __disable_irq just to be sure interrupts are disabled.  Every thing runs as expected.

Thanks again - mystery (to me) solved!

Vance

[vneff]

Posted on April 06, 2014 at 17:24

Just to be complete:  I do have to call __enable_irq in the application code if I call __disable_irq in the boot loader.

Vance