search

pyocd / pyOCD

Open source Python library for programming and debugging Arm Cortex-M microcontrollers
https://pyocd.io
Apache License 2.0
1.13k stars 484 forks source link

FlashEraseFailure with new microbit v2 (nrf52833) #1212

Open aiunderstand opened 3 years ago

aiunderstand commented 3 years ago

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. image

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?

aiunderstand commented 3 years ago

Command line workaround (needed only once):
1) pyocd erase --mass --t nrf52833 2) 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?

aiunderstand commented 3 years ago

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?

flit commented 3 years ago

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.

microbit-carlos commented 3 years ago

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.

aiunderstand commented 3 years ago

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.

microbit-carlos commented 3 years ago

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/

aiunderstand commented 3 years ago

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

microbit-carlos commented 3 years ago

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)

aiunderstand commented 3 years ago

Interesting, it fails to flash my .bin after I flashed it with a hex from the online editor as well.

carlosperate commented 3 years ago

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 😅)

aiunderstand commented 3 years ago

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

aiunderstand commented 3 years ago

I don't know if this is relevant, but I cannot "pyocd flash microbit_program.hex" resulting in this error:

image

With the first five lines of the hex (downloaded from https://python.microbit.org and clicked download to get its hex)

image

microbit-carlos commented 3 years ago

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/

aiunderstand commented 3 years ago

Ah ok, so unrelated to this issue.

aiunderstand commented 3 years ago

Inspired by Issue #1215 , I am starting to doubt if APPROTECTSTATUS register is enabled. If I try

image

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.

aiunderstand commented 2 years ago

Thanks for confirming the issue.