You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[feature] Programmer serial should be displayed when no target is connected #432
When there is currently no target connected the programmer is found but no serial is displayed. This is not handy when we extract the serial number (and OpenOCD hla_serial) when the target is powered on.
I was not aware of that ticket, but yes, this is intended. I've got a couple of fixes for st-flash and gdb server to push to usb probe returning some st-link info with no target connected, i'll tag them with that ticket number.
@grevaillot I don't really know what causes the observed change there then. Maybe it is only a partial fix that leads to the change with this device or only a few others as seen from the code side, but is not a complete fix that addresses all devices by then - no clue on that yet. I'll try my second programmer with this commit as well (before and after). They are both CKS32F103C8T6 devices.
an intermediary commit the probe rework stuff could allow to get some stlink with not target connected to show as "found 1 stlink programmers" with no serial. This was an issue, probe was returning the number of stlink found instead of the number of stlink probed.
in no way 804c38e can change probe behaviour, i would suspect some local not-so-clean rebuild and test issue :)
BTW, i think that --probe call should maybe display cpuid. This one should never be null and would help new chip support / bug report. but that's an other issue.
@grevaillot: You are right it must have been a local not-so-clean rebuild: By now I figured out that my findings derive from the changes introduced by the older manual merge-commit aad5cf1, and thus none of yours. Also refer to #863 which derives from the same branch. So we should stay with what you mentioned before. However this explains the observed behaviour.
Activity
16 remaining items
grevaillot commentedon Apr 19, 2020
I was not aware of that ticket, but yes, this is intended. I've got a couple of fixes for st-flash and gdb server to push to usb probe returning some st-link info with no target connected, i'll tag them with that ticket number.
grevaillot commentedon Apr 19, 2020
hmm, the commit you referenced is not the good one, it was fixed in the probe rework patchset
Nightwalker-87 commentedon Apr 19, 2020
@grevaillot I don't really know what causes the observed change there then. Maybe it is only a partial fix that leads to the change with this device or only a few others as seen from the code side, but is not a complete fix that addresses all devices by then - no clue on that yet. I'll try my second programmer with this commit as well (before and after). They are both CKS32F103C8T6 devices.
Nightwalker-87 commentedon Apr 19, 2020
Here is the output of
st-info --probewith commit 804c38e for the second programmer, which appears to be the same result:while the previous commit 46bf0ab returns:
Still wondering why...
grevaillot commentedon Apr 20, 2020
sorry, got lost in my tree, let's sum up:
an intermediary commit the probe rework stuff could allow to get some stlink with not target connected to show as "found 1 stlink programmers" with no serial. This was an issue, probe was returning the number of stlink found instead of the number of stlink probed.
in no way 804c38e can change probe behaviour, i would suspect some local not-so-clean rebuild and test issue :)
my PR #933 should close that issue.
BTW, i think that --probe call should maybe display cpuid. This one should never be null and would help new chip support / bug report. but that's an other issue.
Nightwalker-87 commentedon Apr 20, 2020
@grevaillot: You are right it must have been a local not-so-clean rebuild: By now I figured out that my findings derive from the changes introduced by the older manual merge-commit aad5cf1, and thus none of yours. Also refer to #863 which derives from the same branch. So we should stay with what you mentioned before. However this explains the observed behaviour.