Have I "bricked" it with pyb.stop()?

[Gordon_Hardman]

I was debugging some code, and I added a pyb.stop() command to my code. I saw the command in the list of commands, but there was no explanation, so I thought I would give it a whirl...... should have been wary! And did it stop it! I can now see my code running (I2C, scope activity), but when (I believe) it gets to the stop command, it sits there.

Symptoms:
1. VCP is still shown (COM4), but programs cannot open this port. RealTerm reports "Apo error", WTMB.
2. It shows as "uPython USB device.... " in program manager. But does not "mount" it as a disk drive any more. So can't edit the pyb.stop() out.
3. Using DFU, I re-installed the code, but it made no difference. I guess since it does not change the program memory, this was to be expected- but since DFU works, the chip and USB connection must be okay.

Any ideas on how to un-brick it? I guess I need to erase the program memory somehow, although I hate to do that without downloading it first- I can't remember when I last backed it up. (my bad, but I wish there was a way to have the file on the board mirrored auto-magically on my PC somewhere). DFuse from STM doesn't seem to have an option to erase that part of memory.

Any ideas short of soldering on a new chip appreciated....

[blmorris]

Try starting your board in Safe Mode:

http://micropython.readthedocs.org/en/l ... #safe-mode

Your board will start up without executing your main.py or erasing your scripts, so you can get in and remove the pyb.stop() command.
And yes, pyb.stop() does stop the processor

Good luck!
-Bryan

[Gordon_Hardman]

Okay! Thanks. I know I read that once before, but I never retained it. Edited out the pyb.stop() and all is well. I suppose a better way is to use the USR switch, and set up a trap so the program pauses there until the switch is pushed. In fact, you could have multiples of this in your script, and stop at each one, to re-arm the scope trigger, read I2C monitor etc.

Problem solved. Thanks for the refresher.