Fixed STM32WB55 reading DEBUG IDCODE from the wrong address

[C-Elegans]

The STM32H7_CORE_ID value in the manual is 0x6b00477, however it was
incorrectly set in stm32.h to 0x6b002477 - see RM0433 page 3065

Fixes #1100

Note: this has not been tested on an STM32H7 core (I don't have one)

[Nightwalker-87]

@C-Elegans: Thx for fixing this, but I can't see the relation to the referenced issue yet. Can you explain?

[C-Elegans]

The STM32WB55 (or at least the chip I have) has an ID code of 0x6ba02477. Previously this caused the chip to be misidentified as an STM32H7 series, causing the DEBUG_IDCODE to be read from the wrong address.

However, looking at the data sheet for the WB55, it also lists an IDCODE of 0x6ba00477. Looks like I need to email ST and see if either datasheet is in error.

[Ant-ON]

The ID is correct. You don't need to fix anything. As I understand it, there is an ID that is read from the JTAG mode (in PR), and another from SWD (in code now).
It is possible to add them as the second and add to the verification code for both.
In its current form, I do not approve PR.

[Ant-ON]

@C-Elegans Tomorrow I will look at reference manual of WB55. Most likely you are right that this needs to be corrected, but not so.

[C-Elegans]

@Ant-ON - So the difference here is that the manual is giving the value for JTAG, but the st-flash tool is reading it through SWD?

[Nightwalker-87]

@C-Elegans ... and what is the relation to issue 1098 which is linked to this PR? There we have a totally different MCU. 😕

[C-Elegans]

@Nightwalker-87 Not sure how that happened, meant to put the issue I opened, #1100. Fixed

[Ant-ON]

@C-Elegans Yes. WB55 and H7 have same ID. For JTAG 0x5BA00477 and for SWD 0x5BA02477. You can see the DP_DPIDR register description. "2" describe the version of the debug port architecture

[Ant-ON]

@C-Elegans I think this can be simplified to

    if (sl->core_id == STM32H7_CORE_ID) {
        // STM32H7 chipid in 0x5c001000 (RM0433 pg3189)
        ret = stlink_read_debug32(sl, 0x5c001000, chip_id);
    }

    if (*chip_id == 0) {
        // default chipid address
        ret = stlink_read_debug32(sl, 0xE0042000, chip_id);
    }

[C-Elegans]

@Ant-ON but reads from 0x5c001000 return 0x1f, not 0. Additionally, 0x5c001000 is in a reserved address space on this chip, so there's no guarantee that it will even always return 0x1f

[Ant-ON]

@C-Elegans We may use the CPUID register additionally.

#define STLINK_REG_CMx_CPUID_CM0 0x410CC200
#define STLINK_REG_CMx_CPUID_CM3 0x412FC230
#define STLINK_REG_CMx_CPUID_CM7 0x411FC272

...

    uint32_t cpu_id;
...

   if (stlink_read_debug32(sl, STLINK_REG_CM3_CPUID, &cpu_id))
      cpu_id = 0;

    if (sl->core_id == STM32H7_CORE_ID && cpu_id == STLINK_REG_CMx_CPUID_CM7) {
        // STM32H7 chipid in 0x5c001000 (RM0433 pg3189)
        ret = stlink_read_debug32(sl, 0x5c001000, chip_id);
    }

    if (*chip_id == 0) {
        // default chipid address
        ret = stlink_read_debug32(sl, 0xE0042000, chip_id);
    }

[C-Elegans]

@Ant-ON The change you described above works for the WB55, I've pushed it to this branch.

[Ant-ON]

I just looked at the addresses of the chip id registers. It turns out a simple and laconical algorithm. But I believe that this should be checked more accurately and do a new PR...

if (sl->core_id == STM32H7_CORE_ID && cpu_id == STLINK_REG_CMx_CPUID_CM7) {
    // STM32H7 chipid in 0x5c001000 (RM0433 pg3189)
    ret = stlink_read_debug32(sl, 0x5c001000, chip_id); 
} else if (cpu_id == STLINK_REG_CMx_CPUID_CM0) {
    // STM32F0/L0/G0
    ret = stlink_read_debug32(sl, 0x40015800, chip_id); 
} else if (cpu_id == STLINK_REG_CMx_CPUID_CM33) { 
    // STM32L5/U5(?)
    ret = stlink_read_debug32(sl, 0xE0044000, chip_id); 
} else /* СM3, СM4, CM7 */ {
    // STM32F1/F2/F3/F4/F7/G4/L4/WBxx
    // default chipid address
    ret = stlink_read_debug32(sl, 0xE0042000, chip_id);

    // Fix chip_id for F4 rev A errata, read CPU ID, as CoreID is the same for F2/F4
    if (*chip_id == 0x411 && (cpu_id & 0xfff0) == 0xc240) {
        *chip_id = 0x413;
    }
}

[Nightwalker-87]

Found the reason for the CI build failure now:
https://travis-ci.community/t/the-default-osx-image-xcode9-4-is-now-unusable-because-macos-10-13-is-eol/10628