cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with the interrupt of UART4 of processor STM32F072CBT6

willian2005
Associate II
Posted on November 22, 2015 at 21:54

hello,

I'm having a problem with the UART4 of the processor STM32F072CBT6 when the interrupt of the UART is enabled.

Lets me shot the code:

#include ''stm32f0xx.h''

#include ''stm32f0xx.h''

#include ''stm32f0xx_usart.h''

#include ''stm32f0xx_misc.h''

void initUSART(void);

void sendStringUart(char *data);

void sendCharUart(char data);

volatile char receiverBufferUart[256];

int possitionUart; //possition of next byte of receiveerBuffer

void initUSART(){

USART_InitTypeDef USART_InitStructure;

GPIO_InitTypeDef GPIO_InitStructure;

NVIC_InitTypeDef NVIC_InitStructure;

RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);

RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART4, ENABLE);

GPIO_PinAFConfig(GPIOA, GPIO_PinSource0, GPIO_AF_4);

GPIO_PinAFConfig(GPIOA, GPIO_PinSource1, GPIO_AF_4);

/* Configure USART4 pins: Rx and Tx ----------------------------*/

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;

GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;

GPIO_Init(GPIOA, &GPIO_InitStructure);

/* Enable USART4 IRQ */

NVIC_InitStructure.NVIC_IRQChannel = USART3_4_IRQn;//USART1_IRQn;

NVIC_InitStructure.NVIC_IRQChannelPriority = 0;

NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

NVIC_Init(&NVIC_InitStructure);

USART_InitStructure.USART_BaudRate = 115200;

USART_InitStructure.USART_WordLength = USART_WordLength_8b;

USART_InitStructure.USART_StopBits = USART_StopBits_1;

USART_InitStructure.USART_Parity = USART_Parity_No;

USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;

USART_Init(USART4, &USART_InitStructure);

// Habilita a interrupcao

USART_ITConfig(USART4, USART_IT_RXNE, ENABLE);

USART_Cmd(USART4,ENABLE);

}

void sendCharUart(char data){

while (USART_GetFlagStatus(USART4, USART_FLAG_TXE) == RESET);

USART_SendData(USART4, data);

}

void sendStringUart(char *data){

int i=0;

for(;data[i] !=0 ;i++){

sendCharUart(data[i]);

}

}

void USART3_4_IRQHandler(void)

{

/* RXNE handler */

if(USART_GetITStatus(USART4, USART_IT_RXNE) != RESET)

{

receiverBufferUart[possitionUart] = USART_ReceiveData(USART4);

}

}

int main(void){

initUSART();

sendStringUart(''hello world\n'');

while(1);

return 0;

}

When I execute this code the processor broke in the function HardFault_Handler () at stm32f0xx_it.c:67 - I discovery it using the GDB. However when I comment the line USART_ITConfig(USART4, USART_IT_RXNE, ENABLE); it work very well, but without interrupt.

Anyone was this problem?

Is some bug of the processor? My code is wrong?

Sorry for my bad English.

Thanks

Note: this post was migrated and contained many threaded conversations, some content may be missing.
12 REPLIES 12
Posted on November 22, 2015 at 23:04

Is some bug of the processor?

Probably the least likely cause, guess again.

Do you initialize the index variable?

Is this in a .CPP file?

Where exactly does the processor indicate the faulting instruction is located, and what are the register contents? Assuming you think this is a silicon bug, I hope you've reviewed the TRM to understand what the defined behaviour is, and how this falls outside of that.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
willian2005
Associate II
Posted on November 24, 2015 at 11:36

If it don't is a silicon bug, for me is very happy. I just want solve my problem.

Do you initialize the index variable?

Yes

Is this in a .CPP file?

No, I'm using a .c file.

Follow the state of the register in three moments: in the begin (after the load of program), in a breakpoint initUSART(), and when the processor break.

 in the begin

> reg

===== arm v7m registers

(0) r0 (/32): 0xFFFFFFFF

(1) r1 (/32): 0xFFFFFFFF

(2) r2 (/32): 0xFFFFFFFF

(3) r3 (/32): 0xFFFFFFFF

(4) r4 (/32): 0xFFFFFFFF

(5) r5 (/32): 0xFFFFFFFF

(6) r6 (/32): 0xFFFFFFFF

(7) r7 (/32): 0xFFFFFFFF

(8) r8 (/32): 0xFFFFFFFF

(9) r9 (/32): 0xFFFFFFFF

(10) r10 (/32): 0xFFFFFFFF

(11) r11 (/32): 0xFFFFFFFF

(12) r12 (/32): 0xFFFFFFFF

(13) sp (/32): 0x20004000

(14) lr (/32): 0xFFFFFFFF

(15) pc (/32): 0x08001690 (dirty)

(16) xPSR (/32): 0xC1000000

(17) msp (/32): 0x20004000

(18) psp (/32): 0xFFFFFFFC

(19) primask (/1): 0x00

(20) basepri (/8): 0x00

(21) faultmask (/1): 0x00

(22) control (/2): 0x00

===== Cortex-M DWT registers

(23) dwt_ctrl (/32)

(24) dwt_cyccnt (/32)

(25) dwt_0_comp (/32)

(26) dwt_0_mask (/4)

(27) dwt_0_function (/32)

(28) dwt_1_comp (/32)

(29) dwt_1_mask (/4)

(30) dwt_1_function (/32)

in a breakpoint initUSART()

> reg

===== arm v7m registers

(0) r0 (/32): 0x00000002

(1) r1 (/32): 0x0011000A

(2) r2 (/32): 0x00000008

(3) r3 (/32): 0x40021000

(4) r4 (/32): 0xFFFFFFFF

(5) r5 (/32): 0xFFFFFFFF

(6) r6 (/32): 0xFFFFFFFF

(7) r7 (/32): 0xFFFFFFFF

(8) r8 (/32): 0xFFFFFFFF

(9) r9 (/32): 0xFFFFFFFF

(10) r10 (/32): 0xFFFFFFFF

(11) r11 (/32): 0xFFFFFFFF

(12) r12 (/32): 0xFFFFFFFF

(13) sp (/32): 0x20003FF8

(14) lr (/32): 0x080016DF

(15) pc (/32): 0x08000250

(16) xPSR (/32): 0x61000000

(17) msp (/32): 0x20003FF8

(18) psp (/32): 0xFFFFFFFC

(19) primask (/1): 0x00

(20) basepri (/8): 0x00

(21) faultmask (/1): 0x00

(22) control (/2): 0x00

===== Cortex-M DWT registers

(23) dwt_ctrl (/32)

(24) dwt_cyccnt (/32)

(25) dwt_0_comp (/32)

(26) dwt_0_mask (/4)

(27) dwt_0_function (/32)

(28) dwt_1_comp (/32)

(29) dwt_1_mask (/4)

(30) dwt_1_function (/32)

Bug  processor break

> reg

===== arm v7m registers

(0) r0 (/32): 0x40004C00

(1) r1 (/32): 0x0000006C

(2) r2 (/32): 0x0000002C

(3) r3 (/32): 0x0000007F

(4) r4 (/32): 0x0000006C

(5) r5 (/32): 0xFFFFFFFF

(6) r6 (/32): 0xFFFFFFFF

(7) r7 (/32): 0xFFFFFFFF

(8) r8 (/32): 0xFFFFFFFF

(9) r9 (/32): 0xFFFFFFFF

(10) r10 (/32): 0xFFFFFFFF

(11) r11 (/32): 0xFFFFFFFF

(12) r12 (/32): 0xFFFFFFFF

(13) sp (/32): 0x20003FA8

(14) lr (/32): 0xFFFFFFF1

(15) pc (/32): 0x080000DA

(16) xPSR (/32): 0x01000003

(17) msp (/32): 0x20003FA8

(18) psp (/32): 0xFFFFFFFC

(19) primask (/1): 0x00

(20) basepri (/8): 0x00

(21) faultmask (/1): 0x00

(22) control (/2): 0x00

===== Cortex-M DWT registers

(23) dwt_ctrl (/32)

(24) dwt_cyccnt (/32)

(25) dwt_0_comp (/32)

(26) dwt_0_mask (/4)

(27) dwt_0_function (/32)

(28) dwt_1_comp (/32)

(29) dwt_1_mask (/4)

(30) dwt_1_function (/32)

Thanks for reply
Posted on November 24, 2015 at 13:11

Unfortunately that doesn't provide me with adequate context. Have you looked at coding a Hard Fault Handler to decode the location/nature of the fault. Take a look a Joseph Yiu's examples.

int possitionUart = 0 ; //possition of next byte of receiveerBuffer

You might want to check how the variable starts, and advances, and is kept within the scope of the buffer.

Double check the vector table, and that the IRQHandler links in properly. Review the MAP and Listing files.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Antonio Giovanini
Associate II
Posted on June 07, 2017 at 19:22

Hi,

I know that it is a very old post, but I am facing the same issue. I have a STM32F072, and I am trying to use the USART4 by interruption. I double - checked the interruption vector and it is ok, but when the interruption occurs the PC is jumped to 0x0800BE00, and just after it goes to a hardfault (because I have nothing on this area, it means 0xffffffff, so wrong instruction).

It is very strange as this address (0x0800BE00) is out of linker script region and it is not present in any position of interruption vector.

Does anyone have some idea?

Posted on June 08, 2017 at 00:52

And what is the content of SYSCFG_CFGR1.MEM_MODE  at that moment?

I double - checked the interruption vector

So check it the third time, by actually reading out the content of the vector table, and post it here.

JW

Posted on June 08, 2017 at 01:49

Hi JW,

In this case, 

SYSCFG_CFGR1.MEM_MODE = 00 (Flash), but I also have tried 11 (SRAM), but the result was the same.

Posted on June 08, 2017 at 02:05

Interruption table:

0690X00000607GoQAI.png

and the xpsr register:

0690X00000607GtQAI.png
Posted on June 08, 2017 at 12:15

The interrupt number from xpsr matches the USART4... it's a hummm...

And what happens if you try to trigger the interrupt from USART3?

What exactly is on address 08000324, can you show us (disasm)? Do you have a breakpoint at that address, or only at 0x0800BE00?

JW

Posted on June 08, 2017 at 14:33

As USART3 and USART4 were sharing the same IRQ, the result is the same. BTW, USART1 and USART2 are working properly.

I have my USART3_4_IRQHandler at 0x08000324, and I have a breakpoint on there. See picture below:

0690X00000607HDQAY.png