Skip to main content
TK.0
Visitor II
September 25, 2018
Question

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

  • September 25, 2018
  • 2 replies
  • 1274 views

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

    This topic has been closed for replies.

    2 replies

    Amel NASRI
    ST Technical Moderator
    October 8, 2018

    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

    To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
    RFrie.1
    Visitor II
    November 17, 2022

    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.

    zwang.12
    Visitor II
    June 9, 2020

    How to apply for X-CUBE-STL package?