[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]

@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.