pyOCD
pyOCD copied to clipboard
pyocd
FlashEraseFailure with new microbit v2 (nrf52833)
PyOCD v0.32 with python 3.9.6 on Windows 10
Hi, I am trying to flash a binary to my new MicrobitV2 using pyocd, but I get the error below.
The workaround is to drag an drop the binary in the Microbit v2 drive after which it reboots and flashing with pyocd works as normal. Any idea if I can set a flag to force the flashing of a new Microbit v2?
Command line workaround (needed only once):
- pyocd erase --mass --t nrf52833
- flash like normal, eg. pyocd flash
Any idea why a mass erase is needed and a chip or sector erase doesn't work with a new MicrobitV2?
It look like new MicrobitV2's are programmed with APPROTECTSTATUS register enabled, meaning that an ERASEALL command is needed to overwrite this protection according to https://infocenter.nordicsemi.com/pdf/nwp_027.pdf. This is different from new MicrobitV1's who are unlocked/RBPCONF disabled. The pyocd nrf52 implementation https://github.com/pyocd/pyOCD/blob/main/pyocd/target/family/target_nRF52.py defines how to do mass erase.
Could a 1 command solution be that pyocd flash have a "-e mass" flag or that "-e auto" tries a mass erase if chip and sector erase fail?
Funny, I have a todo note from a while ago wondering whether pyocd should attempt a mass erase if chip/sector fails. 😄 I have some new v2s, so let me investigate a little to understand the details.
@carlosperate Is it true that flash is locked on the micro:bit v2 from the factory? If so, why lock it? Seems unfriendly to users.
The micro:bit V2 nRF52 flash is not locked from factory, or at least not on purpose.
Would DAPLink MSD flashing work if it's locked? We had an issue with a malformed hex file accidentally locking the nRF52 flash and DAPLink wasn't able to reflash it via MSD until a pyocd erase chip command was executed first.
See OP, if I drag and drop my .bin file to the MSD of a new micro:bit V2 the flash is programmed and pyocd flash command line then works with the same .bin file. Another workaround is pyocd erase --mass before pyocd flash.
I had this issue with all the new micro:bit V2's (+- 30 ). Product number on the device is: micro bit educational foundation CMIIT ID: 2020DJ13018 Model: V2.0
The MB runs a demonstrator application that plays music on the speaker at startup.
See OP, if I drag and drop my .bin file to the MSD of a new micro:bit V2 the flash is programmed and pyocd flash command line then works with the same .bin file. Another workaround is pyocd erase --mass before pyocd flash.
And this is only when is factory new? So if you flash a micro:bit hex file from a micro:bit editor (MakeCode or Python) PyOCD still works, correct? Can you flash the factory Out of Box hex and try again? https://microbit.org/get-started/user-guide/out-of-box-experience/
Thanks for the quick response. And spot on. When I upload the Out of Box hex, the issue returns and I cannot flash it without doing pyocd erase --mass first
Thanks for the quick update as well! Is that only with the Out of Box? Does it do the same with a hex file from the online editor? (You can just go to https://python.microbit.org and click download to get a hex)
Interesting, it fails to flash my .bin after I flashed it with a hex from the online editor as well.
Can you consecutively flash different bin files with PyOCD? I wonder if the issue is having to erase between flashing different programmes. (ups, sorry, I replied to this with my personal account, I'm the same Carlos 😅)
Yes, I can flash different bin files with PyOCD consecutively, but only after it is unlocked with a pyocd erase --mass when it was programmed with a hex before
I don't know if this is relevant, but I cannot "pyocd flash microbit_program.hex" resulting in this error:
With the first five lines of the hex (downloaded from https://python.microbit.org and clicked download to get its hex)
That would be because it's a "Universal Hex", we extended the Intel Hex format to use additional record types to be able to have data for multiple targets (micro:bit V1 and V2) in the same file. Old versions of DAPLink (in micro:bit V1) ignores the new records, but I assume PyOCD must be validating them.
https://tech.microbit.org/software/spec-universal-hex/
Inspired by Issue #1215 , I am starting to doubt if APPROTECTSTATUS register is enabled. If I try
I get the same result with both the .hex and my .bin flashed. The status command does not indicate locked or unlocked but AP register 1 being 1 means unlocked according to https://github.com/pyocd/pyOCD/blob/main/docs/security.md
@flit or @microbit-carlos can you verify the issue of needing a mass erase before flashing it with your own .bin using pyocd flash? The MB doesn't need to be factory new, a hex uploaded using DAPlink MSD from https://python.microbit.org should replicate the issue.