Timeline for STM32F7 device freeze: cannot access registers
Current License: CC BY-SA 4.0
19 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 10, 2019 at 8:05 | history | edited | Sean Houlihane | CC BY-SA 4.0 |
Reqrite question updates to be less 'forum' style and easier to parse.
|
May 9, 2019 at 16:31 | answer | added | Pranit Pawar | timeline score: 0 | |
May 9, 2019 at 14:57 | comment | added | Lundin | The usual suspects: MCU reset including watchdog, loss of clock, loss of power/brown-out. | |
May 9, 2019 at 14:46 | vote | accept | nick | ||
May 9, 2019 at 14:34 | answer | added | Sean Houlihane | timeline score: 1 | |
May 9, 2019 at 13:34 | history | edited | nick | CC BY-SA 4.0 |
added 2268 characters in body
|
May 9, 2019 at 12:54 | comment | added | nick | @SamGibson thanks, I will clarify | |
May 9, 2019 at 12:46 | comment | added | SamGibson♦ | (e) You ask about capturing data after a reset, but you report the problem is the MCU "freezing", not that it is resetting. I guess (but it isn't clear) that the problem is always that the MCU freezes. It's you who can perform a manual reset, and you are asking whether any useful info can be captured after manual reset. Is that correct? Again, please edit the question to add details about the exact steps you follow to (i) perform the test which triggers the problem and (ii) what you are doing after that e.g. are you performing a manual reset? (f) Please add a schematic too. Thanks. | |
May 9, 2019 at 12:43 | comment | added | SamGibson♦ | @nick - Please edit your question to add more details: (a) Explain the hardware - is this your design, or a standard dev board? Add photos of the hardware into the question. (b) Assuming it's your design, explain the history - has this always been a problem, or was there a time when this problem didn't happen? What troubleshooting have you done so far? (c) What simplification can you do (or have you done already) to the system e.g. reducing clock speed; removing external connections, running just "blink LED" code etc.? (d) What is failure rate and have you found anything that alters it? | |
May 9, 2019 at 12:31 | comment | added | nick | @Jon standard clock config, 216MHz | |
May 9, 2019 at 12:26 | comment | added | nick | @SunnyskyguyEE75 yeah I figured, I think it is interrupt related due to its asynchronous nature | |
May 9, 2019 at 12:23 | comment | added | nick | @Andyaka no, this issue is reproducible over multiple (identical) devices | |
May 9, 2019 at 12:20 | comment | added | nick | @Arsenal I will test this out, thanks for the tip! | |
May 9, 2019 at 11:35 | comment | added | Jon | How is the system clocked? Are you using standard clock configuration code (e.g. CubeMX)? | |
May 9, 2019 at 11:24 | comment | added | D.A.S. | waiting for an incomplete IO | |
May 9, 2019 at 11:22 | comment | added | Andy aka | Sounds like a hardware reset issue to me. Is this a one-off design? | |
May 9, 2019 at 11:06 | comment | added | Arsenal | What you ideally want is the functionality to attach to the target while it is running. I'm not using your toolchain, so I have no idea if it is possible. This website offers some information with a Segger J-Link, and I have a slight memory that a ST-Link can be upgraded into a J-Link (not sure if it was only the ones on the Nucleo boards). But even without that it might help as the way might also work for the ST-Link. | |
May 9, 2019 at 9:50 | review | First posts | |||
May 9, 2019 at 9:57 | |||||
May 9, 2019 at 9:46 | history | asked | nick | CC BY-SA 4.0 |