Group Actions
Engagement
  • Author Author: parasquid
  • Date Created: Date Created
  • Views 1536 views
  • Likes 0 likes
  • Comments 3 comments
Related
Recommended

ARM Mbed OS on a Bare nRF52840 Chengdu Ebyte Custom Target

parasquid

A few days ago, the Mbed team released version 6.3 https://os.mbed.com/blog/entry/Mbed-OS-63-released-today/ of the Mbed OS and along with it a BLE CLI app that is part of a new Bluetooth integration test suite https://os.mbed.com/blog/entry/Introducing-the-Mbed-OS-Bluetooth-integr/ that can help debug BLE software issues.

 

Since it's a Weekend Wednesday https://www.youtube.com/watch?v=ALaTm6VzTBw I thought I'd try out Mbed on the nRF52840 module https://psqd.pw/ebyte-nrf52840 manufactured by Chengdu Ebyte. I was especially interested in the BLE CLI app which looks like it can make setting up various BLE advertising options really easy and fast. I also wanted to try out the new Mbed Studio release, which allows me to compile firmware locally (instead of using the online compiler).

 

Mbed Studio is really easy to work with when you use a supported board. When I used my nRF52832DK as an Mbed target (by first flashing the Mbed daplink firmware onto the built-in j-link programmer) everything "just works." They do support custom targets as well, but it's not as straightforward.

 

I wanted to start with small steps, so I loaded up the blinky example and started figuring out how to make it support a custom target.

 

image

The first thing to do is connect your j-link (Mbed Studio probably supports other programmers, but this is all I have) and select that as the USB device. Then on the build target you'll need to click on the button to the right so you can create your own custom_targets.json where you can then define parameters for your chip (or board).

 

In my case, I put this in my custom_targets.json file:

 

{

    "TARGET": {
        "inherits": ["MCU_NRF52840"],
        "components_remove": ["QSPIF"],
        "overrides": {
            "lf_clock_src": "NRF_LF_SRC_SYNTH"
        }
    }
}

 

The Mbed documentation on custom targets https://os.mbed.com/docs/mbed-studio/current/targets/custom-targets.html was a huge help at this point. What got me really stuck was the realization that my bare chip didn't have a low frequency clock source, which the ancestor target MCU_NRF52840 requires by default. I was really frustrated when I was trying to upload the blinky hex file and it doesn't work; until I figured out the clock source overrides.

 

Aside from the custom target definition, you'll also need to add two files: device.h and PinNames.h which you can just copy from the mbed-os\targets\TARGET_NORDIC\TARGET_NRF5x\TARGET_NRF52\TARGET_MCU_NRF52840\TARGET_NRF52840_DK folder.

 

At this point I had to use my j-link for another project, so now I'm using a "clone" j-link programmer and OpenOCD to flash the hex file onto the chip.

 

c:\Users\tristan\Mbed Programs\mbed-os-example-blinky\BUILD\TARGET\ARMC6>openocd -d2 -f interface/jlink.cfg -c " transport select swd" -f target/nrf52.cfg -c "init; halt; flash erase_check 0; program mbed-os-example-blinky.hex; reset; exit"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

swd
Info : J-Link ARM-OB STM32 compiled Jun 30 2009 11:14:15
Info : Hardware version: 7.00
Info : VTarget = 3.300 V
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x0002f4a4 psp: 0x20004f18
Info : nRF52840-xxAA(build code: D0) 1024kB Flash, 256kB RAM
Warn : Flash protection of this nRF device is not supported
Error: nrf52.cpu -- clearing lockup after double fault
Running slow fallback erase check - add working memory
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000398 msp: 0x20040000
** Programming Started **
Warn : Adding extra erase range, 0x0000941c .. 0x00009fff
** Programming Finished **

 

image

And we have a blinky! image

 

Next is to clone the ble-cliapp project from https://github.com/ARMmbed/mbed-os-bluetooth-integration-testsuite/tree/master/ble-cliapp  and build it. It's mostly the same process as the blinky, except that on the PinNames.h I had to change some of the pin definitions to match the pins I'm using with my FTDI adapter (not all of the nRF52840 pins are exposed by the ebyte module so I had to find good alternatives).

 

    // RX_PIN_NUMBER  = p8,
    // TX_PIN_NUMBER  = p6,
    RX_PIN_NUMBER  = P1_10,
    TX_PIN_NUMBER  = P1_11,
    // CTS_PIN_NUMBER = p7,
    // RTS_PIN_NUMBER = p5,
    CTS_PIN_NUMBER = P0_3,
    RTS_PIN_NUMBER = P1_13,

 

Flashing the firmware onto the chip via OpenOCD and then connecting to the COM port my FTDI adapter is in (115200 8-N-1) gives a prompt which I can then follow the examples with.

image

It does advertise! And I can change the parameters without having to recompile and reflash.

image

Mbed seems to be an interesting platform. I feel it's quite similar to what Arduino is trying to do: have a base abstraction that can serve as a foundation for further code, which allows the developer the freedom to switch platforms (e.g. Nordic, STMicro, etc) while retaining portability. Having an abstracted ble cli driver makes it even easier to verify whether the software does what it's supposed to.