stlinkv3 and swim reset

[gabbla]

Hello,

I am trying to read the flash of an STM8L101F2P3 (stm8l101?2 from a stm8flash point-of-view) via stlinkv3 without any success. I built the tool with DEBUG=1 and it always goes into error when it tries to assert the reset pin:

✘130 ➜ ./stm8flash -c stlinkv3 -p "stm8l101?2" -s flash -r /tmp/dummy.hex
Determine FLASH area
     GET_VERSION
STLink: v3, JTAG: v0, SWIM: v0, VID: 8304, PID: 4f37
     GET_CURRENT_MODE
        -> 01 03
     DFU EXIT
     SWIM ENTER
     SWIM READBUFSIZE
        -> 0x1800
     SWIM READ_CAP 01
        -> 00 01 00 30 00 00 00 00
     SWIM ASSERT_RESET
IO error: expected 4 bytes but 2 bytes transferred

also, I need to unplug the stlink before I can try again.

Any help?

Thank you, Gab

[spth]

Could you try commit 197db1bd2b03b956186e564aca0234c76d4771fd? That was the last version with the old ST-Link/V2 driver code (the ST-Link/V2 and STLINK-V3 share most of the driver).

AFAIR, the new ST-Link/V2 driver hasn't seen much testing with STLINK-V3 yet (which is partially my fault - I can't find my STLINK-V3 right now).

[gabbla]

Hello,

I tried 197db1bd2b03b956186e564aca0234c76d4771fd and it worked flawlessly! Should I stick to this commit?

Thank you, Gab

[spth]

For now, I guess yes. In the long term, I hope the ST-Link-V3 compability issue can be fixed in the new driver.

[gabbla]

Ok, thank you. I can do tests if you need, the sole problem is I only have STM8L101F2P3 on hands.

Gab

[stefaandesmet2003]

Hi, sorry to hear my PR caused this trouble. I don't have a stlinkv3 to test, but am happy to help figure this out. It looks like the error occurs on the first call of swim_cmd(), on the status request stage. Would you mind to test by replacing at https://github.com/vdudouyt/stm8flash/blob/master/stlinkv2.c#L248 this line : msg_send(pgm, status_cmd, sizeof(status_cmd)); by : stlink2_cmd(pgm,2,STLINK_SWIM,SWIM_READSTATUS);

and move the stlink2_cmd() function just after stlink2_cmd_internal() to keep the c-compiler happy.

I believe the issue is that commands are supposed to be always 16 bytes, but msg_send is erroneously sending a 2 byte packet here, which seems to work on stlinkv2, but apparently not on stlinkv3.

Thanks! Stefaan

[stefaandesmet2003]

proposed code changes here : https://github.com/stefaandesmet2003/stm8flash/tree/stlinkv3_fix

[gabbla]

Hi Stefaan,

I tried your proposed fix and it worked! I tried -w, -r and -v.

stm8flash_fix_v3 on  stlinkv3_fix [?] 
➜ ./stm8flash -c stlinkv3 -p "stm8l101?2" -w out.hex
Determine FLASH area
STLink: v3, JTAG: v0, SWIM: v0, VID: 8304, PID: 4f37
Due to its file extension (or lack thereof), "out.hex" is considered as INTEL HEX format!
466 bytes at 0x8000... OK
Bytes written: 466

stm8flash_fix_v3 on  stlinkv3_fix [?] 
➜ ./stm8flash -c stlinkv3 -p "stm8l101?2" -r /tmp/mem.hex
Determine FLASH area
STLink: v3, JTAG: v0, SWIM: v0, VID: 8304, PID: 4f37
Due to its file extension (or lack thereof), "/tmp/mem.hex" is considered as INTEL HEX format!
Reading 4096 bytes at 0x8000... OK
Bytes received: 4096

stm8flash_fix_v3 on  stlinkv3_fix [?] 
➜ ./stm8flash -c stlinkv3 -p "stm8l101?2" -v out.hex
Determine FLASH area
STLink: v3, JTAG: v0, SWIM: v0, VID: 8304, PID: 4f37
Due to its file extension (or lack thereof), "out.hex" is considered as INTEL HEX format!
Verifing 4096 bytes at 0x8000... OK
Bytes verified: 466

Thank you! Gab

[stefaandesmet2003]

Good news. Apologies again for the screw up. @spth I make another PR with this change?

[spth]

Thanks for looking into this on such short notice. Yes, please prepare a PR. Then we can do a little bit more testing before merging it.

[spth]

@gabbla: can you confirm that is is now fixed in current master?

[gabbla]

@spth Tomorrow night I'll try and update you.

[gabbla]

@spth Ran the same test as above, it works as expected!

Gab