Add new board based on STM32H725AE

[JohnK1987]

Hello and happy new year,

I am trying add a STM32H725AE based board called Wio Lite AI from Seed Studio.

• Schematic
• Reference (Here I took the clock settings, and I also tried that by my own, but still nothing)

I am facing an issue and i don't know what i should do.

Directly after start I received MbedOS crash

++ MbedOS Error Info ++
Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Location: 0x8000E91
Error Value: 0x0
Current Thread: <unnamed> Id: 0x0 Entry: 0x524F3525 StackSize: 0xB4CCB67C StackMem: 0xDB97F33D SP: 0x2404FD8C 
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=WioLiteAI_H725AE
-- MbedOS Error Info --
HAL_RCC_OscConfig ERROR

The error comes from lp_ticker.c. So then I disable LPTICKER in targets.json configuration, but then the board stucked directly after start of program.

int main()
{
    debug_if(DEBUG, "Test\n");
    while (true) {
        //debug_if(DEBUG, "loop\n");
        led1 = !led1;
        thread_sleep_for(1000); // does not matter if the sleep is here or not ,the behavior is same
    }
}

Output in console is just first char T, the led switch to ON and then do nothing more, no errors, just stay.

Targets.json content for this board

    "WIOLITEAI_H725AE": {
        "inherits": [
            "MCU_STM32H725xE"
        ],
        "config": {
            "hse_value": {
                "help": "HSE default value is 25MHz in HAL",
                "value": "25000000",
                "macro_name": "HSE_VALUE"
            }
        },
        "device_has_remove": [
            "LPTICKER"
        ],
        "overrides": {
            "system_power_supply": "PWR_DIRECT_SMPS_SUPPLY"
        },
        "device_name": "STM32H725AEIx"
    },

I also tried just simple blinky with same clock settings in STM32CubeIDE and seems to be OK.

In next few days I will try to debug it, but I would like to know If i miss something.
@JojoS62 @multiplemonomials some hints?

Thank you
BR, Jan

[multiplemonomials]

If I were you, I might try to step through the STM32 HAL code and see why the lpticker OscConfig call is failing. It might help you find what's different about this board vs others that Mbed supports.

[JohnK1987]

Good news! After some pause with Blackpill, I went back to this one and I finally found a rootcause of behavior descripted above.

In the past I tried debugging the unexpected behavior and I found the ST-Link V2.1 stucked in function what was responsible for Dcache enable. After short test, where I commented out this method, the wrong behavior was gone.
However it seems it was just a luck because I was wrong :) I bought STLINK-V3MINIE, which is more pleasant to work with, and I found the code stucks much later.
The issue is wrong SRAM memory settings in cmsis_nvic.h.

#if !defined(MBED_RAM_START)
#define MBED_RAM_START  0x24000000
#endif

#if !defined(MBED_RAM_SIZE)
// 0x38000000 - 0x38003FFF 16K SRAM4
// 0x30004000 - 0x30007FFF 16K SRAM2
// 0x30000000 - 0x30003FFF 16K SRAM1
// 0x24000000 - 0x2404FFFF 320K AXI SRAM
// 0x20000000 - 0x2001FFFF 128K DTCM
#define MBED_RAM_SIZE  0x50000  // 320 KB
#endif

I do not understand all context, but I found on other targets (H723, H743) the DTCM is used like standard RAM and the AXI is used like RAM1. So I set it also like that and tadááá, the issue is gone!

// 0x38000000 - 0x38003FFF 16K SRAM4
// 0x30004000 - 0x30007FFF 16K SRAM2
// 0x30000000 - 0x30003FFF 16K SRAM1
// 0x24000000 - 0x2404FFFF 320K AXI SRAM
// 0x20000000 - 0x2001FFFF 128K DTCM

#if !defined(MBED_RAM_START)
#define MBED_RAM_START  0x20000000
#endif

#if !defined(MBED_RAM_SIZE)
#define MBED_RAM_SIZE  0x20000  // 128 KB
#endif

#if !defined(MBED_RAM1_START)
#define MBED_RAM1_START  0x24000000
#endif

#if !defined(MBED_RAM1_SIZE)
#define MBED_RAM1_SIZE  0x50000  // 320 KB
#endif

Failed Greentee tests remain same for now.

BR, Jan

[JojoS62]

Ram/Rom sizes should be checked in the datasheet when in doubt. My recent problem was also a wrong Ram setting. These are imported from Keil pack manager, the large index.json that was in mbed-os in tools. This file is not bug free, as you can see in my PR in mbed-os for this issue.
DCache and DMA is also difficult and very different between the MCUs. DMA is not supported in some RAM regions, and this can be only solved by modifying the linker script and adding sections to the code. That is why the custom linker script option was very important in my opinion. There is also the MPU involved for turning of Cache on/off only for some regions instead of disabling all.
But here I see also missing OS support, the MPU entries should be handled by OS functions. E.g., the Ethernet code disables the complete DCache when Ethernet is used (on H7).
A clean solution takes time to develop and to test, especially when you want to support more than only STM32 targets.

[JohnK1987]

Yeah @JojoS62, I check the datasheet before of course, but I do not understand these things around linker script/memory mapping.

DCache and DMA is also difficult and very different between the MCUs. DMA is not supported in some RAM regions, and this can be only solved by modifying the linker script and adding sections to the code.

That seems be the information what I needed in January :) For now I solve that with settings (linker script/memory mapping) from STM32H723, but I am not sure if this is 100% correct.

Another good news is the LSE is up. It was lse_drive_load_level settings how was expected, but I did not know I need to do complete power down between change of this setting.
During testing with STM32CubeIDE I just did a change of this and upload to the board, reset, test. When it was not working, then changed it to another one and so on. Yesterday I found I need to unplug USB cable between these actions... sad.

However, the Greentea test mbed-hal-sleep-manager still failing with assertion - lp ticker sleep time incorrect

BR, Jan

[multiplemonomials]

I did not know I need to do complete power down between change of this setting.

Waaaat? Dang that might explain a similar issue I ran into in the past, and ended up giving up on.

[JohnK1987]

Yeah, it is annoying.

In the context of issues on this board I found this

• the issue with mbed-hal-sleep-manager is not target specific, but STM32H7 family specific - Greentea - mbed-hal-sleep-manager test is failing on STM32H7 #131
• the issue with mbed-usb-device-basic is related to STM32 in general - STMicro devices do not pass USB endpoint halt test #53

So it seems I can ignore these issues, for now and make a PR - #133

BR, Jan