Stlink: [feature] STM32H7xx support

[saschagrunert]

Hey,

If I check the ST-Link with my STM32H753i-EVAL board the following message occurs:

> st-flash write arm_app.bin 0x8000000
st-flash 1.4.0-14-gfbd55d9
2018-02-20T13:39:55 INFO common.c: Loading device parameters....
2018-02-20T13:39:55 WARN common.c: Invalid flash type, please check device declaration
...

Indeed the chip id is not recognized:

> st-info --chipid
0x0000

I guess the problem here is that in chipid.c contains no H7s at all.

Is there any plan to support these devices with stlink too?

[xor-gate]

It is not supported currently. The chipid reads zero because probably the wrong registery is read which returns zero. If you would like you could try to add it.

[saschagrunert]

Alright is it only the thing in chipid.c which needs to be found out? Or do I have to modify other parts as well?

[johanderson]

I assume we will need to add in a flashloader for h7 https://github.com/texane/stlink/tree/master/flashloaders
I am not sure and hopefully someone can correct me on this if I am wrong. Still looking into exactly what the st-flash dependencies are.

[xor-gate]

We need to find the correct place to readout the chipid, from that point we select the flash loader. There is a small part in assembly which is run in RAM and a part which is run on the PC. It is a deep dive but probably worth the effort. In the meantime you could also use openocd with gdb which has probably already support for H7 chip variants.

[johanderson]

I probably wont have the time to contribute to this, as I was able to get my needs met through openocd. My needs being a command line way to build a binary, flash it to a target STM32H7 using ST-Link and have executable run so I can automatically perform regression testing.

My steps include:
Install AC6 eclipse http://www.openstm32.org/Downloading%2Bthe%2BSystem%2BWorkbench%2Bfor%2BSTM32%2Binstaller
Collect a run launcher configuration using eclipse on the project with all of my run setting that I need.

The run launcher it generated for me is this (Ive striped away the comments because the code format here didnt like them):
source [find interface/stlink.cfg]
set WORKAREASIZE 0x8000
transport select "hla_swd"
set CHIPNAME STM32H743ZITx
set ENABLE_LOW_POWER 1
set STOP_WATCHDOG 1
set CLOCK_FREQ 4000
reset_config srst_only srst_nogate connect_assert_srst
set CONNECT_UNDER_RESET 1
source [find target/stm32h7x.cfg]

Using AC6 Eclipse, I saw the command line execution it was using. I have taken it and put it here for your use:
$AC6_INSTALL/plugins/fr.ac6.mcu.externaltools.openocd.linux64_1.17.0.201801121207/tools/openocd/bin/openocd -f YOUR_LAUNCH_CONFIG.cfg -s YOUR_PROJECT -s $AC6_INSTALL/plugins/fr.ac6.mcu.debug_2.1.4.201801121207/resources/openocd/st_scripts -c "programYOUR_BINARYreset exit"

I probably could have done more research into creating my own openocd config and used openocd on its' own but I figured this worked and didn't want to reinvent the wheel if I didn't need to.

[xor-gate]

Hi @johanderson I understand. OpenOCD has much more contributors and also works almost the same as the texane/stlink tools. Thank you for your response, good luck with your regression testing.

[olofwalker]

@xor-gate I have a H7 board and made some initial discoveries,

        {
            //RM0433 document was used to find these paramaters
            .chip_id = STLINK_CHIPID_STM32_H74XXX,
            .description = "H743xx device",
            .flash_type = STLINK_FLASH_TYPE_F4,
            .flash_size_reg = 0x1FF1E880,      // section 61.2
            .flash_pagesize = 0x800,           // No flash pages
            .sram_size = 0x100000,             // "SRAM" byte size in hex from
            .bootrom_base = 0x1FFF0000,        //! "System memory" starting address from 
            .bootrom_size = 0x1E800            //! @todo "System memory" byte size in hex from 
        },

    STLINK_CHIPID_STM32_H74XXX           = 0x450    /* Found on page 3069 in the RM0433 

However, when compiling and running st-util I get the following, so I guess Im missing something

st-util 1.4.0-20-gaf4d2eb
2018-02-26T09:18:20 INFO common.c: Loading device parameters....
2018-02-26T09:18:20 WARN common.c: Invalid flash type, please check device declaration
2018-02-26T09:18:20 INFO gdb-server.c: Chip ID is 00000000, Core ID is  6ba02477.
2018-02-26T09:18:20 INFO gdb-server.c: Listening at *:4242...

[xor-gate]

Probably the core is not halted or invalid chipid register is read thats why it read 0x00000000.

[olofwalker]

@xor-gate mkay, any tips on where to start looking, something todo with flash_type ?

[xor-gate]

The chipid is read from the DBGMCU_IDC register with DEV_ID[11:0] bits (datasheet RM0433 page 3069) as you mentioned earlier.

The DBGMCU registers are not reset by a system reset, only by a power on reset. They are accessible to the debugger via the APB-D bus at base address 0xE00E1000. They are also accessible by both processor cores at base address 0x5C001000

It seems it doesn't read the correct register for the DEV_ID here: https://github.com/texane/stlink/blob/a2a707e4f75fd8aafce3fa6095dc34206c5bb801/src/common.c#L586-L597. See also this comment https://github.com/texane/stlink/blob/19691485359afef1a256964afcbb8dcf4b733209/include/stlink/chipid.h#L10

This means we need to read reg 0xE00E1000 also.

[iabdalkader]

@xor-gate

This means we need to read reg 0xE00E1000 also.

Hi, this returns zero, however reading the other address (0x5C001000) returns the chip id:

(gdb) call stlink_read_debug32(sl, 0xE00E1008, chip_id)
$16 = 0
(gdb) print *chip_id
$17 = 0
(gdb) call stlink_read_debug32(sl, 0x5C001000, chip_id)
$18 = 0
(gdb) print /x *chip_id
$19 = 0x10036450

[xor-gate]

@iabdalkader could you try this branch https://github.com/texane/stlink/tree/stm32h7xx-improvements. It took me some time to figure out how to programmaticly verify to which core the programmer is talking to and which stm32 variant. Should work now. See https://github.com/texane/stlink/blob/stm32h7xx-improvements/src/common.c#L592-L602.

[iabdalkader]

@xor-gate Hi, I get a warning (treated as error) about uninitialized ret in stlink_core_id. Initializing ret to 0 or -1 will fix. After adding the chip id and params above, it works:

st-util 1.4.0-24-g20ec71a-dirty
2018-03-08T00:26:35 INFO common.c: Loading device parameters....
2018-03-08T00:26:35 INFO common.c: Device connected is: H743xx device, id 0x450
2018-03-08T00:26:35 INFO common.c: SRAM size: 0x100000 bytes (1024 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2018-03-08T00:26:35 INFO gdb-server.c: Chip ID is 00000450, Core ID is  6ba02477.
2018-03-08T00:26:35 INFO gdb-server.c: Listening at *:4242...
2018-03-08T00:26:38 INFO gdb-server.c: Found 8 hw breakpoint registers
2018-03-08T00:26:38 INFO gdb-server.c: GDB connected.
2018-03-08T00:26:41 INFO gdb-server.c: Found 8 hw breakpoint registers

However breakpoints are not working. This is what I ran from the gdb side:

Remote debugging using :4242
brwarning: Overlapping regions in memory map: ignoring
e0x08068f60 in Reset_Handler ()
(gdb) break main
Breakpoint 1 at 0x8062a16
(gdb) monitor reset
(gdb) c
Continuing.

[Staringlizard]

Any updates on this?

[xor-gate]

You are probably better of using OpenOCD as long it is not working yet.

[SL-RU]

How's a progress? What is stopping to add STM32H7 support? Can I help with anything?

[hggq]

My stm32H743 Nucleo board not working this stink
$ st-info --probe

Found 1 stlink programmers

not display info

[xor-gate]

@SL-RU no progress, if people need this to work properly someone must standup to fix it.

[xor-gate]

@hggq your problem is related to issue #716

[SL-RU]

Hello. There is any progress?
I've made some modifications and succeed to load, make breakpoints and other debug. I'll test it some more and will make PR;

[xor-gate]

@SL-RU great!

[zainkamoi]

Hi. Anyone still interesting in this topic?

Have cloned the stm32h7xx-improvements branch and managed to build it. As iabdalkader commented on Mar 7, 2018, there is an issue at line 590 in common.c, where int ret should be initialized to (-1). Easy fix though. But I still get the unknown chip id error when running st-util even though the core-id is correct... Seems like the chipid.c/h updates was not part of the branch

Added this block to chipid.c as given by olofwalker commented on Feb 26, 2018
{
//RM0433 document was used to find these paramaters
.chip_id = STLINK_CHIPID_STM32_H74XXX,
.description = "H743xx device",
.flash_type = STLINK_FLASH_TYPE_F4,
.flash_size_reg = 0x1FF1E880, // section 61.2
.flash_pagesize = 0x800, // No flash pages
.sram_size = 0x100000, // "SRAM" byte size in hex from
.bootrom_base = 0x1FFF0000, //! "System memory" starting address from
.bootrom_size = 0x1E800 //! @todo "System memory" byte size in hex from
},

And to chipid.h

   STLINK_CHIPID_STM32_H74XXX            = 0x450

[xor-gate]

@zainkamoi please provide a pull request if you want, which is the way to go. Thanks!

[SL-RU]

@zainkamoi it wasn't the real problem... Real problem is that you need to write flash uploader in asm and deeply modify everything for stm32h7 because registers and core is absolutely different from F7 and ect... It is a lot of work and requires studying datasheets and other documentation! For now I'm just using gdb server from TrueStudio

[kabirz]

Any updates on this?

[EmBitz]

@SL-RU Hi, I did already a datasheet study and perhaps you could use these files as templates for your modifications:

https://github.com/EmBitz/EBlink/blob/master/scripts/stmicro/stm32h7x.script
https://github.com/EmBitz/EBlink/blob/master/scripts/stmicro/flash/stm32h7_fl.script

I'm working now for almost 10 months on a H7 project with these scripts and have no problems so far.