Stephane and Wayne: As an FYI, the commands that you list do the following:
w4 4001e504 2 -> This is the NVMC CONFIG register. Writing a 2 enables erase. w4 4001e50c 1 -> This is the NVMC ERASEALL register. This will erase the UICR and the entire flash. Note that there is also a MPU on this device that can be used to enable other protections. On reset, the MPU registers are “disabled”, meaning that the protections provided are not enabled but if some bootloader runs that writes to these registers you might have issues trying to erase portions of the flash. I mention this only as a FYI in case you run into difficulties erasing the device. Note that we will be adding a microbit BSP soon; definitely on the radar! Not that that helps you now... Let me know if you run into other difficulties Wayne. Will > On Jun 3, 2016, at 1:15 AM, Stephane D'Alu <[email protected]> wrote: > > On 06/03/2016 07:32 AM, Wayne Keenan wrote: >> Hi Will, >> >> Ok, thanks for letting me know. Boards 2&3 are 'hidden' behind the mbed >> CMSIS-DAP interface and I also didn't want to resort to using additional >> h/w (a non-dev user wouldn't have) in order to erase or program them; prior >> to programming board 1 am using: >> >> JLinkExe -device nrf51 -if swd -speed 4000 >> >> erase >> >> q > > That will remove protections and erase > (don't remember where I got it) > > w4 4001e504 2 > w4 4001e50c 1 > sleep 100 > erase > > >> >> >> . >> All the best >> Wayne >> >> On 2 June 2016 at 23:12, will sanfilippo <[email protected]> wrote: >> >>> Hey Wayne: >>> >>> We dont “officially” support the boards you mention as they are not in the >>> supported BSPs. If you have an “official" nrf51dk that would be the best to >>> get started on as we do support that currently. >>> >>> Unfortunately, bletiny is a bit of a misnomer; it is not so tiny, and >>> depending on which version you are trying to build it may be too large to >>> fit in our current image slot; bleprph should work though. We may have a >>> work-around for nrf51 bletiny soon but for now I would use bleprph. >>> >>> BTW, are you sure you have erased the devices you are trying to load the >>> code on? There are protection mechanisms that you must disable in order for >>> our newt tool to be able to erase/program flash. >>> >>> >>> >>>> On Jun 2, 2016, at 2:04 PM, Wayne Keenan <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> I've been trying to get the bletiny and bleprph apps running on a few >>> types >>>> of nrf51 boards but not having much luck. >>>> >>>> The 3 types are: >>>> >>>> 1. PCA10000 - QFAA G0 (The stubby little USB dingle with the built-in >>>> Jsegger J-link) >>>> 2. PCA10024 - QFAA G0 (The mbed enabled board, using a hex file ) >>>> 3. BBC:Microbit - QFAA M0 >>>> >>>> I've tried with bsp set to 'nrf51dk-16kbram' and 'nrf51dk' >>>> I am uploading the Newt boot loader app too. >>>> >>>> >>>> In order to upload to #2 & #3 (as they appear as USB drives) I've tried >>>> converting the elf binaries to a combined hex file in two different ways: >>>> >>>> A) >>>> >>>> arm-none-eabi-objcopy -O ihex bin/bletiny/apps/bletiny.elf app.hex >>>> arm-none-eabi-objcopy -O ihex bin/nrf51_boot/apps/boot/boot.elf boot.hex >>>> >>>> mergehex -m app.hex boot.hex -o microbit_firmware.hex >>>> >>>> B) >>>> >>>> srec_cat boot.hex -intel app.hex -intel -o combined.hex -intel >>>> >>>> >>>> I'm pretty sure for #3 that it's possible to flash the entire address >>> range >>>> of the nrf51 as the micro:bit's default firmware download from the web >>> is >>>> a > 500k hex file; which without lifting the hood it implies to me it has >>>> the SoftDevice, App and Bootloader. >>>> >>>> I'm not having much luck, I probably need to add some load/start address >>>> info during objcopy and/or some address altering flags using srec_cat (?) >>>> >>>> Are these boards and the methods currently supported? I guess they >>> should >>>> be but I've buttered fingered something somewhere. >>>> >>>> Or perhaps should I be using the 'official' nrf51dk ? >>>> >>>> >>>> All the best >>>> Wayne >>> >>> >> > > > -- > Stephane D'Alu
