L4S5I-IOT01A - STLink error (20): DP wait

[arekzaluski]

Platform: Linux, macOS, Windows (logs attached are from macOS) Board: B-L4S5I-IOT01A (https://os.mbed.com/platforms/B-L4S5I-IOT01A/) Toolchain: ARMC6 (but I'm pretty sure that issue is also reproducible for GCC_ARM) pyOCD: 0.30.3 (issue exists also on previous versions) Python: 3.7+ (Issue exists also on other Python versions)

Steps to reproduce:

1. Import https://github.com/ARMmbed/mbed-os-example-blinky
2. Build a program. Using Mbed Studio or Mbed CLI (https://github.com/ARMmbed/mbed-cli)
3. Download a CMSIS-Pack (Keil.STM32L4xx_DFP.2.5.0.pack) for the target from: https://developer.arm.com/tools-and-software/embedded/cmsis/cmsis-packs
4. Run pyOCD:

> pyocd gdbserver --pack {path/to/Keil.STM32L4xx_DFP.2.5.0.pack} --erase=chip --target STM32L4S5VITx -O connect_mode=under-reset

5. Run arm-none-eabi-gdb:

> arm-none-eabi-gdb {path/to/binary.elf}
> target remote localhost:3333

GDB logs: gdb.log pyOCD logs: pyocd.log

[arekzaluski]

My investigation showed also that this problem is connected with a program that is currently running on the target:

• Issue is reproducible for the Mbed programs that are using ThisThread::sleep_for().
• Issue is not reproducible for the Mbed program that is using wait_us() from mbed_wait_api.

[jeromecoutant]

Thx @arekzaluski to have reported the issue

* Issue **is** reproducible for the Mbed programs that are using `ThisThread::sleep_for()`.
* Issue **is not** reproducible for the Mbed program that is using `wait_us()` from `mbed_wait_api`.

During sleep_for(), mbed OS is requested MCU to go in deepsleep mode, which is STOP2 mode from ST power mode point of view.

Adding @schstm in copy

[jeromecoutant]

Some copy paste from the MCU Reference Manual:

51.16.1 Debug support for low-power modes
In Stop mode, the bit DBG_STOP must be previously set by the debugger. This will
enable the internal RC oscillator clock to feed FCLK and HCLK in Stop mode.
The DBGMCU_CR register can be written by the debugger under system reset. If the
debugger host does not support these features, it is still possible to write this register by
software.

[flit]

This is the typical low power mode issue. A lot of more recent STM32 devices require the DBGMCU_CR power controls to be set to fully wake up the device prior to performing discovery, otherwise you'll get invalid CoreSight IDs.

[arekzaluski]

Thank you @flit for more information. I see DBGMCU_CR being used in both Mbed OS and in pyOCD. Can you recommend the best place to add it?

[flit]

Well, the quickest way to get it working is by adding a pyocd_user.py user script such as this:

DBGMCU_CR = 0xE0042004

def will_init_target(target, init_sequence):
    def set_traceclken():
         target.dp.write_ap(0x00, 0x23000052) # write CSW register of AP0
         target.dp.write_ap(0x04, DBGMCU_CR) # write TAR register of AP0
         target.dp.write_ap(0x0C, 0x00700007) # write DRW register of AP0 with DBGMCR_CR value

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

A permanent solution would be to add a built-in L4S5 target like the F767. It's a little tricky because the write of DBGMCU_CR must be done before discovery is performed, and therefore before APs have been found and created within pyocd. (Thus the direct use of AP register writes to perform a memory write in the above snippet.)

The best solution will be to implement CMSIS-Pack debug sequence support. The STM32 packs have sequences to configure DBGMCU_CR appropriately.

[arekzaluski]

Thanks @flit. I confirm that the addition of the pyocd_user.py file fixes the debug of L4S5I-IOT01A target in both pyocd and Mbed Studio. I agree however that a more permanent solution needs to be implemented.

[jeromecoutant]

Hi

I agree however that a more permanent solution needs to be implemented.

Permanent and automatic for new MCU to come!

@MarceloSalazar

Thx

[jeromecoutant]

Question: this low power mode issue should be taken into account by pyOCD, not MBED/Keil studio...? Do you agree ?

[flit]

@jeromecoutant Absolutely, it should be handled. I'm currently implementing support for debug sequences from CMSIS packs. This will take advantage of the existing STM32 support that configures the DBGMCU registers. (Though pyocd probably won't support .dbgconf files initially.)

[jeromecoutant]

Any update ?

[flit]

@jeromecoutant I'm continuing development on debug sequence support. Sequences are working, with some minor unsupported features. Right now I'm focusing on integration with the rest of pyocd. It's almost finished. 😄

Sorry that it's taken a while. Just have a lot of other stuff going on concurrently, especially the pyocd.io website recently. The branch is feature/debug_sequences in my fork, if you'd like to follow or try it out.

(Btw, we have a Slack workspace now, in case you're interested.)