EmWi 8.20 and ARM Compiler 6

Question

Hello,

Our STM32 GUI application is in a stage of integration with middleware and business logic. We are using Keil MDK5 and have recently switched from ARM Compiler version 5 to version 6, mainly due to its vastly increased compile performance. We are well aware that this is a major upgrade that changes, among others, a number of compiler-specific language extensions.

We have found that the "tlsf" memory manager included with EmWi 8.20 fails to compile under ARM compiler 6, due to different implementation of __clz instruction.

Has EmWi and its components been found to be compatible to ARM Compiler version 6 in general? Is the issue described a minor problem that can be overcome by tweaking tlsf to include ARM version 5 compatibility headers, or is it a sign of using the software in a context it has not been tested for?

Thanks!

Answer 1

Hello,

here we have to separate between Embedded Wizard source code (either generated code or licensed source code of Graphics Engine and Runtime Environment) and any other code that is provided as example or template to get started with a dedicated hardware.

The TLSF memory manager is provided as third party source code "as is" and this package is not part of Embedded Wizard Studio or a licensed Platform Package. This memory manager makes it easy to provide a good memory manager even on a bare metal system. You can use it, modify it or replace it by another memory manager (e.g from your operating system). For more details, please have a look into the license terms and the headers of the software packages.

The provided Build Environments are tested by using the toolchains and version that you will find within the ReadMe.txt file in the root folder of the Build Environment.

Comments

Hello Manfred,

Thanks for pointing out the difference between EmWi and third-party modules, this is understood. There is nothing to be criticized about that, so the discussion below is just to better understand what has been tested at EmWi development, and what has to be tested by us.

Given the contents of ReadMe.txt, the only compiler the STM32F769 Run-Time Environment has been tested on is GCC. Strictly speaking, this would actually preclude licensees from using either EWARM or KEIL, right? On the other hand, EmWi does provide project environments for GCC, KEIL, and EWARM. So anybody assumes these have been tested to the same extent as GCC.

All three compilers evolve over time. Some are major releases, like the KEIL/ARM Compiler version 6. Are there any compatibility checks, at least on major releases, run at EmWi development beyond those listed in ReadMe.txt?

Thanks, Steffen Schmid

---

Hello Steffen,

in case of Build Environment for STM32F769-Discovery (Version 9.00), this was tested with the following toolchains:

• GCC ARM Embedded Toolchain 7-2017-q4-major
• IAR C/C++ Compiler for ARM 7.80.4.12462
• MDK-ARM 5.24, ARM Compiler 5.06 update 5 (build 528)

Our tests cover the generated code of different test applications, the source code (+ libraries) of Runtime Environment (RTE) and the source code (+libraries) of Graphics Engine (GE). Other toolchains or compiler versions may be used in the context of customer projects, but they are not used within our release tests.

Best regards,

Manfred Schweyer.

---

Hello Manfred,

Thanks for clarification.

May I suggest that subsequent releases of Embedded Wizard also be tested against MDK-ARM, ARM Compiler version 6 please. Using Compiler version 5 in new projects might be deprecated soon.

If I am correct to suppose that EmWi continues using TLSF version 3.0, you may be interested in knowing there is an update to version 3.1 available.

Best regards,

Steffen Schmid

---

Hello Steffen,

thank you for the feedback. I fuflly agree that using the latest versions of compilers and third-party source codes make sense for upcoming Embedded Wizard releases.

Nevertheless, there is one reason why we used dedicated versions of the toolchains: In case of IAR we choose the same version that is used from ST for testing their STCube firmware. I assume it was the same in case of KEIL.

Anyway, I will discuss internally to update MDK-ARM compiler to version 6 for future releases.

Thanks and best regards,

Manfred Schweyer.

---

Hello Manfred,

May I add some results from my recent tests:

I succeeded to use ARM Compiler version 6 with EmWi 8.20 / STM32F769 environment -- BUT only if optimization is turned off (-O0). Turning on any optimization (for speed, size, balanced or whatsoever) results in a Hard Fault at EmWi root object creation. The vulnerable part is the GeneratedCode. The RTE and anything else tolerates optimization. I don't have any insight into why the GeneratedCode is so vulnerable to optimization by ARM Compiler 6 though. The legacy ARM Compiler 5 can be used along with optimization without the GeneratedCode crashing.

Generating code with no optimization is no option though, as its size grows by more than 50%, and so does size of resources in QSPI flash, negatively affecting runtime performance.

Do you have any idea about why the GeneratedCode is so vulnerable to optimization? Is this something that can be fixed easily, or do we need to refrain from using ARM Compiler 6 until it becomes officially supported by EmWi?

Thanks and best regards,

Steffen Schmid

---

Hello Steffen,

the root cause for the Hard Fault is neither ARM Compiler version 6, nor the generated code of Embedded Wizard and nor the optimization setting.

In the Embedded Wizard BuildEnvironment version 8.20 the MPU settings in ew_bsp_system.c are not sufficient.

In BuildEnvironment version 8.30 we added MPU configuration for QSPI flash and SDRAM according to STM application note AN4861 and AN4838.
This modification solves this issue.

We recommend to update to version 9.00 of Embedded Wizard.

With kind regards,
Martin

---

Hello Martin,

This is an interesting aspect. Could you please be more specific about the changes in ew_bsp_system.c introduced with EmWi version 8.30, providing code snippets if possible?

We will certainly be glad to incorporate the changes in our RTE, but I am afraid we need to continue using 8.20 due to development of this application of ours being nearly complete. We usually don't allow any change to our toolchain in such a late development stage.

Thanks and best regards,

Steffen

---

Hi Steffen,
in Embedded Wizard Build Environment V8.30 we added MPU configuration for QSPI flash and SDRAM in function MPU_Config().
In detail:
 

  /* Configure the MPU attributes for Quad-SPI area to strongly ordered
     This setting is essentially needed to avoid MCU blockings!
     See also STM Application Note AN4861 */
  MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
  MPU_InitStruct.Number           = MPU_REGION_NUMBER2;
  MPU_InitStruct.BaseAddress      = 0x90000000;
  MPU_InitStruct.Size             = MPU_REGION_SIZE_256MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;
  MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_DISABLE;
  MPU_InitStruct.IsShareable      = MPU_ACCESS_SHAREABLE;
  MPU_InitStruct.IsCacheable      = MPU_ACCESS_NOT_CACHEABLE;
  MPU_InitStruct.IsBufferable     = MPU_ACCESS_NOT_BUFFERABLE;
  HAL_MPU_ConfigRegion(&MPU_InitStruct);

  /* Configure the MPU attributes for the QSPI 64MB to normal memory Cacheable, must reflect the real memory size */
  MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
  MPU_InitStruct.Number           = MPU_REGION_NUMBER3;
  MPU_InitStruct.BaseAddress      = 0x90000000;
  MPU_InitStruct.Size             = MPU_REGION_SIZE_64MB; // Set region size according to the QSPI memory size
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_DISABLE;
  MPU_InitStruct.IsShareable      = MPU_ACCESS_SHAREABLE;
  MPU_InitStruct.IsCacheable      = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsBufferable     = MPU_ACCESS_NOT_BUFFERABLE;
  HAL_MPU_ConfigRegion(&MPU_InitStruct);

  /* Configure the MPU attributes for SDRAM_Banks area to strongly ordered
     This setting is essentially needed to avoid MCU blockings!
     See also STM Application Note AN4861 */
  MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
  MPU_InitStruct.Number           = MPU_REGION_NUMBER4;
  MPU_InitStruct.BaseAddress      = 0xC0000000;
  MPU_InitStruct.Size             = MPU_REGION_SIZE_512MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;
  MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_DISABLE;
  MPU_InitStruct.IsShareable      = MPU_ACCESS_SHAREABLE;
  MPU_InitStruct.IsCacheable      = MPU_ACCESS_NOT_CACHEABLE;
  MPU_InitStruct.IsBufferable     = MPU_ACCESS_NOT_BUFFERABLE;
  HAL_MPU_ConfigRegion(&MPU_InitStruct);

  /* Configure the MPU attributes for SDRAM 16MB to normal memory Cacheable */
  MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
  MPU_InitStruct.Number           = MPU_REGION_NUMBER5;
  MPU_InitStruct.BaseAddress      = 0xC0000000;
  MPU_InitStruct.Size             = MPU_REGION_SIZE_16MB;
  MPU_InitStruct.SubRegionDisable = 0x0;
  MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
  MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_ENABLE;
  MPU_InitStruct.IsShareable      = MPU_ACCESS_NOT_SHAREABLE;
  MPU_InitStruct.IsCacheable      = MPU_ACCESS_CACHEABLE;
  MPU_InitStruct.IsBufferable     = MPU_ACCESS_NOT_BUFFERABLE;
  HAL_MPU_ConfigRegion(&MPU_InitStruct); 

Kind Regards,
Martin

---

Hi Martin,

Thanks for providing this code fragment.

First tests shows that this fragment enables using ARM Compiler version 6, with optimization turned on.
Additionally, improved MPU initialization avoids most of the intermittent hangups that we were recently experiencing at high CPU load when using compiler version 5.

Compiler version 6 enables better runtime performance as well, avoiding thoses nasty issues with LTDC data starvation (FIFO underrun) that we had before, avoiding screen update artifacts.

Thanks a lot again -- this fix appears to resolve a bunch of issues altogether.

Best regards,

Steffen