Electronics > Microcontrollers

Porting stm32 to gigadevice mcu: weird c++ hard fault issue [Solved]

(1/2) > >>

seabea:
Hello !

We have application allready in production running on a STM32F469Bit6.
Now we port it to a gigadevice gd32f450zk mcu.

We experience problems with the c++ application code which goes to hard faults at "random" positions on the gd32 mcu.

The hal (hardwareabstraction layer) is running and clock, sdram, ext flash, controller area network, lcd and trace is working

We checked the timing on a analog output with the oscilloscope, checked the pin connections with the miroscope and used two different boards. a hardware error is unlikely.

we have testprograms for doing all sdram and iram checks, allready went back to the slowest timing possible and checked the connections on the (homemade) board -
everything seems ok and c code is running without such problems.
heap is properly mapped, allocate and new operator return valid pointers.
iram is also working of course. some code runs from the extflash but we also checked this with a test application:
no errors detected here and additionally c++ code may still produce hard faults when linked to iram.

malloc and new is all we use in the c++ code where allready the hard faults occur.
(No initialization of external interrupts or peripherals)

the c++ application code goes to a hard fault sporadically at different programm position
that happens during predictable initialization where no asychnronous external events occur, no interrupts are enabled - just allocating and initializing straight forward.

rebuilding the app with a stripped down object oriented model could not reproduce the errors till now.

we're a bit clueless at the moment and we hope it's our fault but we can not figure out what we do wrong...

The hard fault status register states a bus data error but the error only occurs within the c++ application and not if we test the rams with test routines. (see attachment)


--- Quote ---
* IMPRECISERR is set when a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error.
* FORCED is set to indicate a forced HardFault, generated by escalation of a fault with configurable priority that cannot be handled, either because of priority or because it is disabled
--- End quote ---
see https://www.keil.com/dd/vtr/4889/8687.htm



anyone faced such issues with c++ on gigadevice on keil environment?

kind regards + hello to the forum members!

PS: The hardfault code is (see attachment)
The ADDR is always different, like mentioned above.

We're on the latest 2.0.0 device support package
compiler version 1.6.3 also up to date.
still keil 5.18a is a bit out of date.

bson:
It's a data access bus fault, and the return address on the stack refers to the instruction that made the faulting access.  Look at the instruction and see what it's trying to access - the problem is with the target of that access, not the instruction itself.

thm_w:
You know GD32F450ZK is 256K sram. STM32F469BG is 384kB (with CCM), 200MHz vs 180MHz
Probably some major differences in the peripherals as well.

How much porting effort was actually done here? You are using STM32 HAL?

seabea:

--- Quote from: bson on January 17, 2022, 06:38:01 pm ---It's a data access bus fault, and the return address on the stack refers to the instruction that made the faulting access.  Look at the instruction and see what it's trying to access - the problem is with the target of that access, not the instruction itself.

--- End quote ---
Thanks. I know about this process. The problem is that the faulting adress is different each time i run the code.

In one state I saw in the debugger, it is accessing a target in an area where is no memory at all (0xe.....)


--- Quote from: thm_w on January 17, 2022, 10:59:10 pm ---You know GD32F450ZK is 256K sram. STM32F469BG is 384kB (with CCM), 200MHz vs 180MHz
Probably some major differences in the peripherals as well.

How much porting effort was actually done here? You are using STM32 HAL?

--- End quote ---
Yes, i know. It think it was the best match we could get in purchase due to delivery problems.

We use the Stm32Hal for the stm only.

Most effort i did so far was to refacture an abstraction for the hal adapter. For the GD32 we of course use the GD32-Hal-Functions, not the Stm32Hal.

My collegue just stated, that on his tests the programm does not enter the main function unless he removes all c++ code...
It seems the problem is exclusively related to c++ code.

seabea:
Ok, i have a track: The code executed in external flash produces these errors.

the same code executed in irom works.

So i think the flash timing is not properly set for external flash. I will check this tommorow with my collegue..

It seems just strange to me, that this error was not detected by the write/read tests...

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version