STM32H7 ITCM testing for improved performance

[robertnoble9]

Posted on July 05, 2018 at 00:44

Hi all,

EDIT:

Intention,

I would like to test if there is any performance gain to be had by running functions tat are called inside interrupts from ITCMRAM rather than flash on an STM32H7 MCU.

I'm working with an STM32H7 nucleo 144 board.  I have some functions I would like to test running from ITCM RAM rather than FLASH but I'm having some issues.  I have managed to set up my linker script to place one of my function in the ITCMRAM memory section, then using linker symbols and memcpy, copy the function from FLASH to the ITCMRAM area at the start if the main function.

I'm using Atollic TrueStudio.

I know the function works, but when I try to run it from ITCMRAM I get a hard fault caused by an attempt to execute and undefined instruction.   Does anyone know what would cause this?  Below is the C and disassembly that is causing the fault.  This occurs with optimisation off and on.  there is something going on with the copy from flash to ram but I don't understand what it could be.

Any help would be great.

Thanks

Rob

C

if (signals->I_term_reset == 1)

Disassembly in ITCM area when running from ITCM

; <UNDEFINED> instruction: 0xb890

Disassembly in FLASH load address area

when running from ITCM

ldrb.w  r5, [r0, &sharp36]   ; 0x24

Disassembly when running normally from FLASH

ldrb.w  r5, [r0, &sharp36]   ; 0x24

EDIT: THIS IS WRONG!

I have found that after the copy, the ITCMRAM code is correct.  Its not until the function stored in ITCMRAM is entered that the data becomes corrupt.

EDIT:

Using a watch point I have found that when the __HAL_UNLOCK macro is used the ITCMRAM address where the error is occurring is being modified.

#stm32h7 #stm32 #itcm

[Tesla DeLorean]

Posted on July 05, 2018 at 19:39

Perhaps, but the implementation also doesn't have any coherency mechanisms between the assorted memories/caches.

[Tesla DeLorean]

Posted on July 05, 2018 at 19:42

The scatter loader is more Keil specific, the GNU/GCC tools do require code in the startup file to manage the data described in the linker script.

[robertnoble9]

Posted on July 06, 2018 at 15:06

So, by setting a watch on the memory address that is being written over, I have found that there a couple of HAL macros that are overwriting it.

The disassembly code that is doing it is:

str r1, [r3, #12]

Where:

r1 = 0x5024b890

r3 = 0x0

So, if I'm reading this correct, it says store the value 0x5024b890 in the memory address 0x0 + 12 = 0xC.

Address 0xC is the address that is triggering the hard fault due to the undefined instruction.

The original value of this address after the function has been loaded into ITCMRAM is 0x5024f890, and when the hard fault is trigger address 0xC contains 0x5024b890.  As per the original post, the disassembly line that the fault occurs on is:

; <UNDEFINED> instruction: 0xb890

To me this all ties up and is the cause of the problem.

What I don't understand is how to fix this.

Thanks again for all the help.

[robertnoble9]

Posted on July 06, 2018 at 15:17

A little more investigation.  If I step through I see that the r3 register has sensible numbers in when reaching this particular instruction and the instruction that it is meant to carry out is executed correctly, ie. r3 does not contain 0x0 and writes to the correct address and the code in ITCMRAM is not corrupted.

Could this be something to do with context changes when entering and exiting interrupts?

[Tesla DeLorean]

Posted on July 06, 2018 at 17:07

>>

Could this be something to do with context changes when entering and exiting interrupts?

Somehow I doubt it.

>>

What I don't understand is how to fix this.

Right now you're working on your own code, in isolation. Try presenting your use case in a way that might garner external interest.

[Abdelhamid GHITH]

Posted on July 07, 2018 at 03:02

Is is a NULL pointer?

__MACRO(&handle);

With handle.Instance=0?