STM32H750 support

[jazamatronic]

Hi,

I've managed to get pyocd to talk to a Daisy Seed that's based on an STM32H750 by creating a pyocd_user.py script.
Without it pyocd was garbling the flash with blocks of FFFFFFF on upload.

For starters I'm using an stlink-v3mini (V3J7M2) and pyocd 0.30.0.

Her's my user script:

pyocd_user.py.txt

# For Daisy Seed
def will_connect(board):

    # For STM32H750xB devices: a 128-Kbyte user Flash memory block containing one
    # user sector of 128 Kbytes (4 K Flash words).
    # /data/daisy/cmsis/CMSIS/Flash/STM32H7xx_CM7.FLM
    flash = pyocd.core.memory_map.FlashRegion(
                                        name="flash",
                                        start=0x08000000,
                                        length=0x20000,
                                        blocksize=0x100,
                                        flm="/data/daisy/cmsis/CMSIS/Flash/STM32H7xx_CM7.FLM"
                                        )
    target.memory_map.add_region(flash)

    # Create the DTCMRAM region
    dtcmram = pyocd.core.memory_map.RamRegion(
                                        name="dtcram",
                                        start=0x20000000,
                                        length=0x20000
                                        )

    # Add the SDRAM region to the memory map.
    target.memory_map.add_region(dtcmram)


    # Create the new 64M SDRAM region
    sdram = pyocd.core.memory_map.RamRegion(
                                        name="sdram",
                                        start=0xc0000000,
                                        length=0x4000000
                                        )

    # Add the SDRAM region to the memory map.
    target.memory_map.add_region(sdram)

    # Create QSPIFLASH - took blocksize from libdaisy/src/per/qspi.c
    # TODO: No ALGO for this - can't keep code in it yet 
    qspiflash = pyocd.core.memory_map.FlashRegion(
                                        name="qspiflash",
                                        start=0x90000000,
                                        length=0x800000,
                                        blocksize=0x1000
                                        )

    # Add the SDRAM region to the memory map.
    target.memory_map.add_region(qspiflash)

#
# Don't know if this is 100% needed 
#
# 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 the processor core at base address 0x5C001000.
# Note: the DBGMCU is not a standard CoreSight component. Therefore, it does not appear
# in the system ROM table.
#
# DBGMCU configuration register (DBGMCU_CR)
# Address offset: 0x004
# Reset value: 0x0000 0000
# 
# See also CMSIS/Debug/STM32H742_743_753_750.dbgconf

DBGMCU_CR = 0xE00E1004
DBGMCU_APB3FZ1 = 0xE00E1034
DBGMCU_APB1LFZ1 = 0xE00E103C
DBGMCU_APB2FZ1 = 0xE00E104C
DBGMCU_APB4FZ1 =  0xE00E1054

def did_reset():
    # Set STANDBY, STOP, and SLEEP bits all to 1.
    LOG.info("Setting DBGMCU_CR to 0x7 after reset")
    target.write32(DBGMCU_CR, 0x7)
    target.write32(DBGMCU_APB3FZ1, 0x0)
    target.write32(DBGMCU_APB1LFZ1, 0x0)
    target.write32(DBGMCU_APB2FZ1, 0x0)
    target.write32(DBGMCU_APB4FZ1, 0x0)

Is this the right way to go about this kind of thing?

Flash speed seems kind of slow...
I also can't load from gdb right now:

(gdb) load
Loading section .isr_vector, size 0x298 lma 0x8000000
Load failed

The following warnings are somewhat concerning, but don't seem to stop flash or debug usage:

0001678:INFO:rom_table:APB-AP#2 Class 0x1 ROM table #0 @ 0xe00e0000 (designer=020 part=450)
0001679:WARNING:rom_table:Invalid coresight component, cidr=0x0
0001679:INFO:rom_table:[2]<e00e3000: cidr=0, pidr=0, component invalid>
0001680:WARNING:rom_table:Invalid coresight component, cidr=0x0
0001680:INFO:rom_table:[3]<e00e4000: cidr=0, pidr=0, component invalid>
0001681:INFO:rom_table:[4]<e00e5000:TSGEN class=15 designer=43b part=101>
0001681:ERROR:rom_table:Error attempting to probe CoreSight component referenced by ROM table entry #5: Memory transfer fault (read) @ 0xe00f0fbc-0xe00f1043
Traceback (most recent call last):
  File "/home/jared/.local/lib/python3.8/site-packages/pyocd-0.30.0-py3.8.egg/pyocd/coresight/rom_table.py", line 358, in _read_table

Anything to be worried about?

Cheers

[flit]

Hi there!

The Daisy stuff is really awesome! 🎹 I had seen it before, but this time it's too tempting to resist… There's a "referral" field in the checkout page—would you like me to put you as my referral? (There's no indication of what it gives you, though.)

Are you using the STM32H750 CMSIS-Pack as the basis, then customizing it from there with the user script?

Using a user script as you've done is absolutely a good way to do things. Ideally the CMSIS-Pack would work without workarounds required, at least for internal flash. 😄 Though when you start adding external flash and SDRAM, you inevitably need customization regardless which debug probe you're using.

For the DBGMCU registers, you probably can use did_connect() instead of writing the registers every reset. But it really shouldn't matter.

gdb load failure
Can you provide the pyocd debug log for when the gdb load fails?

Flash speed
Make sure you set the SWD frequency to something higher than the default of 1 MHz: --f 10m, for instance.

By default pyocd scans (reads) the flash before programming to check if pages are changing, so it can only erase and program those that differ. Depending on how you're using it (programming totally different images versus development), how big the firmware image is, how fast the flash is, etc this can actually slow things down. You can disable this with the smart_flash option (-Osmart_flash=0).

Warnings
The Cortex-M7 based STM32 devices have some weird behaviour like the invalid CoreSight component IDs that I think is related to certain clocks not being enabled. I need to look into it more. Sorry I don't have an immediate answer. (And I don't have an H750 yet.)

[jazamatronic]

G'day @flit ,

Thanks for getting back to me with some useful info.

would you like me to put you as my referral?

I'm not sure the referral field does anything, I certainly haven't signed up for anything.

Are you using the STM32H750 CMSIS-Pack as the basis.

Indeed - I tried installing the pack, but that didn't seem to work so I went digging into its contents.
Already I've seen a few differences between ST's reference manual DM00314099.pdf and the details for the device in the pack's pdsc file. Especially regarding bits in the DBGMCU_CR register and the like - maybe that's where the difficulties are coming from in using it the pack as is?

I'm fairly new to pyocd and the stm32 ecosystem in general but am willing to get my hands dirty - where would I dig to see what pyocd is pulling from the CMSIS-Pack as far as memory maps, flash algos and startup sequences are concerned?

Can you provide the pyocd debug log for when the gdb load fails?

Here it is - let me know if this deserves an issue of its own.

pyocd_gdbserver_debug.txt

Concerning Flash speed -
I got a large speed up by changing the blocksize and page_size for the FlashRegion:

                                        blocksize=0x20000,
                                        page_size=0x20,

I also updated the SWD clock to 20MHz, although that didn't seem to help as much.
I'm not sure I read the STM32 Flash docs correctly - but I took those numbers from this statement:

Flash memory programming by 256 bits
128-Kbyte sector erase, bank erase and dual-bank mass erase.

The H750 only has a single 128K sector anyway... Do those settings look reasonable?

For the Coresight errors, let me know if there's anything I can poke at

[flit]

Ok, if we figure out what the referral is for, I can send them an email. My board should hopefully be here by the weekend.

Because of the use of external flash, and the way the Keil STM32 packs are generally built (I'll need to verify for the H750), you'd probably need a user script anyway to set the flash algo.

From a quick look at the gdbserver log, it's running into the notorious "Memory transfer fault (individual memory accesses must not cross memory region boundaries)" error. Using the CMSIS-Pack based target, combined with adding memory regions via the user script, may be causing overlapping regions. You can verify this by running pyocd cmd <your args here> -c "show map" to list the memory map.

The flash block and page size look good. You can probably increase the page size quite a bit, all the way up to the block size. The larger the page size, the fewer times the flash algo has to be executed. The only downside is that sub-sections of a page cannot be programmed. But given the huge block size, that's not much of a problem.

I'll take a closer look at the H750 specs and CMSIS-Pack .pdsc XML. Though I might not be able to get to right away.

Btw, the SDRAM region probably isn't accessible until the SDRAM controller is configured. So you should set is_default=False and is_powered_on_boot=False on it.

[jazamatronic]

G'day flit,

I appreciate your help here!

So I looked at the map, and yes - I'd made another copy of the internal flash region, which was causing problems. However, with the page_size defined by the pack I was getting programming errors. I tried redefining the page size of the existing region:

    internal_flash = target.memory_map.get_first_matching_region(name="FLASH_Bank1")
    internal_flash.page_size = 0x20
    internal_flash.flm = "/data/daisy/cmsis/CMSIS/Flash/STM32H7x_128k.FLM"

but couldn't get that to work, the page size was never getting updated and I was still getting blocks of FFFF causing segfaults in the flash.
In the end I found the one from the pack, used target.memory_map.remove_region to get rid of it and then created my own.
Now it programs using pyocd flash AND I can load from gdb.

I also updated the SDRAM region. I haven't been using the external qspi flash yet so haven't looked into getting an flm for it together. There are routines for writing to the external flash in the daisy libraries, I guess I'd need to pick those apart and create something stand alone so we could flash it from pyocd.

Anyway - I'm sure you'll have the answers once you've got the hardware in your hands.

BTW - there are some forums with useful info for the daisy here
And @stephenhensley is making regular updates to the daisy repos, he knows a thing or two about how the hardware is put together.

Cheers

[flit]

Fyi, shipment of my Daisy was delayed a week or more because of a delay at the case manufacturer… should be here soon, hopefully. 😄

For the QSPI flash algo, the FlashAlgo repo is a framework for building such algos and includes several examples. I can help with this.

Does SDRAM work? I assume you'd need to configure the controller registers in the user script as with other devices.

[jazamatronic]

Thanks - I've begun looking at this.
Started with the CubeMX, thanks for the tip @stephenhensle, and tried to whittle it down.
Then I took the libdaisy stuff and started thining that out too.
I got a little overzealous and I end up in an error handler, so I'll have to start putting things back.

Once I get something stand alone working I'll see if I can force it into the FlashAlgo format.

@flit are you saying a make based gcc_arm flow won't build yet?

[flit]

Yesterday I pushed the changes to FlashAlgo to get make_gcc_arm working. It may have worked with an older version of project-generator? In any case, it works now with the latest progen 0.11. Just make sure to pull the latest changes and run pip install -U --upgrade-strategy=eager -r requirements.txt.

I just created the feature/stm32h750-is25lp064 branch. You can create a pull request against it if you would like some help (of course I won't be able to test until I get my Daisy).

[jazamatronic]

Great, thanks. I'll probably try and clone this to have a look at it on the weekend.
Still have to get a generic libdaisy style QSPI example working, which I haven't managed yet...

[jazamatronic]

Hi - Sorry, it's been a while, my daisy project had been on hiatus.
I did manage to get the libdaisy QSPI example working on my seed and I want to pick up the flash algo development again.
@flit - did you ever get your hands on a Daisy?

Cheers

[flit]

No worries! 😄 And I do have a Daisy, though sadly I haven't had time to even boot it yet…

[flit]

From the debug sequences in the Keil.STM32H7xx_DFP CMSIS-Pack, it looks like the invalid CoreSight components are caused by a trace clock not being enabled (unsurprising).

If you set bit [20] TRACECLKEN (0x00100000) in DBGMCU_CR in your did_reset() hook, it should enable the clock to the global trace components so they read correctly.

[flit]

I think we need to go via AP2

The register address passed to write_ap() is a "full" address, including the AP number in the top 8 bits, the bank, and the register. (SWD transactions only carry 2 bits of address; the other bits, the bank and AP, have to be set in DP registers.) It takes care of all the details.

So writing to AP2 is just a matter of adding 2 at bit offset 24 to the register addresses, e.g. target.dp.write_ap(0x02000000, 0x23000052)

I'm not even sure they're created at that point?

It's true that pyocd's AP objects aren't created at that point, because pyocd hasn't performed AP discovery yet. That's why we're using the low-level AP write methods on the DP (target.dp). (Otherwise we could just do target.ap[2].write32(DBGMCU_CR, 0x00700007).)

next time 'round the probe memory fault errors were gone

Great!

[jazamatronic]

Ok - I must be doing something wrong here. I tried

target.dp.write_ap(0x02000000, 0x00000042) # write CSW register of AP2

but I get:

 0001834:INFO:dap:DP IDR = 0x6ba02477 (v2 rev6)
 Exception while initing board: STLink error (29): Unknown error
 Traceback (most recent call last):
  ...
   File "/data/daisy/pod_test/../DaisyExamples/libdaisy/core/pyocd_user.py", line 94, in set_traceclken
    target.dp.write_ap(0x02000000, 0x00000042) # write CSW register of AP2
  File "/home/jared/.local/lib/python3.8/site-packages/pyocd-0.30.1.dev0+dirty-py3.8.egg/pyocd/coresight/dap.py", line 697, in write_ap
    self.probe.write_ap(addr, data)
  File "/home/jared/.local/lib/python3.8/site-packages/pyocd-0.30.1.dev0+dirty-py3.8.egg/pyocd/probe/stlink_probe.py", line 192, in write_ap
    result = self._link.write_dap_register(apsel, addr & 0xffff, data)
  File "/home/jared/.local/lib/python3.8/site-packages/pyocd-0.30.1.dev0+dirty-py3.8.egg/pyocd/probe/stlink/stlink.py", line 447, in write_dap_register
    self._check_status(response)
  File "/home/jared/.local/lib/python3.8/site-packages/pyocd-0.30.1.dev0+dirty-py3.8.egg/pyocd/probe/stlink/stlink.py", line 305, in _check_status
    raise exceptions.ProbeError(error_message)
pyocd.core.exceptions.ProbeError: STLink error (29): Unknown error

I'm writing 0x00000042 as according to the RM a lot of the fields in the AP_CSW are reserved when accessing the ABP-AP. I tried a bunch of other values as well, but got the same probe error each time.

Cheers

[flit]

It's unlikely you're doing something wrong.

I dug out a STM32H747I-Disco board I have and tested it with the on-board STLinkV3. The H747 is very close to the H750, with the addition of a second M4 core. The script I'm using is shown below.

This works seemingly ok. At least, I don't get any exceptions and there are no invalid CoreSight components listed.

So I'm not sure what the issue could be on your side. That's not the most helpful error from the STLink… Can you check that you've got the latest STLink firmware version installed? I'm using V3J3M2.

Of course, there's a possibility that the H747 is, in fact, not so similar to the H750! Hopefully I'll be able to test directly on the H750 soon.

DBGMCU_CR = 0xE00E1004
APBD = (2 << 24)

def will_init_target(target, init_sequence):
    def set_traceclken():
        LOG.info("setting DBGMCU_CR")
        target.dp.write_ap(APBD | 0x00, 0x23000052) # write CSW register of AP0
        target.dp.write_ap(APBD | 0x04, DBGMCU_CR)  # write TAR register of AP0
        target.dp.write_ap(APBD | 0x0C, 0x007001bf) # write DRW register of AP0 with DBGMCR_CR value

    init_sequence.insert_after('dp_init', ('set_traceclken', set_traceclken))

[jazamatronic]

OK - thanks for your perseverance - it's working now!

I had flashed my stlink-v3mini with the latest firmware - V3J7M2

Digging on ST's site, I couldn't find the exact same version as yours, but I did find V3J4M2 (stsw-link007_V2-34-25 for those playing along at home). Now it works:

0001646:INFO:pyocd_user:Setting DBGMCU_CR(0xE00E1004) to 0x700007 during init via AP Base 0x2000000

No more coresight probe errors, no more memory faults - pyocd starts up clean. Great!

Now - I'm not sure I really needed to do any of that as I'm unsure how to even use all that trace functionality, but with this out of the way I can concentrate on the flash algo stuff.

Cheers

[flit]

Awesome! Glad it's working. 😄