MBR got erased

Hi,

Is it possible (and how) MBR got erased when I upload the code from Web-IDE.

Actually I have a nrf52 based fitness tracker. I have build Espruino (not the latest one, but somewhere around 2V.07.XXX). Since this version is the sable (for me and SDK11).

When I upload the code for color OLED display driver in Inline C function, which is not mine but was originally developed for B5 and
F07 trackers.
What I did-

1. I upload the code for B5
   
2. Without resetting board (reset()) I upload F07 code. I have disabled reset before send in Web IDE for some reason
   
   

When I reversed the code like Upload F07 and then B5, it did not brick the device.

Jut after second upload, WEB IDE got disconnected and tracker is not searchable in BLE search (Web IDE and nrfConenct)

After that I connected the tracker with SWD stlink and dump the flash bank 0. I noticed that MBR is filled with 0xFF from 0x0 to 0xfff.

What I understood is the MBR is clear somehow and device is bricked. Is it really possible that MBR can be erased by any chance.

I successfully bricked the device 2-3 times same way (and revived by mass erase) and every time it bricked.

Is it old Espruino code I am using.
It is the Inline C oled driver causing this?

There was no firmware upgrade or flashing (other then Web-IDE upload to RAM) involved in entire process.

Thanks

It's very unlikely. The softdevice generally stops you writing to protected areas of flash memory and you have to turn it off before you can do that. While Espruino allows you to write to flash, it also has protection (can be overridden via E.setFlags) to stop you overwriting Espruino itself or the softdevice/bootloader.

I've shipped a lot of nRF52-based devices now - I can't remember the exact figure but probably over 20,000 - and I can't even remember a time when anyone has been able to properly brick their device (apart from by flashing very early firmwares onto Puck.js v2 via DFU).

I think the protection is only enabled for official board names
https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/jshardware.c#L213­5

If it is reproducible then maybe logging in jshFlashErasePage for zero address could be interesting to see if it gets triggered. Or the procection there could be enabled to see if it goes away.

Anyway uploading similar code for two different devices to third device without reset() in-between is definitely asking for trouble and is great stress test. Anything could happen during upload

• watchdog trigger
  
• out of memory
  
• stack overflow
  
• mix of old and new code running from watches and intervals
  
  

However erasing MBR is still interesting result of such abuse, the js code uploaded does not write/erase internal flash anywhere. If the code was really uploaded to ram only and not storage then even storage bug in not likely.

If it is reproducible then maybe logging in jshFlashErasePage for zero address could be interesting to see if it gets triggered. Or the procection there could be enabled to see if it goes away.

Yes it is I can reproduce it many times.
Do you have sample code to test as you mentioned here? @fanoush

However erasing MBR is still interesting result of such abuse

Honestly it was an accident and I bricked a brand new watch unfortunately. I reproduced it later on another opened watch.

Do you have sample code to test as you mentioned here? @fanoush

just check the method I already linked https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/jshardware.c#L213­5
so remove the #if defined(PUCKJS) ... or add your board name there. Also you can add jsiConsolePrintf to the if (addr<0x1f000) part so you know it was called with wrong address.

If it is reproducible then maybe logging in jshFlashErasePage for zero address could be interesting to see if it gets triggered. Or the protection there could be enabled to see if it goes away.

Nope, it did not log anything jshFlashErasePage function. But again device got bricked!!