stm32f103vbt6 Interrupt Numbers ?.

[Chris Quayle]

Posted on July 20, 2017 at 00:15

Evaluating the above processor using gcc toolchain and openocd and J-Link. Not using cmsis (various reasons) and writing all the low level hal and header files, as a way to become more familiar with the processor. Already have  a simple non interrupt based program running, but need to understand the relationship between the interrupt numbers for the device and how these are derived. From what I can see, each device has a different set of interrupt numbers to control access to the nvic, but can find no docs that define that, after extensive web search and scan of the device data sheets etc. Would assume that this has been defined and docs must exist somewhere ?...

Regards,

Chris

[Vangelis Fortounas]

Posted on July 21, 2017 at 01:42

Hello Chris!!

Look at

http://www.st.com/content/ccc/resource/technical/document/reference_manual/59/b9/ba/7f/11/af/43/d5/CD00171190.pdf/files/CD00171190.pdf/jcr:content/translations/en.CD00171190.pdf

paragraph 10.1.2

Theese are the  definitions you searched for.

Regards.

[Chris Quayle]

Posted on July 21, 2017 at 14:02

Hi,

Thanks for the reply. I'm looking at RM00008 tech manual, and paragraph 10.1 describes the dma controller. The interrupt numbers for the (non connectivity) devices are at Table: 53, Page: 172-174, which is fine, but still doesn't explain how that is related to the nvic interrupt enable/disable and priority setting table entries. I don't have cmsis sources to see how that is done, but assume some indexing, bit twiddling and masking to access the correct field for the peripheral. Is this relationship defined anywhere, or perhaps point me to the cmsis sources so that I can work it out ?.

Correction: Was looking at an older version of RM0008 manual earlier. The latest (11-2015) has the interrupt numbers for the device at Table: 63, Pages: 203-205, but still can't find any definition on how those interrupt numbers are related to the nvic enable/disable and priority etc entries...

Regards,

Chris

[Tesla DeLorean]

Posted on July 21, 2017 at 20:15

The NVIC has hundreds on IRQ inputs, the table describes how these are wired up on the STM32 parts. The numbers translate to bits within the NVIC, and provide an inherent sequence/level of priority. You can change the priority settings, and if you have two identical settings the pin ordering internally breaks the tie.

[Vangelis Fortounas]

Posted on July 21, 2017 at 16:31

Hello again!!

This time must try

http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/DUI0552A_cortex_m3_dgug.pdf

  from ARM

STM32F1xx series contains M3 cortex cpu. M3 peripherals like NVIC, MPU,  Systick, are common for all M3 containining MCUs All information  about M3 is in this link.

ST and any other M3 based MCU manufacturer provide detailed info about  their devices assuming that someone is familiar with M3 cpu.

Regards!

Vf

[Chris Quayle]

Posted on July 21, 2017 at 19:32

Vf,

Thanks again for the reply. Have already looked at that manual, but nowhere does it describe how the interrupt number relates to the entries in the nvic set/enable, priority setting areas. All it does is quote CMSIS function usage eg: Section 4.3.8, NVIC_GetPriority (IRQn_Type IRQn) etc

.

Don't want to sound difficult, but it seemed like a simple unambiguous question to me :-), so is this info documented, or if not, can we access the cmsis sources, so we can work it out ?...

Regards,

Chris

[Chris1]

Posted on July 21, 2017 at 20:45

You may have to look at ARM's CMSIS source (file core_cm3.h, widely available).

There you can see various mask definitions and translations from IRQ number to register bits, for example:

/**
* @brief Enable Interrupt in NVIC Interrupt Controller
*
* @param IRQn The positive number of the external interrupt to enable
*
* Enable a device specific interupt in the NVIC interrupt controller.
* The interrupt number cannot be a negative value.
*/
static __INLINE void NVIC_EnableIRQ(IRQn_Type IRQn)
{
 NVIC->ISER[((uint32_t)(IRQn) >> 5)] = (1 << ((uint32_t)(IRQn) & 0x1F)); /* enable interrupt */
}�?�?�?�?�?�?�?�?�?�?�?�?

[Vangelis Fortounas]

Posted on July 21, 2017 at 20:15

Hello !

IPSR register of Cortexm3  holds the interrupt number of an ISR

 so when you enable  n interrupt in NVIC, after interrupt  you will take the number n when you read the IPSR

Is  this a relation?

[Chris Quayle]

Posted on July 21, 2017 at 23:00

 ,

 ,

Hi Again,

Perhaps i'm not explaining it very well, so let's try an example of the sort of thing I need to be able to do. Reading the programming manual, PM0056, April 2010. In nvic section starting 4.3.2, we see a description of the 32 bit interrupt enable register. If I want to enable an interrupt for timer ♯ 1 for example, what is the translation between interrupt number for timer ♯ 1 and the bit that needs to be set ?. Or, how do I know which bit to set to enable timer ♯ 1 interrupt ?. Same goes for other nvic registers. This is a serious gap in the documentation as far as I can see.

The problem is that all st docs assume the use of cmsis and i've already said that that won't be used here, for various reasons. I should be able to bare metal program your devices without using it, using only the official docs...

Regards,

Chris

[Chris1]

Posted on July 21, 2017 at 23:14

You may have to look at ARM's CMSIS source (file core_cm3.h, widely available). I agree this information ought to exist in a proper document, but maybe it doesn't.

In core_cm3.h you can see various mask definitions and translations from IRQ number to register bits, fro example:

/**
* @brief Enable Interrupt in NVIC Interrupt Controller
*
* @param IRQn The positive number of the external interrupt to enable
*
* Enable a device specific interupt in the NVIC interrupt controller.
* The interrupt number cannot be a negative value.
*/
static __INLINE void NVIC_EnableIRQ(IRQn_Type IRQn)
{
 NVIC->ISER[((uint32_t)(IRQn) >> 5)] = (1 << ((uint32_t)(IRQn) & 0x1F)); /* enable interrupt */
}

[Vangelis Fortounas]

Posted on July 21, 2017 at 23:20

Hello again Chris..

Finaly i understand 

St  provides this information .

you  may find this information to stm32f103xb.h

this file is made from ST

Is included in

https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-embedded-software/stm32cubef1.html

software pack

I hope this time to realy help you

this file is placed under CMSIIS directory but is made from ST

St is responsible to provide you for every family of MCU an stm32fXXXxx.h with proper definitions about theese interrupt numbers

Regards

[Chris Quayle]

Posted on July 22, 2017 at 01:25

Thanks for the link. Just downloaded that and seems very complete. St seem to have put a shedload of effort into this and far more than any other vendor so far. However much of it we use, there's planty to dig into from a learning pov...

Regards,

Chris

[Chris Quayle]

Posted on July 22, 2017 at 01:00

Many thanks for all the replies. Later this evening I found a github page for the core_cm3.c and core_cm3.h files. Old version of CMSIS, but no matter. The  functions are defined in the header file, so can now see exactly what the translation is. One line of code, in fact. I know all the variants are different, but the nvic access method looks generic to all, with the interrupt number being the key. Perhaps update the docs in future to include this ?, as the algorithm is not obvious without seeing example code. Constant feedback and improvement etc :-).

You may ask why we are writing our own hal layer. We are currently evaluating various arm processors for future projects and the ST M3 series looks ideal. The only way to really understand the device is to write the hal layer.  Also, to find limitations and / or gotchas, this being the only example so far. The investment in time is more than worth the effort over a set of projects and provides a completely transparent audit trail for code from the top right down to bare metal. Something that's important for many clients, as well as being the due diligence part of the work . Old school here, but bare metal programming since 6502, 68000 and later...

Regards,

Chris