CPU test bug in the X-CUBE-STL (gcc)

[TK.0]

Hi, this isn't really a question, but I figured I'd share back with the community (and hopefully bring the change back into ST's next release) on the X-CUBE-STL CPU test code.

There are some instances, where the APSR has some bit set in what ARM documents as "reserved" bits. I'm not sure who/what sets them, but occasionally we see some reserved bits set after a firmware update (e.g. DFU).

The result is that the FailSafePOR() hook gets triggered, which in our case performs a NVIC_SystemReset(). After resetting, these reserved bits are cleared and will allow the system to boot properly.

I've added this extra line (with the TLK comment) in the stm32f4xx_STLcpustartGCC.s (v2.1.0) to clear out the bits.

STL_StartUpCPUTest:
    MOVS R0, #0x00000000      /* Set Z(ero) Flag */
    BNE.W FailSafePOR         /* Fails if Z clear */
    SUBS R0,#1                /* Set N(egative) Flag */
    BPL.W FailSafePOR         /* Fails if N clear */
    ADDS R0,#2                /* Set C(arry) Flag and do not set Z */
    BCC.W FailSafePOR         /* Fails if C clear */
    MOVS R0, #0x80000000      /* Prepares Overflow test */
    ADDS R0, R0, R0           /* Set V(overflow) Flag */
    BVC.W FailSafePOR         /* Fails if V clear */
    MOVS R0, #0xFFFFFFFF      /* Prepares Saturation test */
    USAT R1,#10,R0            /* Set Q(saturation) Flag */
    MRS R0, APSR              /* Get Status register */
    AND R0, R0, #0xF8000000   /* <--------- TLK: Hack to remove stuff from reserved bits */
    CMP R0, #0xB8000000       /* Verifies that N=C=V=Q=1 */
    BNE.W FailSafePOR         /* Fails if Q+N+C=V clear */

Tom

[Amel NASRI]

Hello,

Thanks for reporting this issue. We need some more details in order to be able to understand it more, and bring the changes.

So, could you please:

1. precise the reference of the package you are using?
2. is it the X-CUBE-CLASSB (https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-classb.html)?
3. Which example are you running?
4. when exactly the reserved bits are set?
5. which bits in APSR are set?

Thanks,

-Amel

[zwang.12]

How to apply for X-CUBE-STL package？

[RFrie.1]

Hello,

since I'm running in pretty much the same problem I'd like to hook here up.

1. I'm using x-cube-classb version 2.3, however the related code is implemented in most other packages in the same way (stm32g4xx_STLcpustartGCC.s):

    MRS R0, APSR              /* Get Status register */
    CMP R0, #0xB8000000       /* Verifies that N=C=V=Q=1 */

1. _
2. Yes, I'm using the X-CUBE-CLASSB library on a STM32G474 device. The original post refered to X-CUBE-STL package (as the title suggests)
3. The relevant code is part of the startup code provided by the library. At least for STM32G474 devices it runs BEFORE any kind of application code and is also not effected by reset type (POR, watchdog, ...)
4. It seems the return from the Startup_Copy_Handler function effects the reserved bits ('bx lr' instruction):

* @param  None
 * @retval : None
*/
    .section  .text.Copy_Handler
 
  .weak  Startup_Copy_Handler
  .type  Startup_Copy_Handler, %function
Startup_Copy_Handler:
 
/* Copy the data segment initializers from flash to SRAM */  
  movs  r1, #0
  b  LoopCopyDataInit
 
CopyDataInit:
  ldr  r3, =_sidata
  ldr  r3, [r3, r1]
  str  r3, [r0, r1]
  adds  r1, r1, #4
    
LoopCopyDataInit:
  ldr  r0, =_sdata
  ldr  r3, =_edata
  adds  r2, r0, r1
  cmp  r2, r3
  bcc  CopyDataInit
  ldr  r2, =_sbss
  b  LoopFillZerobss
 
/* Zero fill the bss segment. */
FillZerobss:
 
  movs  r3, #0
  str  r3, [r2], #4
  
LoopFillZerobss:
  ldr  r3, = _ebss
  cmp  r2, r3
  bcc  FillZerobss
  bx   lr

Finally, APSR is read as 0xB80F 0000 which is the expected value with Reserved bits APSR[19:16] being set.

In the ARM reference manual (DUI553A_cortex_m4_dgug.pdf, see developer.arm.com/documentation/dui0553/latest/) there is a table 2-4 whre these bits are stated as GE[3:0] ' Greater than or equal flags.