[STM32U5x5]: Last bytes are not written (flashed) when len(<binary>)%16 <= 8 #1303

victor-dryad · 2023-04-15T08:23:38Z

Actually, a blind workaround for the issue is simple:

if len(<binary>)%16 <= 8
   then pad 8 bytes to the end of the binary

Programmer/board type: [STLINK/V3]
Operating system an version: [Linux]
stlink tools version and/or git commit hash: [1.7.0-261-g1745bf5-dirty]
stlink commandline tool name: [st-flash]
Target chip (and board, if applicable): [chip ID 482]

Full --debug printout is about 35Mb, if it is needed - just tell me the best way to share them (failed and successful ones)

$ sudo st-flash --debug --reset --freq=1000k --flash=0x200000 --serial 003000215553500920393256 write BG_BOOT_APP_combine.bin 0x8000000
st-flash 1.7.0-261-g1745bf5-dirty
2023-04-14T16:36:49 DEBUG common.c: *** looking up stlink version ***
2023-04-14T16:36:49 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2023-04-14T16:36:49 DEBUG common.c: stlink pid     = 0x374f
2023-04-14T16:36:49 DEBUG common.c: stlink version = 0x3
2023-04-14T16:36:49 DEBUG common.c: jtag version   = 0xc
2023-04-14T16:36:49 DEBUG common.c: swim version   = 0x1
2023-04-14T16:36:49 DEBUG common.c: stlink current mode: mass
2023-04-14T16:36:49 DEBUG usb.c: JTAG/SWD freq set to 1000
2023-04-14T16:36:49 DEBUG common.c: stlink current mode: mass
2023-04-14T16:36:49 DEBUG common.c: *** stlink_enter_swd_mode ***
2023-04-14T16:36:49 DEBUG common.c: Loading device parameters....
2023-04-14T16:36:49 DEBUG common.c: *** stlink_core_id ***
2023-04-14T16:36:49 DEBUG common.c: core_id = 0x0be12477
2023-04-14T16:36:49 DEBUG read_write.c: *** stlink_read_debug32 0x410fd214 at 0xe000ed00
2023-04-14T16:36:49 DEBUG read_write.c: *** stlink_read_debug32 0x20016482 at 0xe0044000
2023-04-14T16:36:49 DEBUG chipid.c: detected chip_id parameters

2023-04-14T16:36:49 DEBUG chipid.c: # Device Type: STM32U5x5
2023-04-14T16:36:49 DEBUG chipid.c: # Reference Manual: RM0456
2023-04-14T16:36:49 DEBUG chipid.c: #
2023-04-14T16:36:49 DEBUG chipid.c: chip_id 0x482
2023-04-14T16:36:49 DEBUG chipid.c: flash_type 10
2023-04-14T16:36:49 DEBUG chipid.c: flash_size_reg 0xbfa07a0
2023-04-14T16:36:49 DEBUG chipid.c: flash_pagesize 0x2000
2023-04-14T16:36:49 DEBUG chipid.c: sram_size 0xc4800
2023-04-14T16:36:49 DEBUG chipid.c: bootrom_base 0xbf90000
2023-04-14T16:36:49 DEBUG chipid.c: bootrom_size 0x10000
2023-04-14T16:36:49 DEBUG chipid.c: option_base 0x0
2023-04-14T16:36:49 DEBUG chipid.c: option_size 0x0
2023-04-14T16:36:49 DEBUG chipid.c: flags 0

Binary to flash:

file BG_BOOT_APP_combine.bin md5 checksum: bead0c587f679d90a363624eb7f620, stlink checksum: 0x05554e18
2023-04-14T16:36:49 INFO common_flash.c: Attempting to write 744072 (0xb5a88) bytes to stm32 address: 134217728 (0x8000000)

This error message appears time to time, but seems is not important
2023-04-14T16:36:49 DEBUG usb.c: READDEBUGREG error (0x18)

Last bytes of the binary are flashed, and seems confirmed as successful

2023-04-14T16:38:05 DEBUG read_write.c: *** stlink_write_debug32 0000000000 to 0x080b5a80
2023-04-14T16:38:05 DEBUG read_write.c: *** stlink_read_debug32 0x00020000 at 0x40022020
2023-04-14T16:38:05 DEBUG read_write.c: *** stlink_write_debug32 0x77777777 to 0x080b5a84
2023-04-14T16:38:05 DEBUG read_write.c: *** stlink_read_debug32 0x00020000 at 0x40022020

However during verification these last bytes are not found in the memory.
(This fact also checked and confirmed using official STM flasher)

(I have edited a little the code of debug printout, so do not be surprised)

2023-04-14T16:38:12 DEBUG read_write.c: *** stlink_read_mem32 ***
2023-04-14T16:38:12 DEBUG common.c: data_len = 648 0x288

 a0 27 00 20 a8 27 00 20 a8 27 00 20 b0 27 00 20
 b0 27 00 20 b8 27 00 20 b8 27 00 20 c0 27 00 20
 c0 27 00 20 c8 27 00 20 c8 27 00 20 d0 27 00 20
 d0 27 00 20 d8 27 00 20 d8 27 00 20 e0 27 00 20
 e0 27 00 20 e8 27 00 20 e8 27 00 20 f0 27 00 20
 f0 27 00 20 f8 27 00 20 f8 27 00 20 00 28 00 20
 00 28 00 20 08 28 00 20 08 28 00 20 10 28 00 20
 10 28 00 20 18 28 00 20 18 28 00 20 20 28 00 20
 20 28 00 20 28 28 00 20 28 28 00 20 30 28 00 20
 30 28 00 20 38 28 00 20 38 28 00 20 40 28 00 20
 40 28 00 20 ff ff ff ff 00 00 02 00 27 2d 0b 08
 27 2d 0b 08 88 e9 0a 20 00 00 00 00 01 00 00 00
 00 00 00 00 4a 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 4a 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 ff 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 73 c3 08 08 d1 9c 08 08
 00 00 00 00 8c 21 0b 08 4e f2 09 08 4c 03 09 08
 4c 03 09 08 4c 03 09 08 4c 03 09 08 4c 03 09 08
 4c 03 09 08 4c 03 09 08 4c 03 09 08 4c 03 09 08
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00
 01 00 41 53 43 49 49 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 41 53 43 49 49 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ff ff ff ff ff ff ff ff
2023-04-14T16:38:12 ERROR common_flash.c: Verification of flash failed at offset: 743424 (0xb5800)
2023-04-14T16:38:12 ERROR common_flash.c: cmp_size: 648 (0x288) aligned_size 648 (0x288)

       <the block printed until first difference>
 a0 27 00 20 a8 27 00 20 a8 27 00 20 b0 27 00 20
 b0 27 00 20 b8 27 00 20 b8 27 00 20 c0 27 00 20
 c0 27 00 20 c8 27 00 20 c8 27 00 20 d0 27 00 20
 d0 27 00 20 d8 27 00 20 d8 27 00 20 e0 27 00 20
 e0 27 00 20 e8 27 00 20 e8 27 00 20 f0 27 00 20
 f0 27 00 20 f8 27 00 20 f8 27 00 20 00 28 00 20
 00 28 00 20 08 28 00 20 08 28 00 20 10 28 00 20
 10 28 00 20 18 28 00 20 18 28 00 20 20 28 00 20
 20 28 00 20 28 28 00 20 28 28 00 20 30 28 00 20
 30 28 00 20 38 28 00 20 38 28 00 20 40 28 00 20
 40 28 00 20 ff ff ff ff 00 00 02 00 27 2d 0b 08
 27 2d 0b 08 88 e9 0a 20 00 00 00 00 01 00 00 00
 00 00 00 00 4a 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 4a 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 ff 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 73 c3 08 08 d1 9c 08 08
 00 00 00 00 8c 21 0b 08 4e f2 09 08 4c 03 09 08
 4c 03 09 08 4c 03 09 08 4c 03 09 08 4c 03 09 08
 4c 03 09 08 4c 03 09 08 4c 03 09 08 4c 03 09 08
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00
 01 00 41 53 43 49 49 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 41 53 43 49 49 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 diff at 0x280: read: ff expected: 00

You can see, that last 8 bytes are 8FF instead of 400 and 4*77
FF - these were written during erase step and were not replaced during binary flash.

The text was updated successfully, but these errors were encountered:

Nightwalker-87 · 2023-05-10T23:04:08Z

@victor-dryad I do have this board available for testing. Can you provide your binary somewhere (temporary webspace) for testing on a second instance? You can paste your logs here https://pastebin.com/ (perpetual distribution is not necessary).

victor-dryad · 2023-05-11T07:43:26Z

@victor-dryad I do have this board available for testing. Can you provide your binary somewhere (temporary webspace) for testing on a second instance? You can paste your logs here https://pastebin.com/ (perpetual distribution is not necessary).

https://drive.google.com/file/d/1LFVCN6ZWUORAQ7jgWgm-1zXwkEbeCyxC/view?usp=sharing
Simply add/remove zeros in the end of it. Now it has exactly 8 bytes in the end

Nightwalker-87 · 2023-05-16T21:45:51Z

@victor-dryad: I'm on this topic now, but certainly would need a few days to analyse the observed behaviour.

2023-05-16T23:25:48 DEBUG usb.c: READDEBUGREG error (0x18)
--> Yes, this is not really relevant, I've seen this in debug outputs from some other boards as well. As to the current state of knowledge, it does not imply any error or malfunction on the operation itself.

Here is the current output (shortened) I get:

st-flash --debug --reset --freq=1000k --flash=0x200000 write BG_BOOT_APP_combine.bin 0x8000000

[...]
2023-05-16T23:27:18 DEBUG read_write.c: *** stlink_read_mem32 ***
2023-05-16T23:27:18 DEBUG common.c: data_len = 88 0x58
 ae 32 09 08 ae 32 09 08 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 01 00 41 53 43 49 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 41 53 43 49 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
2023-05-16T23:27:18 ERROR common_flash.c: Verification of flash failed at offset: 761856
2023-05-16T23:27:18 DEBUG read_write.c: *** stlink_read_debug32 0x0800ab55 at 0x08000004
2023-05-16T23:27:18 DEBUG read_write.c: *** stlink_write_reg
2023-05-16T23:27:18 DEBUG common.c: *** stlink_run ***
2023-05-16T23:27:18 DEBUG read_write.c: *** stlink_read_reg
2023-05-16T23:27:18 DEBUG read_write.c:  (16) ***
2023-05-16T23:27:18 DEBUG common.c: data_len = 8 0x8
 80 00 09 08 03 00 00 f9
2023-05-16T23:27:18 DEBUG usb.c: r_idx (16) = 0xf9000003
stlink_fwrite_flash() == -1
2023-05-16T23:27:18 DEBUG common.c: *** stlink_exit_debug_mode ***
2023-05-16T23:27:18 DEBUG read_write.c: *** stlink_write_debug32 0xa05f0000 to 0xe000edf0
2023-05-16T23:27:18 DEBUG common.c: *** stlink_close ***

Nightwalker-87 · 2023-05-16T22:02:06Z

... in common_flash.c (L1343 ff) we find:

/**
 * Verify addr..addr+len is binary identical to base...base+len
 * @param sl stlink context
 * @param address stm device address
 * @param data host side buffer to check against
 * @param length how much
 * @return 0 for success, -ve for failure
 */
int32_t stlink_verify_write_flash(stlink_t *sl, stm32_addr_t address, uint8_t *data, uint32_t length) {
  size_t off;
  size_t cmp_size = (sl->flash_pgsz > 0x1800) ? 0x1800 : sl->flash_pgsz;
  ILOG("Starting verification of write complete\n");

  for (off = 0; off < length; off += cmp_size) {
    size_t aligned_size;

    // adjust last page size
    if ((off + cmp_size) > length) {
      cmp_size = length - off;
    }

    aligned_size = cmp_size;

    if (aligned_size & (4 - 1)) {
      aligned_size = (cmp_size + 4) & ~(4 - 1);
    }

    stlink_read_mem32(sl, address + (uint32_t)off, (uint16_t)aligned_size);

    if (memcmp(sl->q_buf, data + off, cmp_size)) {
      ELOG("Verification of flash failed at offset: %u\n", (uint32_t)off);
      return (-1);
    }
  }

  ILOG("Flash written and verified! jolly good!\n");
  return (0);
}

This appears to be the relevant code snippet.

Nightwalker-87 · 2023-05-20T15:34:53Z

@victor-dryad Would you propose a fix based on your idea and the relevant code part?

victor-dryad · 2023-05-22T09:20:07Z

@victor-dryad Would you propose a fix based on your idea and the relevant code part?

You are the driver. If you see it logical from point of view of the code, why not? I cannot estimate the code because it is full of details I have no knowledge.
For the users it's more important to get the tool running without problems.

Nightwalker-87 · 2023-05-22T18:41:18Z

@victor-dryad My knowledge to the implementation is limited here as well, because I'm not the author of the code, nor have I gained the complete overview of original implementation - to be honest nobody has, as several people contributed with different attempts to implement certain functionalities. I have stepped in as a maintainer and try to resolve bugs and find my way through the source code, just as many others. 😉

victor-dryad · 2023-05-23T07:31:18Z

@victor-dryad My knowledge to the implementation is limited here as well, because I'm not the author of the code, nor have I gained the complete overview of original implementation - to be honest nobody has, as several people contributed with different attempts to implement certain functionalities. I have stepped in as a maintainer and try to resolve bugs and find my way through the source code, just as many others. wink

Ok.
then I'll try to look in during coming (long) weekend

victor-dryad · 2023-05-28T08:23:22Z

I had a look before weekend to be able to play with the h/w.
An opinion:
The corrections have to be placed in flash_loader.c:
The main write loop is from line

    for (off = 0; off < len; off += sizeof(uint32_t)) {
      uint32_t data;
............... (print is skipped)............
      write_uint32((unsigned char *)&data, *(uint32_t *)(base + off));
      stlink_write_debug32(sl, addr + (uint32_t)off, data);
      wait_flash_busy(sl); // wait for 'busy' bit in FLASH_SR to clear
    }

(a purpose of uint32_t data is not clear for me)
Next "if" looks like a workaround for an issue similar to the discussed here one.
I would propose after it to put a piece of code as proposed in the issue report:
if ((flash_type == STM32_FLASH_TYPE_L5_U5) and (len % 16 <= 8)) { ..... write zero two times. (one write operation writes 4 bytes, as I understood) }
I added in "if" STM32_FLASH_TYPE_L5_U5 check because the issue is not confirmed for other flash types in the group.

Nightwalker-87 · 2023-05-28T19:21:48Z

@victor-dryad As I read it uint32_t data needs to be defined to serve write_uint32(...) and stlink_write_debug32(...) within the for-loop. Do the proposed lines (written out state) solve the issue? We should give it a try and then analyse the derived result.

Ant-ON · 2023-05-29T03:28:37Z

@victor-dryad This code has an error related to array dereferencing (the base variable may not be aligned to 4 byte). But it should not affect full data writing, if the code is executed without segmentation errors. The code should simply write "noise" into the last bytes of the word.

I would rewrite line

write_uint32((unsigned char *)&data, *(uint32_t *)(base + off));

to

data = 0;
memcpy(&data, base + off, (len - off) < 4 ? (len - off) : 4);

victor-dryad · 2023-05-31T11:18:57Z

@Nightwalker-87
Because I am quite pure in C, the proposed attempts above where failing with "ERROR common_flash.c: Invalid flash address".
However this works:
common_flash.c stlink_write_flash after first "if":
L1436+


  if ((len % 16 <= 8) & (sl->flash_type == STM32_FLASH_TYPE_L5_U5))
  {
    len += 8;
  }

L1167 change makes the printout shorter:
    fprintf(stdout, "-> Flash page at %#x erased (size: %#x)\r", addr, page_size);

Tested successfully with len%16 = 1..8 (file size 0xba061..0xba068)

One more question comes to my mind:
The issue operates by absolute value - 8.
May it be possible that the value has relation to sizeof(uint32_t)?
If not - just make the changes in code.

Nightwalker-87 · 2023-06-07T21:28:13Z

@victor-dryad Thanks. I'll test this on my Nucleo-U575ZI-Q as well.
I still need to think about your additional comment.

Nightwalker-87 · 2023-06-08T10:47:27Z

@Ant-ON I've included your proposal into my working copy for testing.
Looking at flash_loader.c and common_flash.c from a more general perspective leaves me uncertain, whether there is further potential for refactoring work related to this topic. It would be preferable to have functions and routines that are generalised and applicable to most chipsets in order to avoid individual approaches where possible. I'd also prefer an improved structuring along with further inline documentation. Any ideas?

victor-dryad · 2023-06-08T17:05:56Z

@Ant-ON with further inline documentation. Any ideas?

Minimal improvement:
Put issue number as comment in the code

//issue num start
...
//issue num finish

:-D

Nightwalker-87 · 2023-06-08T18:05:36Z

@victor-dryad As to our common practise this will be listed in CHANGELOG.md and the Release Notes as soon as this issue is finally resolved and verified. Also there will be a reference in the commit which will close this issue.

I know it is a kind of a struggle to gain an overview of the available functions, but I'll try to do my very best to improve and unify the appearance. Thus for the first (even though off topic) I'll make sure that all existing functions are correctly declared in the related header files. Then I'll check the header includes and do the testing with the provided binary, to which I've added a few zeros at the end. Otherwise I can not rule out any strange side effects during compilation. 😕

victor-dryad · 2023-06-09T07:16:51Z

I've just mentioned a topic "inline documentation". Definitely, changelog and release notes are out of this topic.
List of functions and related to it descriptions - it is another story. I am not ready to discuss it. Except of very general (spherical chicken in vacuum) - "any project has to have requirements specification", something similar to " it is better to be healthy, but rich".

Nightwalker-87 · 2023-06-09T09:19:58Z

@victor-dryad You may have a look at the testing branch (may be instable!). It is an approach to start off with the mentioned restructuring issue for the library (stlink-lib). You may test it with your board and give some feedback in the meanwhile. We also need some testing on Windows later on to verify that all common functionality is preserved.

Nightwalker-87 · 2023-06-09T12:46:18Z

With the change from @Ant-ON, we can skip the following:

if ((len % 16 <= 8) & (sl->flash_type == STM32_FLASH_TYPE_L5_U5))
{
len += 8;
}

I have tested the changes successfully with my Nucleo-U575ZI-Q using the testing branch and thus can verify that this solution is working.

st-flash 1.7.0-288-gfc99064-dirty
2023-06-09T14:33:13 INFO common.c: STM32U5x5: 786 KiB SRAM, 62399 KiB flash in at least 8 KiB pages.
Forcing flash size: --flash=0x00200000
file /.../BG_BOOT_APP_combine.bin md5 checksum: b97ea645b48ec8db44b748344490c06b, stlink checksum: 0x056ea4aa
2023-06-09T14:33:13 INFO common_flash.c: Attempting to write 761946 (0xba05a) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8000000 erased (size: 0x2000)
-> Flash page at 0x8002000 erased (size: 0x2000)
[...]
-> Flash page at 0x80b8000 erased (size: 0x2000)
-> Flash page at 0x80ba000 erased (size: 0x2000)
2023-06-09T14:33:14 INFO flash_loader.c: Starting Flash write for WB/G0/G4/L5/U5

1/93 pages written
2/93 pages written
[...]
92/93 pages written
93/93 pages written
2023-06-09T14:34:23 INFO common_flash.c: Starting verification of write complete
2023-06-09T14:34:29 INFO common_flash.c: Flash written and verified! jolly good!
2023-06-09T14:34:29 INFO common.c: Go to Thumb mode

However I'd prefer to have someone checking the other refactoring which has taken place to verify that we do not accidentally introduce any errors. As mentioned before, we should run it on Windows as well.

(Closes #1303)

Nightwalker-87 · 2023-06-12T10:01:20Z

Tested native MinGW building on windows (Windows 10), board detection and basic toolset commands in the meanwhile.
So far everything looks fine and we can merge testing into develop, which will close this issue by automation.

victor-dryad changed the title ~~[Chip ID 482]: Last bytes are not written (flashed) when len(<binary>)%16 <= 8~~ [STM32U5x5]: Last bytes are not written (flashed) when len(<binary>)%16 <= 8 Apr 19, 2023

Nightwalker-87 added os/linux component/st-flash programmer/STLINK/V3 V3SET / V3MODS / V3MINI / V3MINIE / V3E / V3EC target/stm32u5 labels Apr 23, 2023

Nightwalker-87 added this to the v1.8.0 milestone Apr 30, 2023

Nightwalker-87 self-assigned this Apr 30, 2023

Nightwalker-87 added needs/investigation needs/testing labels May 9, 2023

Nightwalker-87 added bug/needs-fix and removed needs/investigation needs/testing labels May 16, 2023

Nightwalker-87 mentioned this issue May 18, 2023

STM32G491: programming flash error, non-erased value. #1310

Closed

Nightwalker-87 added the component/stlink-lib label May 18, 2023

Nightwalker-87 added status/resolved bug/fixed status/resolved-verified and removed bug/needs-fix labels Jun 9, 2023

Nightwalker-87 assigned Ant-ON and victor-dryad Jun 9, 2023

Nightwalker-87 added a commit that referenced this issue Jun 10, 2023

Fixed flash-write/verify error

efc5c37

(Closes #1303)

Nightwalker-87 mentioned this issue Jun 12, 2023

Merge branch testing into develop #1315

Merged

Nightwalker-87 closed this as completed in #1315 Jun 19, 2023

Nightwalker-87 added this to Release v1.8.0 Jan 31, 2024

Nightwalker-87 moved this to Done in Release v1.8.0 Jan 31, 2024

chenrui333 mentioned this issue Feb 1, 2024

stlink 1.8.0 Homebrew/homebrew-core#161497

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[STM32U5x5]: Last bytes are not written (flashed) when len(<binary>)%16 <= 8 #1303

[STM32U5x5]: Last bytes are not written (flashed) when len(<binary>)%16 <= 8 #1303

victor-dryad commented Apr 15, 2023 •

edited

Loading

Nightwalker-87 commented May 10, 2023 •

edited

Loading

victor-dryad commented May 11, 2023

Nightwalker-87 commented May 16, 2023

Nightwalker-87 commented May 16, 2023

Nightwalker-87 commented May 20, 2023

victor-dryad commented May 22, 2023

Nightwalker-87 commented May 22, 2023

victor-dryad commented May 23, 2023

victor-dryad commented May 28, 2023 •

edited

Loading

Nightwalker-87 commented May 28, 2023 •

edited

Loading

Ant-ON commented May 29, 2023

victor-dryad commented May 31, 2023 •

edited

Loading

Nightwalker-87 commented Jun 7, 2023

Nightwalker-87 commented Jun 8, 2023 •

edited

Loading

victor-dryad commented Jun 8, 2023

Nightwalker-87 commented Jun 8, 2023

victor-dryad commented Jun 9, 2023 •

edited

Loading

Nightwalker-87 commented Jun 9, 2023

Nightwalker-87 commented Jun 9, 2023 •

edited

Loading

Nightwalker-87 commented Jun 12, 2023

[STM32U5x5]: Last bytes are not written (flashed) when len(<binary>)%16 <= 8 #1303

[STM32U5x5]: Last bytes are not written (flashed) when len(<binary>)%16 <= 8 #1303

Comments

victor-dryad commented Apr 15, 2023 • edited Loading

Nightwalker-87 commented May 10, 2023 • edited Loading

victor-dryad commented May 11, 2023

Nightwalker-87 commented May 16, 2023

Nightwalker-87 commented May 16, 2023

Nightwalker-87 commented May 20, 2023

victor-dryad commented May 22, 2023

Nightwalker-87 commented May 22, 2023

victor-dryad commented May 23, 2023

victor-dryad commented May 28, 2023 • edited Loading

Nightwalker-87 commented May 28, 2023 • edited Loading

Ant-ON commented May 29, 2023

victor-dryad commented May 31, 2023 • edited Loading

Nightwalker-87 commented Jun 7, 2023

Nightwalker-87 commented Jun 8, 2023 • edited Loading

victor-dryad commented Jun 8, 2023

Nightwalker-87 commented Jun 8, 2023

victor-dryad commented Jun 9, 2023 • edited Loading

Nightwalker-87 commented Jun 9, 2023

Nightwalker-87 commented Jun 9, 2023 • edited Loading

Nightwalker-87 commented Jun 12, 2023

victor-dryad commented Apr 15, 2023 •

edited

Loading

Nightwalker-87 commented May 10, 2023 •

edited

Loading

victor-dryad commented May 28, 2023 •

edited

Loading

Nightwalker-87 commented May 28, 2023 •

edited

Loading

victor-dryad commented May 31, 2023 •

edited

Loading

Nightwalker-87 commented Jun 8, 2023 •

edited

Loading

victor-dryad commented Jun 9, 2023 •

edited

Loading

Nightwalker-87 commented Jun 9, 2023 •

edited

Loading