I recently received my Seeed BLE Nitrogen board for zephyr development, and discovered it is reporting the wrong device code. It is reporting itself as an Arch BLE board:
pyocd-flashtool -l
0 => Arch BLE [nrf51] boardId => 9009022103BB1A08FE6575F9
And from its MBED.HTM file:
<meta http-equiv="refresh" content="0; url=http://mbed.org/device/?code=9009022103BB1A08FE6575F9"/>
How do I even find out the correct boardID / device code for a BLE Nitrogen (nrf52)?
That does not sound wrong since the microcontroller is a nordic one. The only odd point is that pyocd reports nrf51 instead of nrf52 because of the board id 9009, I don’t think this is an error with your board ID but maybe just a pyocd interpretation issue. Do you have any problem with board flashing ?
Flashing works fine as long as the ‘-t nrf52’ argument is part of the pyocd-flashtool command. Without it, I assume it’s defaulting to -t nrf51 and flashing is not quite right (the # of bytes flashed is different, and the board does not always boot properly afterwards).
Also, if I double-click on ‘MBED.HTM’ to register the board (per the instructions), it takes me to the Arch BLE page. This sounds wrong to me. Where can I find the list of device codes? And then how to change it?
Since the nitrogen development board mainly targets Zephyr RTOS, I suppose there is no deal with mbed and so nitrogen is not referenced on their website (https://www.mbed.com/en/about-mbed/mbed-enabled/).
Actually, this number (board-id) seems specific to the CMSIS-DAP interface/micro-controller itself, not to the nrf52. CMSIS-DAP is the interface allowing you to flash and debug the nrf52 micro-controller via USB (pyocd, drag-and-drop…), In your case this CMSIS-DAP interface is part of the nitrogen board (LPC11U35 microcontroller), this is not always the case.
You can find some board-id info in the pyocd source code: https://github.com/mbedmicro/pyOCD/blob/master/pyOCD/board/mbed_board.py
On my side, I have 2 nrf ble-nano v2 chips and 2 daplink debug boards, one has an unknown board-id (1093), the other returns a nrf51 board-id (1095). I have no problem to flash the boards, I usually use the drag-and-drop method.
If you really want to change this board ID I think you will have to change the DAPLink firmware and then flash the LPC11U35, this can be achieved by booting in maintenance mode, usually done by pressing reset, plug usb and release reset, then your device should be detected/mounted as a ‘MAINTAINANCE’ driver. DAPLink is available here: https://github.com/ARMmbed/DAPLink/ and board id are statically defined in source/board.
Loic, sounds like you’ve been doing this awhile. Thanks for all your help.
The board does not exist in the python link you sent, but it does exist in DAPLink/source/board (it is ID 9014, in 96b_nitrogen.c). I may try to reflash the NXP micro when I have time.
In the meantime, this may or may not be related, but drag and drop doesn’t work for me. I tried in Ubuntu and Windows 10. In either case, drag or copy the .bin file results in a file called ‘FAIL.TXT’ appearing in the virtual directory that says “The interface firmware FAILED to parse the hex file”. Drag or copy the .hex file and it just sits there.
bin files are raw binary data, you typically need to provide address to load/flash the binary at right place. hex file contains additional metadata (where to load the file, length, type…). For drag and drop method I usually copy the hex file to the virtual daplink disk. I only used Zephyr which generates both bin and hex files.
Which compiler or IDE are you using on your side ? KEIL for example should generate an hex file as well (Nordic Semiconductor Infocenter).
