Order of Operations

[gary239955_stm1_st]

Posted on November 12, 2009 at 05:35

Order of Operations

[gary239955_stm1_st]

Posted on May 17, 2011 at 13:24 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6Yi&d=%2Fa%2F0X0000000bqh%2FW73ajHf3oAgagoIxWqB6jd5S0PLArmIVG1TqhmKqbmg&asPdf=false

[tomas23]

Posted on May 17, 2011 at 13:24

Depends on toolchain, in Keil uVision you can set up ''Connect under reset'' - the HSI starts operating at the reset and the ICE can place bkpts before ANY program starts. Very useful when entering low power modes quickly after start-up 🙂

[st3]

Posted on May 17, 2011 at 13:24

Obviously, the clocks have to be set first - because everything else depends upon them.

And you obviously need to have the interrups properly set-up before you start using them. etc...

[picguy]

Posted on May 17, 2011 at 13:24

It may be just me but I generally zero all RAM then set processor clocks. (The time to zero RAM allows things to settle down some.) It also makes it easier to see what RAM has been overwritten.

I do all initialization, enabling interrupts last. I then enter my mainline. This order helped when I failed to set two wait states when setting 72 MHz. It was still confusing and worked differently on two different demo boards. SIDE NOTE: Due to a past problem after zeroing all RAM I setup enough GPIO to test a PCB push button. I then wait until the push button is not pressed. This gives me a chance to use a debugger in case I made a mess of things setting up the processor clocks. YET ANOTHER SIDE NOTE: if your OS uses svc and loops in your svc handler until some interrupt takes place you should make svc the lowest priority interrupt. In my mind svc should act like an interrupt but maintain the current interrupt priority. My educated guess about what should happen was wrong.

[philippe239955_st]

Posted on May 17, 2011 at 13:24

Hi,

Bit late entering this forum, but back to Gary's code above. One thing troubles me with the interrupt priorities and most particularly the use of ''NVIC_PriorityGroupConfig(xxx)''. From what I know this function should only be used once and before assigning IRQ channel priorities. The priority group functions arguments are: NVIC_PriorityGroup_0 //0 bits for pre-emption priority 4 bits for subpriority NVIC_PriorityGroup_1// 1 bit for pre-emption priority 3 bits for subpriority NVIC_PriorityGroup_2// 2 bits for pre-emption priority 2 bits for subpriority NVIC_PriorityGroup_3// 3 bits for pre-emption priority 1 bit for subpriority NVIC_PriorityGroup_4// 4 bits for pre-emption priority 0 bits for subpriority Once pre-emption priority and subpriority set, only then each IRQ channel pre-emption and sub priority can be set, and of course respecting what has been ''initialized''. From what I see here it seems to be a miracle the interrupts operate as they should, priority wise that is... Phil