You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Wayne Keenan <wa...@gmail.com> on 2016/06/02 21:04:37 UTC

Running Newt on nrf51 boards with 0.9.0 and 0-dev

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

Re: Running Newt on nrf51 boards with 0.9.0 and 0-dev

Posted by will sanfilippo <wi...@runtime.io>.
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 <sd...@sdalu.com> 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 <wi...@runtime.io> 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 <wa...@gmail.com> 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


Re: Running Newt on nrf51 boards with 0.9.0 and 0-dev

Posted by Stephane D'Alu <sd...@sdalu.com>.
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 <wi...@runtime.io> wrote:
>
>> Hey Wayne:
>>
>> We dont \u201cofficially\u201d support the boards you mention as they are not in the
>> supported BSPs. If you have an \u201cofficial" 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 <wa...@gmail.com> 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

Re: Running Newt on nrf51 boards with 0.9.0 and 0-dev

Posted by Wayne Keenan <wa...@gmail.com>.
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


.
All the best
Wayne

On 2 June 2016 at 23:12, will sanfilippo <wi...@runtime.io> 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 <wa...@gmail.com> 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
>
>

Re: Running Newt on nrf51 boards with 0.9.0 and 0-dev

Posted by will sanfilippo <wi...@runtime.io>.
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 <wa...@gmail.com> 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