Basic UART Interrupt TX causes system crash STM32F767

[Brandon Braun]

Posted on July 23, 2017 at 03:18

Hey All,

I'm a bit at my wits end here trying to debug a pesky issue I'm having with a very basic interrupt mode UART transmit. The issue is that when I call HAL_UART_Transmit_IT(), it causes the whole chip to lock up. I've spent literally the entire day running through example code from the STM32CubeMX, looking at tutorials online, stepping through annotated assembly code line by line, reading ST application notes, and haven't yet found the root cause. If someone wouldn't mind taking a quick look at what I have it'd be much appreciated. I could really use a fresh set of eyes.

I'm running on a NUCLEO-F767ZI board with the latest ST-Link debugger/programmer firmware.

/* Just assume these GPIO objects work as intended. They have been well vetted in other projects of mine. */

GPIOClass testPin(GPIOA, PIN_15, HIGH_SPD, NO_ALTERNATE);

GPIOClass txPin(GPIOE, PIN_8, ULTRA_SPD, GPIO_AF8_UART7);

GPIOClass rxPin(GPIOE, PIN_7, ULTRA_SPD, GPIO_AF8_UART7);

UART_HandleTypeDef huart7;

char message[] = 'Hello World';

uint8_t data = 0x33;int main(void){        HAL_Init();    testPin.mode(OUTPUT_PP);        /*GPIO Config */    txPin.mode(ALT_PP, PULLUP);    rxPin.mode(ALT_PP, PULLUP);        /*Interrupt Config */    HAL_NVIC_DisableIRQ(UART7_IRQn);    HAL_NVIC_ClearPendingIRQ(UART7_IRQn);    HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_0);    HAL_NVIC_SetPriority(UART7_IRQn, 0, 0);    HAL_NVIC_EnableIRQ(UART7_IRQn);        /*UART Config */    __UART7_CLK_ENABLE();    huart7.Instance = UART7;    huart7.Init.BaudRate = 115200;    huart7.Init.WordLength = UART_WORDLENGTH_8B;    huart7.Init.StopBits = UART_STOPBITS_1;    huart7.Init.Parity = UART_PARITY_NONE;    huart7.Init.Mode = UART_MODE_TX_RX;    huart7.Init.HwFlowCtl = UART_HWCONTROL_NONE;    huart7.Init.OverSampling = UART_OVERSAMPLING_16;    huart7.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;    huart7.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;    if (HAL_UART_Init(&huart7) != HAL_OK)        ASSERT_ERROR_BKPT; // asm('bkpt 255')        /* Calling the interrupt version crashes the whole chip */    //HAL_UART_Transmit_IT(&huart7, &data, 1);    for (;;)    {

         /* Calling the blocking version works just fine */

        HAL_UART_Transmit(&huart7, (uint8_t *)message, strlen(message), HAL_MAX_DELAY);                testPin.toggle();        HAL_Delay(10);    }}

void UART7_IRQHandler(void)

{    HAL_UART_IRQHandler(&huart7);}#stm32f7 #crash #interrupt-issue

[Tesla DeLorean]

Posted on July 23, 2017 at 03:43

You've implemented a UART7_IRQHandler() ?

[Brandon Braun]

Posted on July 23, 2017 at 04:13

Sorry, yes. Updated the code. I just use the basic HAL implementation.

[Brandon Braun · Accepted solution]

Posted on July 23, 2017 at 19:18

SOLUTION:

Turns out that despite having the function declared in my main code, it was necessary to add

extern 'C' void UART7_IRQHandler(); at the top. I've never had to do that previously with other chips, so it didn't occur to me that was the issue.

HOW THE PROBLEM WAS SOLVED:

I'm running on VS2017 Community Edition with VisualGDB. I found a nice forum post on the VisualGDB web page

https://sysprogs.com/w/forums/topic/dealing-with-stm32-default_handler-debug_default_interrupt_handlers/

that described my issue pretty well. I used the ST-Link Utility to figure out what address my program counter was at when it halted and discovered that it pointed to the Default_Handler() interrupt. I then implemented the debugging solution in the linked forum web page and was able to fix my issue. Interrupts work now!