[feature] Support for STM32L5 / STM32L562E-DK board: read_debug32 returns only 0

[ndusek]

• Programmer/board type: STM32L562E-DK development board
• Programmer firmware version:
  • Board firmware: 1.0.1
  • STLink version: 3
  • JTAG version: 5
• Operating system and version: Linux 5.6.0
• Stlink tools version and/or git commit hash: git hash commit be0157f
• Stlink commandline tool name: test-usb
• Target chip (and board if applicable): STM32L5

We are having an issue reading debug space on this board. read_debug32 won't return anything but 0, regardless of what address is specified.

The board is advertising STLink V3SET device (VID=0x0483:PID=0x374f).

test-usb utility seems to indicate that some basic functionality works.

Core_ID of 0xbe12477 being returned by test-usb utility. ST documentation seems to indicate that chip_id should be 0x477, which seems to be consistent with existing chip_id enumerations.

With st-info --probe test, word one of two word response contains 0x80 or 0x18. Second word is always 0 which defeats the ability for chip probe to determine the chip_id.

ST documentation indicates that L5 board is a feature enhancement of
L4/L4+ boards but architecture/topology is largely the same. Coded up
test chip identification structure based on STLINK_CHIPID_STM32_L46X
definition with debug code added to cause
./src/common:stlink_chip_id() to a chip_id value of 0x477.

ST documentation indicates that chip has dual bank support with
SRAM1=192K and SRAM2=64K. SRAM2 is mapped at 0x0a030000 with second
mapping at 0x20030000 to be contiguous with SRAM1.

Flash size data register read for 0x1fff75e0 returns 0 with first word
of read being 0x18. Additional work would appear to be problematic
without proper functionality of the read_debug32 function.

Would appreciate any suggestions the group may have for further
investigation.

[Nightwalker-87]

This board (L5 series) is not yet supported.

[ndusek]

Thanks for the quick reply. We'll pull down the #999 feature set and see if that solves our problems. Looking forward to getting support for the L5 boards merged.

[Ant-ON]

This board use Stlink-v3, but v3 protocol don't fully (with bugs) implemented. See #820 feature

[Nightwalker-87]

Correct, referring to user feedback, both are currently the main tasks that need to be addressed on the feature-request side.

[Nightwalker-87]

What is the current state here?

[Ant-ON]

There may be a problem with the reset as with STM32H7. If possible, @ndusek you can try this branch https://github.com/Ant-ON/stlink/tree/try_h7_debug

[Nightwalker-87]

There will probably be no further response from the original author due to inactivity.

[tarek-bochkati]

why are you reading this address 0x1fff75e0
IFAICT flash size data register is @ 0x0BFA05E0
and L5 idcode is @ 0xE0044000

I wanted to check further, but reviewing this part src/common.c was a nightmare

maybe I read it wrong and you mean by the ticket to support the secure state ?

[Ant-ON]

@tarek-bochkati I looked carefully at the author's problem. It looks like he tried to add support for L5 based on L4, but didn't fix everything...

[Evidlo]

Not able to get st-flash write working yet.

I produced a simple LED blink .bin with stm32duino that is confirmed working.

This is the console output when stm32duino calls the official programming utility:

sh /home/evan/.arduino15/packages/STMicroelectronics/tools/STM32Tools/2.1.0/stm32CubeProg.sh 0 /tmp/arduino_build_427557/blink.ino.bin -g 
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.10.0                  
      -------------------------------------------------------------------

ST-LINK SN  : 57FF6E067186555527410267
ST-LINK FW  : V2J39S7
Board       : --
Voltage     : 3.23V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x472
Revision ID : Rev Z
Device name : STM32L5xx
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M33
BL Version  : --



Memory Programming ...
Opening and parsing file: blink.ino.bin
  File          : blink.ino.bin
  Size          : 20.09 KB 
  Address       : 0x08000000 


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 10]
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:11.043

RUNNING Program ... 
  Address:      : 0x8000000
Application is running, Please Hold on...
Start operation achieved successfully

And then when I try to program with st-flash:

[evan@blackbox ~] st-flash write /tmp/arduino_build_427557/blink.ino.bin 0x8000000
st-flash 1.7.0-186-gc4762e6-dirty
Failed to parse flash type or unrecognized flash type

detected chip_id parametres

# Device Type: STM32L552
# Reference Manual: RM0438
#
chip_id 0x472
flash_type 10
flash_size_reg 0xbfa05e0
flash_pagesize 0x1000
sram_size 0x40000
bootrom_base 0xbf90000
bootrom_size 0x8000
option_base 0x0
option_size 0x0
flags 0

2022-05-12T12:20:06 INFO common.c: STM32L552: 256 KiB SRAM, 512 KiB flash in at least 4 KiB pages.
file /tmp/arduino_build_427557/blink.ino.bin md5 checksum: 11eea395bf81feee318bcef406d42c, stlink checksum: 0x001e2964
2022-05-12T12:20:06 INFO common_flash.c: Attempting to write 20568 (0x5058) bytes to stm32 address: 134217728 (0x8000000)
2022-05-12T12:20:06 ERROR common_flash.c: method 'is_flash_busy' is unsupported
2022-05-12T12:20:06 ERROR common_flash.c: method 'is_flash_busy' is unsupported
2022-05-12T12:20:06 ERROR common_flash.c: method 'is_flash_busy' is unsupported
2022-05-12T12:20:06 ERROR common_flash.c: method 'is_flash_busy' is unsupported
2022-05-12T12:20:06 ERROR common_flash.c: method 'is_flash_busy' is unsupported
2022-05-12T12:20:06 ERROR common_flash.c: method 'is_flash_busy' is unsupported
...

[Ant-ON]

@Evidlo the STM32_FLASH_TYPE_L5_U5 flash type is not implemented yet. Need to add this flash type (mostly add correct register addresses) to the functions in src/common_flash.c and src/flashloader.c. It is better to take STM32_FLASH_TYPE_G0/STM32_FLASH_TYPE_G4 types as a base. They are close and there is no need to write and compile a native flashloader.

[Evidlo]

@Ant-ON see #1247

[Nightwalker-87]

I'm currently trying to pick up the last known state from #1247, but we would need someone with the respective hardware to test the results in order to get along here.

[Nightwalker-87]

@tarek-bochkati Can you review and/or contribute to this issue?
Am I right in assuming that you may even have (easy) access to the (L5 & U5) board types from your professional background?

[Nightwalker-87]

We need people to test the changes and relevant features.

[Evidlo]

I have hardware for the L552ZEQ, but #1247 being closed from just two weeks of inactivity after spending significant time on that PR was a pretty discouraging experience.

[Nightwalker-87]

@Evidlo ... which is not waisted at all regarding the content of commit b60a035. The point was that the PR was open for a total of 5 months without a result ready to merge. From my understanding this is not the purpose of a PR, but of a personal feature branch for testing instead. The latter should be then put up for a PR once it's scope is at least almost complete (minor tasks). Leaving PRs open for a long time may hinder other development attempts which run in parallel and/or make it necessary to keep track with these. This should not lie in the contributor's range of tasks.

[Nightwalker-87]

Can someone with a L5 board check PR #1300?
Tests on a U5 device have been carried out successfully. 😉

[Ant-ON]

@Nightwalker-87 "read_debug32" is a programmer's call. This does not apply to L5 support. This applies to STLink v3 support. STLink v3 seems to work well and there are no problems with memory reading (U5 as I see it works well). I think this issue has already been resolved.