profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/gszy/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

stlink-org/stlink 3095

Open source STM32 MCU programming toolset

jendrusk/osm_report_addr 2

Watcher poprawności edycji adresów w OSM

gszy/raspberry-pi-debian-image-maker 1

Debian + Mainline Linux Kernel + u-boot Bootstrap Script and Tutorial for RPi2/3

gszy/browser-compat-data 0

This repository contains compatibility data for Web technologies as displayed on MDN

gszy/gallery-css 0

CSS only Gallery

gszy/kicad-boardview 0

KiCAD to Boardview exporter reads KiCAD PCB layout files and writes ASCII Boardview files

gszy/lge-kernel-omap4 0

Linux kernel for the LGE P920/Optimus 3D/Thrill 4G

gszy/OpenRailwayMap 0

An OpenStreetMap-based project for creating a map of the world's railway infrastructure.

gszy/OsmAnd-resources 0

Custom defined resources of OsmAnd project

delete branch gszy/OpenRailwayMap

delete branch : locales-pl

delete time in 6 days

Pull request review commentstlink-org/stlink

Improve chipid checks and printouts

 void dump_a_chip (FILE *fp, struct stlink_chipid_params *dev) {     fprintf(fp, "flags %d\n\n", dev->flags); } +static int chipid_params_eq(struct stlink_chipid_params *p1, struct stlink_chipid_params *p2)

Please consider making the function parameters const:

static int chipid_params_eq(const struct stlink_chipid_params *p1, const struct stlink_chipid_params *p2)
andysan

comment created time in 10 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventgszy/stlink

Grzegorz Szymaszek

commit sha e51309f8428c4f1eea3ef1840c4fd5116c64279c

Update chip config files from the library structs In general, the chip config files should be kept in sync with the old library structs. Regenerate the files (using an ad hoc script) from the current library. The file name is generated from the chip description, all non-alphanumeric characters are replaced with underscores. It turns out some files have to have their names changed.

view details

nightwalker-87

commit sha 7c4ad1c14df80a872d2c50a8caead65bce435e16

Merge pull request #1181 from gszy/chip-files Updated chip config files from the library structs

view details

nightwalker-87

commit sha 0489af7d4d40ae32413fb449d064dad49ba227ee

General Project Update - [doc] Updated version requirements - Updated CHANGELOG.md

view details

Oleksiy Slyshyk

commit sha 7c582b75260fc2af16541d6b1c762ecc5817c906

define SSIZE_MAX if not defined

view details

Andreas Sandberg

commit sha 95ccd02207f7ba9b3323726bf16478879d956de1

Add support for V3 devices with no MSD Add support for ST-Link V3 devices without MSD that identify using USB PID 0x3754. This PID has been observed on a Nucleo board where MSD was disabled.

view details

pcnorden

commit sha 6471a60460a4659134cf80d8864a022dc09b8447

Changed broken link to new address of udev rules Changed and checked that it should work with the new link. Also changed the number of files to 4 since there are 4 udev rule files in the directory.

view details

nightwalker-87

commit sha 32a80be93eafd47d5ceff2277b8e054248d1f670

Merge pull request #1183 from slyshykO/msvc-ssize_max Define 'SSIZE_MAX' if not defined

view details

nightwalker-87

commit sha 1c5446a91eff0b893b5d937bf854d040ed75109f

Merge pull request #1185 from andysan/stlink3_nomsd Added support for STLINK-V3 devices with no MSD

view details

nightwalker-87

commit sha deae7975e62dc58f9acfe22c936dec4f30023a2e

Merge pull request #1186 from pcnorden/patch-1 [doc] Corrected file path in tutorial

view details

push time in 10 days

issue commentstlink-org/stlink

[STM32F446]: st-flash --area=option read out.bin

Where did the .flash_size_reg parameter go?

I didn’t copy the flash_size_reg parameter, as I didn’t see it in the existing chip files (before my changes). Here is the relevant part of my script:

fprintf(f, "# Chip-ID file for %s\n#\n", device->description);
fprintf(f, "chip_id 0x%x\n", device->chip_id);
fprintf(f, "description %s\n", device->description);
fprintf(f, "flash_type %d\n", device->flash_type);
fprintf(f, "flash_pagesize 0x%x\n", device->flash_pagesize);
fprintf(f, "sram_size 0x%x\n", device->sram_size);
fprintf(f, "bootrom_base 0x%x\n", device->bootrom_base);
fprintf(f, "bootrom_size 0x%x\n", device->bootrom_size);
fprintf(f, "option_base 0x%x\n", device->option_base);
fprintf(f, "option_size 0x%x\n", device->option_size);

if (device->flags & CHIP_F_HAS_DUAL_BANK)
	strcpy(flags, "dualbank");
if (device->flags & CHIP_F_HAS_SWO_TRACING) {
	if (flags[0] == '\0')
		strcpy(flags, "swo");
	else
		strcat(flags, " swo");
}
if (flags[0] == '\0')
	strcpy(flags, "none");
fprintf(f, "flags %s\n\n", flags);

(/me wonders why GitHub highlights the second strcpy and the strcat in a different colour…)

Can we move the comments into the chip-id files as well? (I think so.)

We can move the comments there, though I’m afraid doing so manually would take less time than writing a script to do so (using some C parser or playing with grep and sed).

ApiumJacob

comment created time in a month

delete branch gszy/stlink

delete branch : chip-files

delete time in a month

pull request commentstlink-org/stlink

Update chip config files from the library structs

@Nightwalker-87, done. I think this commit, if merged, should be followed by a commit that would remove the old library struct completely.

gszy

comment created time in a month

push eventgszy/stlink

nightwalker-87

commit sha c8fc6561fead79ad49c09d82bab864745086792c

Bugfixes - Corrected paths for chip-id files (Closes #1180) - Fixed 32-bit build (Closes #985) (Closes #1175) - Patch for GitHub Actions Workflow (Ubuntu)

view details

Grzegorz Szymaszek

commit sha e51309f8428c4f1eea3ef1840c4fd5116c64279c

Update chip config files from the library structs In general, the chip config files should be kept in sync with the old library structs. Regenerate the files (using an ad hoc script) from the current library. The file name is generated from the chip description, all non-alphanumeric characters are replaced with underscores. It turns out some files have to have their names changed.

view details

push time in a month

push eventgszy/stlink

nightwalker-87

commit sha c8fc6561fead79ad49c09d82bab864745086792c

Bugfixes - Corrected paths for chip-id files (Closes #1180) - Fixed 32-bit build (Closes #985) (Closes #1175) - Patch for GitHub Actions Workflow (Ubuntu)

view details

push time in a month

startedjubalh/gontributions

started time in a month

issue commentstlink-org/stlink

GDB printing wrong disassembly after connecting to server

I haven’t tried remote disassembly yet, the basic functionality—breakpoints, stepping through the code—seemed to just work last time I used it. I second @xor-gate:

Maybe there is something wrong with the GDB remote protocol on the st-util side.

I have zero experience with this protocol, so no suggestions for now. Was anyone able to reproduce this issue?

rimio

comment created time in a month

issue commentstlink-org/stlink

st-flash and other utilities search for chip files in the wrong directory

IMHO, ideally we would have the default chip files installed to $PREFIX/share, but read them from /etc (and/or perhaps $XDG_DATA_HOME) as well. Alternatively, at least provide a command line option to override the chips config directory at runtime. This is probably a separate issue, but something to consider when choosing names like CMAKE_ETC_CHIPS_DIR (note the “ETC”).

slyshykO

comment created time in a month

pull request commentstlink-org/stlink

Update chip config files from the library structs

(Some? All?) CI failures seem unrelated:

E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/m/mesa/libegl-mesa0_21.0.3-0ubuntu0.2~20.04.1_amd64.deb  404  Not Found [IP: 40.119.46.219 80]
gszy

comment created time in a month

PR opened stlink-org/stlink

Update chip config files from the library structs

In general, the chip config files should be kept in sync with the old library structs. Regenerate the files (using an ad hoc script) from the current library.

The file name is generated from the chip description, all non-alphanumeric characters are replaced with underscores. It turns out some files have to have their names changed.

See https://github.com/stlink-org/stlink/issues/1180#issuecomment-903127544 and https://github.com/stlink-org/stlink/issues/1180#issuecomment-903147893.

+182 -117

0 comment

49 changed files

pr created time in a month

create barnchgszy/stlink

branch : chip-files

created branch time in a month

issue commentstlink-org/stlink

st-flash and other utilities search for chip files in the wrong directory

Here, FWIW, is a patch that replaces all configs/chips/* files with ones freshly generated from src/stlink-lib/chipid.c: 0001-Update-chip-config-files-from-the-library-struct.patch.gz.

slyshykO

comment created time in a month

issue commentstlink-org/stlink

[STM32F446]: st-flash --area=option read out.bin

We currently seem to read four bytes starting from 0x1fffc000, because that’s the way STM32F446’s option bytes are defined in the lib:

https://github.com/stlink-org/stlink/blob/db8f789400d0ac19536228b0bd774ac8f1d60ed6/src/stlink-lib/chipid.c#L295-L305

I don’t really think the address is wrong, technically we are in the option bytes memory area; but the bytes we are interested in (RDP, USER, SPRMOD, nWRP) are obviously not included in these first four bytes. The easiest solution seems to set option_size to 16.

ApiumJacob

comment created time in a month

issue commentstlink-org/stlink

[STM32F446]: st-flash --area=option read out.bin

Well, it seems that when the filename is not provided, the program prints the result of stlink_read_option_bytes32():

https://github.com/stlink-org/stlink/blob/db8f789400d0ac19536228b0bd774ac8f1d60ed6/src/st-flash/flash.c#L210-L215

It results in the following calls:

  • stlink_read_option_bytes32()
    • stlink_read_option_bytes_f4()
      • stlink_read_option_control_register_f4()
        • stlink_read_debug32(sl, FLASH_F4_OPTCR, …) (where FLASH_F4_OPTCR = 0x40023c14, which is the actual memory address of the register)
          • sl->backend->read_debug32(sl, FLASH_F4_OPTCR, …)

Based on the STM32F446xx RM, I think 0x8f00bbed looks like a reasonable value.


On the other hand, when the filename is provided, the program calls stlink_fread() instead:

https://github.com/stlink-org/stlink/blob/db8f789400d0ac19536228b0bd774ac8f1d60ed6/src/st-flash/flash.c#L207

It results in the following calls:

  • stlink_fread()
    • stlink_read(sl, 0x1fffc000, 4, …, …) (where 0x1fffc000 is the memory address of the option bytes)
      • stlink_read_mem32(sl, …, …)
        • sl->backend->read_mem32(sl, …, …)

Not digging too deep into these functions, I wonder if we actually want to read four bytes from 0x1fffc000. If I understand the RM correctly (Table 8 and Table 9), there are actually 16 option bytes:

Byte Description
0x1fffc000 reserved
0x1fffc001 reserved
0x1fffc002 reserved
0x1fffc003 reserved
0x1fffc004 reserved
0x1fffc005 reserved
0x1fffc006 RDP
0x1fffc007 USER
0x1fffc008 reserved
0x1fffc009 reserved
0x1fffc00a reserved
0x1fffc00b reserved
0x1fffc00c reserved
0x1fffc00d reserved
0x1fffc00e SPRMOD; reserved
0x1fffc00f nWRP
ApiumJacob

comment created time in a month

push eventgszy/stlink

Oleksiy Slyshyk

commit sha 03153d083c46d33295e5bd905d08c35472a21048

removed redundant array

view details

nightwalker-87

commit sha b43320006162e12b88ef458173a66e00a1608ec0

Merge pull request #1178 from slyshykO/fix-copypaste-issue Removed redundant array

view details

Oleksiy Slyshyk

commit sha bef3321ea45e939003ef7802bdd2d3368f57b676

Fixes few warnings for msvc about type conversion with possible lost data.

view details

Oleksiy Slyshyk

commit sha 698b97bbddd4505c3fa4e0af366484e29b2739e4

fixes printf format formating

view details

nightwalker-87

commit sha c758341d52a604b73296cfc43e4c1f87ff8f5d86

Merge pull request #1179 from slyshykO/fix-few-msvc-warn Fixed few warnings for msvc about type conversion with possible lost data

view details

nightwalker-87

commit sha 607d1d3b854b0dc3fb84455f6efa21dffc578fe4

General Project Update - Updated CHANGELOG.md - Updated list of contributors

view details

nightwalker-87

commit sha db8f789400d0ac19536228b0bd774ac8f1d60ed6

Merge branch 'develop' of https://github.com/stlink-org/stlink into develop

view details

push time in a month

issue commentstlink-org/stlink

Attempting to flash to STM32L052K8 corrupts flash memory

I’m sorry, I don’t have any L0s to test.

WRansohoff

comment created time in a month

push eventgszy/stlink

Oleksiy Slyshyk

commit sha 41d7ca710eace2b52b5e224a9f238be151477004

fix compilation for MSVC

view details

nightwalker-87

commit sha af384e96930f09e5032f79afca03155d86e9759a

Update src/stlink-lib/chipid.c Co-authored-by: Grzegorz Szymaszek <gszymaszek@short.pl>

view details

Oleksiy Slyshyk

commit sha 274be86616801d65cdc0e1f1bf380c98a7aa5b85

Update src/stlink-lib/chipid.c Co-authored-by: Grzegorz Szymaszek <gszymaszek@short.pl>

view details

Oleksiy Slyshyk

commit sha 9ec951c008b84f89debd69929a0aba6d1e4f4a22

uncrustify chipid.c

view details

Oleksiy Slyshyk

commit sha e5152c45c3f9b27116be9d9d07250e6088d85c5a

chipid.c: drop empty lines at end

view details

nightwalker-87

commit sha a6d19d794e5df7c0a68b6d5d1965c21a4a0ff730

Merge pull request #1176 from slyshykO/fix-msvc-build Fixed compilation for MSVC

view details

push time in a month

Pull request review commentstlink-org/stlink

Fixed compilation for MSVC

 void init_chipids(char *dir_to_scan)       dump_a_chip (stderr, op);       fprintf (stderr, "---------- new ------------\n");       dump_a_chip (stderr, p);-      +     }   } #endif }+#endif //STLINK_HAVE_DIRENT_H++#if defined(_WIN32) && !defined(STLINK_HAVE_DIRENT_H)+#include <fileapi.h>+#include <strsafe.h>+void init_chipids(char *dir_to_scan)+{+  HANDLE hFind = INVALID_HANDLE_VALUE;+  WIN32_FIND_DATAA ffd;+  char file_pattern[MAX_PATH] = {0};+  char filepath[MAX_PATH] = {0};+  StringCchCopyA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), dir_to_scan);+  if (FAILED(StringCchCatA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), "\\*.chip"))) {+    ELOG("Path to chips's dir too long.\n");+    return;+  };+  hFind = FindFirstFileA(file_pattern, &ffd);+  if (INVALID_HANDLE_VALUE == hFind){+    ELOG("Can't find any chip description file in %s.\n", file_pattern);+    return;+  }++  do {+      memset(filepath, 0, STLINK_ARRAY_SIZE(filepath));+      StringCchCopyA(filepath, STLINK_ARRAY_SIZE(filepath), dir_to_scan);+      StringCchCatA(filepath, STLINK_ARRAY_SIZE(file_pattern), "\\");+      StringCchCatA(filepath, STLINK_ARRAY_SIZE(file_pattern), ffd.cFileName);+      process_chipfile(filepath);

Yes, but in the current patch version there seem to be 6 spaces. So you should either follow the style of the rest of this file, and use 2+2=4 spaces, or follow that guide, and use 4+4=8 spaces.

slyshykO

comment created time in a month

PullRequestReviewEvent

Pull request review commentstlink-org/stlink

Fixed compilation for MSVC

 void init_chipids(char *dir_to_scan)       dump_a_chip (stderr, op);       fprintf (stderr, "---------- new ------------\n");       dump_a_chip (stderr, p);-      +

I agree, but I don’t like mixing coding style changes with other ones. So, if my suggestion was accepted, this line would not be changed at all.

slyshykO

comment created time in a month

PullRequestReviewEvent

Pull request review commentstlink-org/stlink

Fixed compilation for MSVC

 void init_chipids(char *dir_to_scan)       dump_a_chip (stderr, op);       fprintf (stderr, "---------- new ------------\n");       dump_a_chip (stderr, p);-      +     }   } #endif }+#endif //STLINK_HAVE_DIRENT_H++#if defined(_WIN32) && !defined(STLINK_HAVE_DIRENT_H)+#include <fileapi.h>+#include <strsafe.h>+void init_chipids(char *dir_to_scan)+{+  HANDLE hFind = INVALID_HANDLE_VALUE;+  WIN32_FIND_DATAA ffd;+  char file_pattern[MAX_PATH] = {0};+  char filepath[MAX_PATH] = {0};+  StringCchCopyA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), dir_to_scan);+  if (FAILED(StringCchCatA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), "\\*.chip"))) {+    ELOG("Path to chips's dir too long.\n");+    return;+  };+  hFind = FindFirstFileA(file_pattern, &ffd);+  if (INVALID_HANDLE_VALUE == hFind){

Is this about that (missing?) space before the opening parenthesis? It seems it’s done this way in this file in other ifs and fors.

slyshykO

comment created time in a month

PullRequestReviewEvent

Pull request review commentstlink-org/stlink

Fixed compilation for MSVC

 void init_chipids(char *dir_to_scan)       dump_a_chip (stderr, op);       fprintf (stderr, "---------- new ------------\n");       dump_a_chip (stderr, p);-      +     }   } #endif }+#endif //STLINK_HAVE_DIRENT_H++#if defined(_WIN32) && !defined(STLINK_HAVE_DIRENT_H)+#include <fileapi.h>+#include <strsafe.h>+void init_chipids(char *dir_to_scan)+{+  HANDLE hFind = INVALID_HANDLE_VALUE;+  WIN32_FIND_DATAA ffd;+  char file_pattern[MAX_PATH] = {0};+  char filepath[MAX_PATH] = {0};+  StringCchCopyA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), dir_to_scan);+  if (FAILED(StringCchCatA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), "\\*.chip"))) {+    ELOG("Path to chips's dir too long.\n");+    return;+  };+  hFind = FindFirstFileA(file_pattern, &ffd);+  if (INVALID_HANDLE_VALUE == hFind){+    ELOG("Can't find any chip description file in %s.\n", file_pattern);+    return;+  }++  do {+      memset(filepath, 0, STLINK_ARRAY_SIZE(filepath));+      StringCchCopyA(filepath, STLINK_ARRAY_SIZE(filepath), dir_to_scan);+      StringCchCatA(filepath, STLINK_ARRAY_SIZE(file_pattern), "\\");+      StringCchCatA(filepath, STLINK_ARRAY_SIZE(file_pattern), ffd.cFileName);+      process_chipfile(filepath);+  } while(FindNextFileA(hFind, &ffd) != 0);
  } while (FindNextFileA(hFind, &ffd) != 0);
slyshykO

comment created time in a month

Pull request review commentstlink-org/stlink

Fixed compilation for MSVC

 void init_chipids(char *dir_to_scan)       dump_a_chip (stderr, op);       fprintf (stderr, "---------- new ------------\n");       dump_a_chip (stderr, p);-      +     }   } #endif }+#endif //STLINK_HAVE_DIRENT_H++#if defined(_WIN32) && !defined(STLINK_HAVE_DIRENT_H)+#include <fileapi.h>+#include <strsafe.h>+void init_chipids(char *dir_to_scan)+{+  HANDLE hFind = INVALID_HANDLE_VALUE;+  WIN32_FIND_DATAA ffd;+  char file_pattern[MAX_PATH] = {0};+  char filepath[MAX_PATH] = {0};+  StringCchCopyA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), dir_to_scan);+  if (FAILED(StringCchCatA(file_pattern, STLINK_ARRAY_SIZE(file_pattern), "\\*.chip"))) {+    ELOG("Path to chips's dir too long.\n");+    return;+  };+  hFind = FindFirstFileA(file_pattern, &ffd);+  if (INVALID_HANDLE_VALUE == hFind){
  if (INVALID_HANDLE_VALUE == hFind) {
slyshykO

comment created time in a month