Reading the chipid gives nonzero "random" number.

[rewolff]

When starting st-util on my F4 discovery board, I got:

WARN src/stlink-common.c: unknown chip id! 0xe0042000
Chip ID is 00000000, Core ID is 00000000.

which I know spells trouble. But when I see some non-zero numbers for the "chip id" I think I have a connection to the target. Turns out that is not the case: When I switched back to my target I got the same 0xe0042000 chip id, even when the target was not powered.

My STM32F407 on my discovery board might be fried, I don't know yet. I'll just use the F4DISCOVERY as my STLINK for now.

It'd be nice if the "detection" of "no chip connected" was a bit better. Apparently "chip id = 0xe0042000, ... core id = 0" means "no chip"....

[prattmic]

0xe0042000 is actually the address that the chip ID is read from. stlink is reporting that it read 0x0 at that address.

I believe I have received a similar error message before. My board was not fried, but I cannot recall at the moment what the solution was.

[rewolff]

I've investigated some more. The call traces into a "read_debug32" call that apparently returns the requested address "unmodified" in this case. I don't know yet if this is in the STLINK hardware or in the st-util code.
Just to clarify: The fact that SOME non-zero number was showing up convinced me communication was happening: when I program an AVR or (for example) have "no target connected" on an SPI bus, I always get data completely filled with just ones-or-zeroes.

The "core_id = 0" that comes up a line lower is an indication that the CPU is not explicitly listed in the list-of-supported-cpus.

[xor-gate]

I'm closing this old issue. As it should now be tested against master. Please reopen a new issue when similar problem exists.

[Nightwalker-87]

Can someone verify that this has been fixed?

[rewolff]

I updated to the latest git version by doing a git pull in my stlink.git repository....

The weirdness still exist.It seems I was still "new" to stm32 when I reported this. It is now firmly implanted in my brain that the 0xe004200 means "no chip".

assurancetourix:~/stm32/stlink.git> ./st-util -m
2020-02-26T18:36:19 INFO src/common.c: Loading device parameters....
2020-02-26T18:36:19 WARN src/common.c: unknown chip id! 0xe0042000
assurancetourix:~/stm32/stlink.git> 

Just FYI:
The desired situation would be that the "read chip ID" function can return -1 as "error", and that instead of printing "unknown chip id 0xfffffff" the message would read something like: Error: No chip found.

While we're at it.... Is the message "loading device parameters" necessary? I have a hard time getting the interns to read error messages. Less output means less confusion. That message was useful in the baby-years of stlink utilities, but the function that prints this message is now reliably being called so there is no reason for this message to keep being printed. Could that message be demoted to a DEBUG message that doesn't get printed by default?

[Nightwalker-87]

@rewolff: Feedback like yours gives me the impression and feeling that it is really worth it to review all closed issues of this project for leftovers no matter when they occurred. I am really sorry that you had to deal with this problem for such a long time - very unsatisfiable indeed. Trying to push the priority up for this.

[Nightwalker-87]

@rewolff: Your proposal seems very reasonable to me. If you fancy, you may submit a PR for this which is linked to this issue.

[Nightwalker-87]

BTW: I assume there may be more of these "hidden" error codes that could see some "decription" as well.

[rewolff]

Working on it....

FYI, I had trouble getting an STM recognized. Probably an older version of stlink. Getting latest now.

assurancetourix:~> st-util -m
2020-03-21T15:05:04 INFO src/stlink-common.c: Loading device parameters....
2020-03-21T15:05:04 WARN src/stlink-common.c: unknown chip id! 0xe0042000
assurancetourix:~> st-util -m
2020-03-21T15:05:39 INFO src/stlink-common.c: Loading device parameters....
2020-03-21T15:05:39 WARN src/stlink-common.c: unknown chip id! 0

[Nightwalker-87]

Yes, please use v1.6.0 or even develop which itself is despite of the name also fairly stable.

[Nightwalker-87]

Note: PRs will go into develop anyway. Please consider this when opening such in the future.

[rewolff]

Sorry, didn't see your remark about using develop until after I finished the PR. Can you cope or do I need to redo it?

[Nightwalker-87]

No that's ok, I can fix this as well. I know this is a bit annoying to contributors. :-/ I've already consulted texane to switch the base branch to develop what would take this additional consideration away from users. If I could, I would have done that already.

[Nightwalker-87]

The weirdness still exist.It seems I was still "new" to stm32 when I reported this. It is now firmly implanted in my brain that the 0xe004200 means "no chip".

assurancetourix:~/stm32/stlink.git> ./st-util -m
2020-02-26T18:36:19 INFO src/common.c: Loading device parameters....
2020-02-26T18:36:19 WARN src/common.c: unknown chip id! 0xe0042000
assurancetourix:~/stm32/stlink.git> 

Just FYI:
The desired situation would be that the "read chip ID" function can return -1 as "error", and that instead of printing "unknown chip id 0xfffffff" the message would read something like: Error: No chip found.

@rewolff: We should have a new ticket related solely to documentation for this as it did not make it into PR 886. I would consider it very useful to have either a inline-comment or a lookup table for these codes.

[rewolff]

My testing shows that it does sensible things now. That's why I didn't do anything for this.

OK... Mine now says:
2020-03-22T12:05:32 WARN common.c: Invalid flash type, please check device declaration
and doesn't consider that fatal. I can dive in and make this message "fatal", but I don't know if it maybe makes sense to have the debugger connected without knowing "flash type"? Maybe debugging works, but flashing new firmware not?

Edit: ohhhh..... I've silenced the hints that "nothing is connected".... OK. That needs to be on me to fix. A chipID of "000" should be a clear: "no chip connected" fatal error. Gimme some time to think about this.