Jumping to stored code triggers hardfault interrupt!

[Mrunal A]

Posted on February 23, 2018 at 07:04

Hello,

I have developed a IAP application based on STM32F030CCT6. The application code is received on UART and I can store it in flash, I am storing codeat 0x08010000. But I am facing problems in executing it. While trying to jump at code my code goes into HardFault interrupt. And unfortunately on this MCU there is no implementation of HFSR and VTOR. Hence I am not getting the reason for hardfault! I am using below code for jumping. And I have also remapped the Vector table in application binary. I am using Keil MDK5 and hence I have verified the addresses of code from MAP file. The application code's RESET starts at

0x08010000. and the IAP starts at0x08000000 as expected. Please guide me.

typedef void (*jumpFunction) (void);//typedef for function pointer jumpFunction JumpToFunction;

//Function pointer uint32_t JumpAddress,somaddr;//Address of function pointer

__disable_irq(); JumpAddress = *(__IO uint32_t*)(FLASH_X_START_ADDR + 4);

JumpToFunction = (jumpFunction) JumpAddress; /* Initialize user application's Stack Pointer */

__set_MSP(*(__IO uint32_t*) FLASH_X_START_ADDR); /* Jump to application */

JumpToFunction();

#stm32f0-iap-multi-app Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Mrunal A]

Posted on February 23, 2018 at 07:59

Yes I checked the memory while debugging and its there. The data is matching with the binary I am sending.

[waclawek.jan]

Posted on February 23, 2018 at 08:00

Read out the content of 0x0801'0000..0007 using debugger and post it here.

I am remapping vector table after HAL_Init() and Sysconfig function

Whenever, after you have disabled interrupts in the bootloader and before you enabled them in the application.

What exactly do you mean by 'remapping vector table'? Show.

JW

[Mrunal A]

Posted on February 23, 2018 at 08:04

The data at 

0x0801'0000..0007 is 0x20002D10CD2000

Whenever, after you have disabled interrupts in the bootloader and before you enabled them in the application.

It means I have correctly implemented.

[waclawek.jan]

Posted on February 23, 2018 at 08:14

It means that you haven't correctly created the app binary.

The vector table should be at 0x0801'0000, at 0x0801'0000 you should see an address pointing into RAM, i.e. 0x2000'**** and at 0x0801'0004 you should see an  address pointing into FLASH, i.e. of 0x080*'****.

JW

[Mrunal A]

Posted on February 23, 2018 at 08:28

Thank you for correcting me. But I didn't understood why the binary is not created correctly.

I am using this function:

//This part I copied from the example IAP binary template

#if (defined ( __CC_ARM ))

__IO uint32_t VectorTable[48] __attribute__((at(0x20000000)));

#elif (defined (__ICCARM__))

#pragma location = 0x20000000

__no_init __IO uint32_t VectorTable[48];

#elif defined ( __GNUC__ )

__IO uint32_t VectorTable[48] __attribute__((section('.RAMVectorTable')));

#endif

//This part I copied from the example IAP binary template

void Remap_Table(void)

{

// Copy interrupt vector table to the RAM.

uint32_t ui32_VectorIndex = 0;

for(ui32_VectorIndex = 0; ui32_VectorIndex < 48; ui32_VectorIndex++)

{

VectorTable[ui32_VectorIndex] = *(__IO uint32_t*)((uint32_t)FLASH_X_START_ADDR + (ui32_VectorIndex << 2));

}

__HAL_RCC_AHB_FORCE_RESET();

// Enable SYSCFG peripheral clock

__HAL_RCC_SYSCFG_CLK_ENABLE();

__HAL_RCC_AHB_RELEASE_RESET();

// Remap RAM into 0x0000 0000

__HAL_SYSCFG_REMAPMEMORY_SRAM();

}

I got this code from

http://marcelojo.org/marcelojoeng/2015/09/bootloader-on-stm32f0.html

. And I added it before HAL_Init() but still the binary has no change after building. So is this code correct. The author in the above mentioned blog implemented same MCU as that of mine.

[Mrunal A · Accepted solution]

Posted on February 26, 2018 at 10:39

I got it working! The binary was correct, but I was writing the binary in wrong order, and hence while execution Hardfault interrupt is certain! I found this fault because of

Waclawek.Jan

comment regarding what should be in the flash after writing binary. And I examined the binary and stored flash and found it was different, after some study I found the bug was in writing the binary. I hope this will help some body in future.