WARNING: All Beta Boards NOW NEED TO BE UPDATED


#1

THE CHANGE HAS BEEN MADE!

You can download the programmer script and instructions from the bluz-beta GitHub page: https://github.com/bluzDK/bluz-beta/tree/master/programmer_1-22-16

Your boards are fine until you do a ‘git pull’ on the repository. So until you do, you do NOT need to run the script. If you do a ‘git pull’ and don’t run the script, your beta board will no longer connect to the cloud.

Please let me know if there are nay concerns or issues. Sorry for the hassle, this was a one-time process that was always looming so it is nice to get it out of the way!

OLD POST:
There has been a change I need to make as part of the provisioning process. When I started this whole thing I hard coded the keys that each board uses, made it much simpler to change things between servers and add new boards. Well, the time has come to make each board (rightfully) have its own keys.

This is a change we have already made in other products that we make based on bluz, and I have already tested it, so everything works. However, the firmware will change from reading a static byte array for its keys to actually retrieving it from the external SPI flash. Since none of the beta boards have a key in their external SPI flash, your board will stop connecting properly once you update to the latest code.

I will provide a Python script that you can run to update your board. In addition to generating and updating keys for you, it will also install the factory reset firmware in the external SPI flash so you can reset if things go bad.

I expect to roll out these changes either sometime tomorrow night or on Monday. So please note, once I do check in these changes, you will have to run the python script or your board will stop connecting to the cloud once you get the latest code. Once you run it one time, you won’t have to again.

The script requires adalink (to install firmware) and the particle cli (to generate new keys) and your board must also be claimed to your account. If anyone will have an issue with any of these requirements, let me know and we can figure something out.

I will post back here once the changes are done and the script is posted.


[Solved] Issue with Bluz DK in Serial1 debugging
#2

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.


#3

This topic is no longer a banner. It will no longer appear at the top of every page.


#4

#5

Hey Eric, Im getting an error when doing this. I saw @peekay123 had the exact same error,

you mentioned about checking ability to create keys, so i tried that and seemed to work ok? but it still gave an error, so i commented out the offending line (create key), but the next one fails (send key) and it deleted the key! (obviously gets the exception) so i commented out that one too… then i created new keys manually, i also sent the key manually to the cloud, and ran the script and the rest worked ok…

Also i couldnt be bothered working out serial, so i commented out that line too… may be worth adding a test to see if its installed before trying to load it. i dont think its needed with stlink?

Doing a quick google on the error now i think that we may need to add shell=True to the call to make it work on windows, but i havent given it a try yet.

now that i have reprogrammed my board i cant get it to show up in the app… like the ble isnt turning on or something… ill try reflashing tonight and ill let you know how i get on

Cheers,

Chris


#6

@Hootie81, I gave up on the script except for the part that defines the ID. I ended up using OpenOCD to flash all the parts manually for both the programmer and production firmwares.


#7

Eric, I know you must be super busy! so I have submitted a pull request on the programmer.py

I’ve tested it on windows, without the serial module installed and its working well.

if the user doesn’t specify a “-s port” it doesn’t try and load the module, if they do and pyserial isn’t installed it gives the reason and exits.

Later on in the script, if they aren’t using serial it asks the user to hit enter when flashing rainbows (i think that means the keys are copied to flash (i don’t know i have no LED on my boards)), otherwise it should do the same as before with the serial… i think! better test that one for me. I’m guessing that’s why i had problems yesterday getting my device connected again… it was not running the production firmware because it skipped that last step…

Also there was the need for shell=True to get the Particle keys commands to work properly in windows. and i noticed the exit didn’t work after the send failed before, it just needed the () on it


#8

Thanks! I’ll take a look. I had been traveling over the weekend and ended up getting stuck in Denver due to the weather, but am home now so I can hopefully get a lot more accomplished again.


#9

@Hootie81, thanks for that dude! I have a second bluz I can test the script with so I’ll let you know how it works for me. I have had issues with adalink in win7 but now with win10, I’d like to try it again. I should be able to test tonight. :wink:


#10

@Hootie81, I don’t see the PR!?


#11

Thats coz im an idiot and did it against the clone in my repo! still learning git…

how do i do a pull request against the bluz one then?

I did a fork of the main one, did the mods, pushed that as a new branch and did a PR… but its in my git not the main one

edit: i think its done now… just had to find the right button!


#12

@Hootie81, I see it now!


#13

Awesome, let me know how it goes, i don’t have the python serial module installed to test the if statement just before flashing the production firmware.


#14

@Hootie81,running particle keys new on the latest CLI does not work (looks for DFU device). You need particle keys new --protocol tcp.

Also, adalink still does not work. It wipe the bluz just fine, but no programming.


#15

Yep your right… I’ve just updated my CLI and see the issue, ive updated and pushed the change do i need to do another pull request? or will it update automagically?

My adalink seems to be working fine, what error are you seeing? does it work manually?


#16

@Hootie81, I see the changes on the exsiting PR. On my system, Adalink will wipe the bluz but won’t program. NO errors are generated.


#17

Thats strange, what about with verbose output in adalink?


#18

@Hootie81, haven’t tried that, at least not that I recall. I don’t see a verbose command line argument for Adalink.

Right now I run OpenOCD and run these commands from the programmer_xxx directory:

flash write_image C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/int.bin 0x3F000 bin
flash write_image C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/device.bin 0x3F400 bin
flash write_image C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/keys/cloud.public.bin 0x3F800 bin
program C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/s110/s110_softdevice.hex verify
program C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/programmer_fw/bootloader/bootloader.hex verify
program C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/programmer_fw/system/system-part1.hex verify

program C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/s110/s110_softdevice.hex verify
program C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/production_fw/bootloader/bootloader.hex verify
program C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/production_fw/system/system-part1.hex verify
program C:/SPARK/BluzBeta/bluz-beta/programmer_1-22-16/production_fw/user-part/tinker.hex verify

#19

what do you use to do the programming? is it a stlink v2? it would be nice to verify… i don’t think adalink does that.

what adalink version are you running? im at 2.2.0.
-v for verbose output… straight after adalink otherwise it doesnt work

C:\Bluz\2-2-16\bluzDK-firmware>adalink -v nrf51822 --programmer stlink --wipe --program-hex ../bluzDK-firmware/build/target/system-part1/platform-103-m/system-part1.hex --program-hex ../bluzDK-firmware/build/target/user-part/platform-
103-m/mine.hex --program-hex ../bluzDK-firmware/platform/MCU/NRF51/NRF51_StdPeriph_Driver/inc/softdevice/s110/hex/s110_softdevice.hex --program-hex ../bluzDK-firmware/BluzBootloader0-1-2/bluz_bootloader.hex
INFO:adalink.programmers.stlink:Using path to OpenOCD: openocd.exe
INFO:adalink.programmers.stlink:Using parameters to OpenOCD: -f interface/stlink-v2.cfg -f target/nrf51.cfg
DEBUG:adalink.programmers.stlink:Running OpenOCD command: openocd.exe -f interface/stlink-v2.cfg -f target/nrf51.cfg -c "init" -c "exit"
DEBUG:adalink.programmers.stlink:OpenOCD response: Open On-Chip Debugger 0.9.0 (2015-05-19-12:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.740819
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints

DEBUG:adalink.programmers.stlink:Running OpenOCD command: openocd.exe -f interface/stlink-v2.cfg -f target/nrf51.cfg -c "init" -c "reset init" -c "halt" -c "nrf51 mass_erase" -c "exit"
DEBUG:adalink.programmers.stlink:OpenOCD response: Open On-Chip Debugger 0.9.0 (2015-05-19-12:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.740819
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
Warn : Unknown device (HWID 0x00000084)

WARNING: Flash memory will be erased before programming nRF51822 with the STLink!
DEBUG:adalink.programmers.stlink:Running OpenOCD command: openocd.exe -f interface/stlink-v2.cfg -f target/nrf51.cfg -c "init" -c "reset init" -c "halt" -c "nrf51 mass_erase" -c "flash write_image {C:\Bluz\2-2-16\bluzDK-firmware\build
\target\system-part1\platform-103-m\system-part1.hex} 0 ihex" -c "flash write_image {C:\Bluz\2-2-16\bluzDK-firmware\build\target\user-part\platform-103-m\mine.hex} 0 ihex" -c "flash write_image {C:\Bluz\2-2-16\bluzDK-firmware\platform
\MCU\NRF51\NRF51_StdPeriph_Driver\inc\softdevice\s110\hex\s110_softdevice.hex} 0 ihex" -c "flash write_image {C:\Bluz\2-2-16\bluzDK-firmware\BluzBootloader0-1-2\bluz_bootloader.hex} 0 ihex" -c "reset run" -c "exit"
DEBUG:adalink.programmers.stlink:OpenOCD response: Open On-Chip Debugger 0.9.0 (2015-05-19-12:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.770938
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
Warn : Unknown device (HWID 0x00000084)
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 90224 bytes from file C:\Bluz\2-2-16\bluzDK-firmware\build\target\system-part1\platform-103-m\system-part1.hex in 1.828460s (48.188 KiB/s)
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 2964 bytes from file C:\Bluz\2-2-16\bluzDK-firmware\build\target\user-part\platform-103-m\mine.hex in 0.111483s (25.964 KiB/s)
Info : Padding image section 0 with 2112 bytes
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 92440 bytes from file C:\Bluz\2-2-16\bluzDK-firmware\platform\MCU\NRF51\NRF51_StdPeriph_Driver\inc\softdevice\s110\hex\s110_softdevice.hex in 1.862236s (48.476 KiB/s)
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 9868 bytes from file C:\Bluz\2-2-16\bluzDK-firmware\BluzBootloader0-1-2\bluz_bootloader.hex in 0.364997s (26.402 KiB/s)


C:\Bluz\2-2-16\bluzDK-firmware>

#20

@Hootie81, it seems I have adalink 2.0.0. and openocd 0.9.0. I’ll upgrade to 2.2.0. I’ll assume I don’t need to uninstall the existing version.

UPDATE: Did the install and I now have adalink 2.3.1. I’ll test tonight. Thanks!