Everything nRF52840

[scalz]

@heinzv
oki
that's what I meant. your pic shows it. Mysensors is already "full" stack with different layers, and afaik it's not in plan to replace its PHY+MAC layers by 15.4 . This would imply lot of work too and most of features are already present except slotted time rf which needs quite some work..
And changing these layers won't solve nrf5 resources, softdevice accessibility in arduino.
The others solutions

• d00616 work for mysensors : help to fix issues and finish the code
• fork mysensors to another non arduino platform supporting these stacks -> lot of work non supported by mysensors team (and still redundant, worth the effort? as you could directly use your favorite stack)

Like you I tried a lot of different roads too (I'm not new on the bleeding edge like I said)..full of dilemmas, no perfect solution, still working on it!

[heinzv]

@scalz just let me/us know or please share your findings.
I'm also exploring different roads for different cases. Not just MCU, radios, sensors, displays (TFT, LCD, ePaper) etc.
So far I've got some overview on the possibilities and limitations.
I'm quite satsified with the ESP family (8266/8285 and ESP32), but I see also the limitations of the Atmega families as well as the old STM32 families.
I like the LoRa radio as best option for long range and energy efficiency use cases, but see the potential of BLE 5.0 and ZigBee but have not yet experience with it and I'm at the beginning of the nRF5x learning, but it looks at least promising.
Any other option on the radar? ... I'll follow your inputs/discussions and of course observe the market as well by myself ...

[NeverDie]

Although it's hard to predict the future, I'd wager that Bluetooth 5 will greatly overshadow 802.15.4 when it comes to wireless sensors. Why do I say that? Because Bluetooth 5 is already included in some of the leading phones: https://www.gizbot.com/mobile/features/10-latest-smartphones-which-come-with-bluetooth-5-0-to-buy-in-inida-2018-047304.html

For instance, I have a Samsung Galaxy S8 phone, and up until just now I wasn't even aware that it actually contains Bluetooth 5. Does that mean my phone can communicate with a Nordic nRF52840 using the 125kbps long range settings? I don't know, but I'm now curious to find out. Anyone know?

According to Nordic, the 500kbps mode will have twice the range of the 1mbps datarate, and the 125kbps datarate will have 4x the range of the 1mbps datarate:

I guess they're comparing it to the 1mbps proprietary mode of the same radio? Part of the reason for the 2x or 4x range increase can be attributed to the coding gain, which, AFAIK, the 250kbps 802.15.4 mode doesn't have. Unfortunately, the article doesn't say what kind of range increase to expect from the 802.15.4 mode, but I'm guessing (?) it will not be a lot. Maybe, what, 10% or 20% better? Any guesses?

But range of the 125kbps mode should be even more impressive if comparing against the nRF24L01, which has a link budget of 86dbm:

https://www.eetimes.com/document.asp?doc_id=1276396&page_number=2
as compared to 111dbm for the 125kbps mode of the nRF52840 (as quoted by the same Nordic blog as above). Part of that is from the greater Tx power and receive sensitivity of the nRF52840. In the end, all those details get reduced to a single link budget number, which is apparently how a proper comparison is made.

[Edit: https://devzone.nordicsemi.com/b/blog/posts/taking-a-deeper-dive-into-bluetooth-5]

[heinzv]

@NeverDie I also own a Galaxy S8 and interested in that study.
I especially like the idea to have a very energy efficient MCU which contains already a very energy efficient radio. That saves a lot of energy in total, soldering, wiring, complexity of multi chip handling (sleep, wake, sync) and saves also space (makes PCB's and devices smaller).
If the range is sufficent and we get the development environment satisfying established, what else are we missing?
Price and MCU performance is also ok, Flash and RAM is ok. Availability of internal peripheral and sleep/wakeup behaviour is ok. The only small drawback I've seen is that there is no internal EEPROM.
Once I have my dongles and or breakout PCB's (for the "inconvinient" 1.1mm pinouts and soldering pads below the module), I'll start with the sensor communication, radio transmission and ePaper display. If the range is satisfying with BLE then I also need to decide how I integrate with my controller OpenHAB (a mySensors binding if we get that added, ZigBee, MQTT which a MQTT gateway ...). Would be interested what your plans for integration are (which is also releated to the comment from @scalz)

[scalz]

about indoor range, if you didn't try the TI range estimator excel sheet link, I extracted list of absorption material, if it interests anyone

about using multi protocols in same band, a while ago I modified a graph I found on internet, for comparing wifi less crowded channels VS nrf24/52 channels in MySensors.
Note: zigbee also uses same channels, some implementation can do frequency hopping too, making harder to predict PER packet error rate etc. If I remember Zigbee channel 1 = nrf24/52 channel5. Last zigbee channel being nrf24/52 channel 80.

maybe I'll try to make an article about all this rf stuff (missing time atm).
Still good to know, what possible issues with coexistence of multiple protocols used in same band without good device placement or "time slots" for switching protocols and avoiding "potential collisions". But this would need same synced software for all devices.
I would say, I can be wrong, it's not a great idea to use too many protocols in same band without these precautions, can get messy in air. (not mentioned neigboors playing with different endproducts in same band, antenna detuning, efficiency due to hw designs, ->shifting center freq, bandwitdth etc..).

[NeverDie]

Sadly, at least as of June 2018, none of the smartphones supported the long range capabilities of Bluetooth 5, only just the 2mbps Bluetooth 5 capability.

Bluetooth 5 features in smartphones

Bluetooth 5 includes capabilities for faster speed and longer range. It’s fairer to say, however, that developers must choose between speed or range.

Read more: The Bluetooth 5 trade-off

In smartphones, however, you don’t even have that choice. To date none of the smartphones support the Coded PHY that extends the range of Bluetooth 5. Instead you can have the 2mbps speed. For most applications this is likely to be fine. Most consumers are looking for ways to connect to devices that are within a few feet of them. The longer-range features are more useful for lower bandwidth applications such as sensor networks.
https://blog.nordicsemi.com/getconnected/bluetooth-5-in-smartphones

I don't know if that's an android limitation which might improve, or whether the radio chips in the phones are missing the required hardware to do coded 125kbps Bluetooth 5 long range. I can understand that there's a chicken and egg dilemma holding things back, and that right now there's probably not any reason for phone manufacturers to give long range priority in their phones, since at present there's very few, if any, devices for the phones to connect with using Bluetooth 5 long range.

Nonetheless, this post has links to demo code for long-range bluetooth on the Nordic: https://devzone.nordicsemi.com/f/nordic-q-a/38267/long-range/148485#148485

[heinzv]

@neverdie I read an article regarding BLE 5.0, ANdroid and the Samsung Galaxy S8 HW (the used SoC from Qualcom/Snapdragon or from Samsung varying on the model/region).
The article is in German but it says: BLE 5.0 was introduced with Android 8.0 but the S8 HW does only support the 2x data rate (2MBps) but not the 4x range. So it seem that it is a HW limitation similar to the nRF52832 in comparison to the nRF52840. Only the 840 support both, the 832 only the higher data rate. Strange, that this is so bound to the HW and thus so limiting and unflexible.

[NeverDie]

It's worth noting that Texas Instruments has a $29 launchpad which demonstrates its flavor of Bluetooth Long Range: http://www.ti.com/tool/launchxl-cc2640r2
It uses a Cortex M3 rather than an M4.
I think it might be worth looking into to see whether it's any easier to use than SES.

Cypress Semiconductor has its version, with kits starting at $49.
http://www.cypress.com/products/ble-bluetooth

Likewise, silicon labs has its version, but the starter kit is $99: https://www.silabs.com/support/getting-started/bluetooth/bluetooth-low-energy
https://www.silabs.com/products/wireless/learning-center/bluetooth/bluetooth-5?gclid=EAIaIQobChMIodewu8PR3QIVXrXACh2IZwE5EAAYASAAEgI3OfD_BwE

Are there other manufacturers worth noting?

I wish at least one of them had an official video course. That would speed up the learning process. I think Nordic has made the mistake of not making it easier to learn how to develop for their product. It wouldn't be hard for them to do a high quality video tutorial, and yet it appears they've done just the bare minimum. I have some hope that TI may be better in this regard, but I haven't yet looked more closely to say for sure.

[monte]

@scalz said in Everything nRF52840:

Hmm, I haven't.. so what's more? Has MySensors been forked to another platform?

I mean people discuss all things here on forum that are in common interest including 3d printers, CNC's and work place arrangement. No wonder they will discuss other wireless protocols and platforms as well.

@scalz said in Everything nRF52840:

Lot of "noobs" don't know what means a rf stack exactly, what logics inside etc, they simply want to use MySensors because it's easy to use, especially when non former dev. That's what would expect someone discovering nrf52840 is supported in MySensors. So this gets completely confusing, external toolchains and using others rf stacks etc.. might end in hundreds of posts with just a few mysensors relevant infos (good luck for newcomers)

Those newcomers will just pass by these threads and find the answer on their topic. And then when they will learn (as many of us did thanks to this forum) they will come back to threads like this and get useful information for their further education. And those noobs, you mentioned who just wants to make "smart socket" or humidity sensor probably won't even come to the forum section as they have plenty information in tutorials on the main page. Why do you consider newcomers so dumb?

[NeverDie]

Guys, let's move on from this tempest in a teapot. The way I see it: at this point in history what we individually want or don't want won't make any difference to the ultimate outcome in the big picture, because there are now much larger forces at work. Our best bet is to help each other identify the best trend to ride. If that's mysensors, then great, but if not, let's try to figure out just exactly what else might reasonably win so that we can avoid dead-ends and hopefully ride the trends with the wind at our backs.

To my mind, the following have traction (in no particular order)

1. LoRa (because it's simple and it just plain works)
2. Bluetooth 5 Long Range (because smart phones, eventually, will make it so) with an integrated ARM MCU. That said, bluetooth per se has always seemed cumbersome to me, and I never really liked it. I'd probably be happier using a barebones version of it.
3. MQTT

Maybe Thread will happen or maybe it won't. I'm not sure what will catalyze it, so I'd have to see meaningful uptake before I bet on Thread.

[heinzv]

@neverdie I have no problem with this discussion (actually I like it :-). We're just lookig for an alternative to the "aged" and "limited" Atmega 328p platform. And at the end, I can/should also benefit for the MySesnors project/community.
At least, I'll do it anyway but having some other experts opinins is always helpful.

I have taken a look at the TI CC1352P which supports multiprotocols UHF (868) and BLE 5 (ZigBee, Threads etc.). It has similar features as the nRF52.
Has less Flash/RAM but still sufficient.

So still to investigate BLE 5/ZigBee long range or LoRa + MQTT and Nordic nRF52 or TI CCxxx

[NeverDie]

@heinzv said in Everything nRF52840:

I have taken a look at the TI CC1352P which supports multiprotocols UHF (868) and BLE 5 (ZigBee, Threads etc.). It has similar features as the nRF52.

Wow, almost everything but the kitchen sink!

The CC1352P device is a multiprotocol Sub-1 and 2.4-GHz wireless MCU targeting Wireless M-Bus, IEEE 802.15.4g, IPv6-enabled smart objects (6LoWPAN), Thread, Zigbee, KNX RF, Wi-SUN, Bluetooth 5 low energy, and proprietary systems. The device contains a +20-dBm integrated high-power amplifier with best-in-class efficiency for long-range applications.
http://www.ti.com/product/CC1352P/description

Impressive. What will TI make next? A software defined radio?

[scalz]

@NeverDie that's what I'm going to use for my ha. I have TI launchpad and sensortag for testing, already played a bit with previous cc1350 and their framework. I have designed a few different cc1352x rf modules (shielded), childboard for sensors, pcb or ceramic antennas footprints for nodes etc..I'm just waiting to receive pcbs, vna and I'll tune. when enclosed too. for compliance. Lot of fun coming

[NeverDie]

Interesting! I watched this video and learned that it lets you do both Bluetooth and sub-gigahertz simultaneously.
Connect: Dynamic Multi-Protocol Demo – 05:48
— Texas Instruments

I like it.

[heinzv]

@scalz So that was a good hint It would be nice if you would share your PCB's and and where you ordered it and I hope also your code! I have not yet seen many boards (good layout and price) with the CC1352P/R but maybe you can help us here?
Of course I mean beside the TI Lunchpad for develoment.

@NeverDie what do you think? Finally we might come closer

[NeverDie]

@heinzv said in Everything nRF52840:

what do you think?

I've pretty much said what's on my mind. I just want to make sure I'm taking the easiest/fastest path possible for getting projects done. IMHO, Nordic would benefit from a more friendly API (more like Arduino or MBED). Nordic's code is largely undocumented in-line. Instead, virtually all the documentation is in Wiki's or the datasheet. It's just not geared toward quick learning, although once you learn something it does seem easy in retrospect.

Therefore, I think TI is worth a closer look. If TI is easier than SES/Nordic, or at least has better learning materials, then I'd probably switch to TI, even though I would sorely miss Nordic's Programmable Peripheral Interface (PPI). As far as I know, PPI is not a part of ARM, and only Nordic has a it (?).

Also, having a wireless bootloader that works and is easy to use would be a real bonus. I'd much prefer to wirelessly upload sketches. Does TI have that? Anyone know?

[heinzv]

@NeverDie got it. I'll also try both and decide then. Maybe scalz can help us to come to a decison as he tried both and might share some sketches/code or give us some hints.

[NeverDie]

@neverdie said in Everything nRF52840:

Also, having a wireless bootloader that works and is easy to use would be a real bonus. I'd much prefer to wirelessly upload sketches. Does TI have that?

Answering my own question, it would appear the answer is yes:

Supports Over-the-Air Upgrade (OTA)
http://www.ti.com/product/CC1352P/description

and it appears to be true for the CC2642R2 launchpad also:
http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_30_00_25/docs/blestack/ble_sw_dev_guide/html/oad/oad.html

[heinzv]

@neverdie I have ordered the Launchpad LAUNCHXL-CC1352P1 from Mouser.at and registered at TI and downloaded all SDK's and the IDE(s).
Now I need plenty of time to test my nRF52832, nRF52840 (breakout/USB dongles) as well as the TI CC1352P ...

[NeverDie]

@heinzv That's great. Maybe we can learn together.

I like Mouser, although here it may in this instance be less expensive to order from TI directly.

The main downside at the moment is that both the CC1352P and the CC2640 are so new that there are not as yet any inexpensive modules to use on projects, and I doubt I would be good at DIY reflowing these chips onto PCBs. So, I'm not sure what to do about that. Anyone have any ideas?

[NeverDie]

@heinzv said in Everything nRF52840:

@neverdie I have ordered the Launchpad LAUNCHXL-CC1352P1 from Mouser.at and registered at TI and downloaded all SDK's and the IDE(s).
Now I need plenty of time to test my nRF52832, nRF52840 (breakout/USB dongles) as well as the TI CC1352P ...

To kick start your development, we offer two LaunchPads with optimized external RF components, one for Sub-1GHz PA and another for 2.4GHz PA wireless operations:

LAUNCHXL-CC1352P1:

Sub-1 GHz operation at 868 MHz / 915 MHz up to 20 dBm

2.4 GHz operation up to 5 dBm

Get started with the out of box experience > (dev.ti.com/launchxl-cc1352p1)

LAUNCHXL-CC1352P-2:

Sub-1 GHz operation at 868 MHz / 915 MHz up to +14 dBm

2.4 GHz operation up to +18 dBm*

Argh. Why, oh why, didn't TI make a launchpad with a PA on both the sub-1ghz and the 2.4ghz?

I wonder which radio gets used for the OTA firmware upload?

[heinzv]

@neverdie I have seen that only the P1 version was "unavailable" directly @TI. And yes they have different signal strength on 1GHz and >2,4GHz. I found that also strange.
I wanted to order @TI directly but it looks like you have to be a company or a school and they enforce you to provide a valid URL (you could fake that but I'm not sure if they would ship then).
However buying it at Mouser in Austria is faster and you don't pay shipping cost (above 50€) and don't have to take cate about tax as Mouser has an Austrian order address . The Launchpad cost about 50€.

Regarding the non dev modules: That is what I mentioned to @scalz that I have not yet seen cheap modules, but he said that he made some PCB's for the MCU as well as sensor add-ons and they are on the way, so I hope he will share the PCB files with us or we can order them via his page.
I have a SMD hot air soldering station and solder paste. So I have no fear to solder the MCU But of course having ready soldered bare modules which work out of the box and less or around than 10€/US$ would be preferred.

[scalz]

@neverdie said in Everything nRF52840:

Argh. Why, oh why, didn't TI make a launchpad with a PA on both the sub-1ghz and the 2.4ghz?

because it's a very new mcu, and they have some work in progress regarding PA paths. (from what I read). So I think they wanted to quickly provide a few usable&different launchpad designs for customers.

Like I said above (but it's in nrf52840 thread arghh), I designed my own shielded modules that I'll tune regarding an ideal gnd plane. I'll test a few antennas (still have a few favorites, but there are some nice chip antennas I would like to test too). And I'll also tune it regarding a sensor daughter board I made, and again check once it's enclosed too. Once that's done I'll provide some comparison, infos, with tuning results (smith charts, vswr etc), tips and help if I can for assembly or to get my modules (PM, or tindie etc, I have a reflow oven to help me, and at my job we're talking about pick&place in shortterm future, not for iot, but handy for extra projects) but 1st step 1st
Still for the moment, as some others new mcus (with erratas), it's not arduino.. but TI mcus are close as it's possible to use, with some limitations, Energia/Arduino project (and sketches are import-able to TI ide).
Our plan (another team member might be interested, he played with cc135x too) is to use MySensors lib (or a part). The main reason : MySensors API is compatible with lot of controllers.

[Nca78]

@scalz said in Everything nRF52840:

Our plan (another team member might be interested, he played with cc135x too) is to use MySensors lib (or a part). The main reason : MySensors API is compatible with lot of controllers.

Yes that's the big advantage of MySensors, having something you can use on many controllers. So even if the RF stack/network is completely different it's still nice to have a gateway that pretends to be a MySensors gateway to the controller.

[NeverDie]

@heinzv (or anybody) Do you happen to know what the Tx power and Rx sensitivity is on the bluetooth that's in the Samsung Galaxy S8? I'm guessing that it's relatively weak, in which case I suppose launchpad P1 might make more sense than P2.

[NeverDie]

It seems that Nordic just hasn't developed easy to use abstraction layer for Bluetooth 5. The question is: has TI? I guess maybe before ordering the launchpad, I should download TI's software and have a look.

Also, is it better to have a single awesome radio that does everything at 2.4Ghz or two humdrum radios, one with great range at sub 1ghz and the other with limited range at 2.4ghz? The two radio solution will always have a higher hardware cost and a bigger footprint, so getting cheap modules might (?) be difficult even down the road. I just don't know.

Thoughts?

[heinzv]

@neverdie I have not found any hint on BLE Rx Tx sensitivity (Rx) or signal strength (Tx), but I assume that it's not that high as after a few meters the device connections are lost (SmatGear S3), Headphone etc. I would say less than 10m.

My TI CC1352P1 is ordered and I guess it will arrive by end of the week. Meanwhile the Nordic USB dongles are also on the way, so I'll start with the nRF52840 latest at the next weekend and I assume I will have the first experience with the Nordic MCU's.

Regarding the TI MCU: Although in the advertisment video it was explained why you would have two radios at the same time on the same chip, but I rather see it as a possibility to use one or the other best fitting the usage it is built for without attaching another modul. But I'll wait for the first set of real live tests under different conditions (for both nRF52 and TI CC1352). And also how convinient the IDE's and libraries can be used.

Looking at the TI homepage, the CC1352(p) is not even yet available but announved for Q3/2018 which should be now or soon. Thene I hope we can get first modules. I wonder where @scalz will get the MCU's (even the raw chip's)?

[NeverDie]

I've thought it through.

Presently the nRF52840 and all the TI Bluetooth 5 launchpads have a receive sensitivity of -103 at 2.4Ghz. None of them are using an LNA at this time.

I think my interest in these chips is mostly tied to doing very power efficient remote control wakeups, which I previously proved I could do using the PPI on an nRF52832. I used the PPI to wake up every 100ms and check for received packets without waking up the mcu, thereby saving power. I could do the same thing with the nRF52840, but with the advantage of its greater receive sensitivity. I'm not sure that TI has anything equivalent to PPI, but even if it did, it would have no advantages for this use case.

For everything else, I'm happy using LoRa modules, because their range/coverage are just fantastic, and at around $3 the Ra-01 LoRa modules are very inexpensive.

Meanwhile, I'll track developments at TI and see what becomes available. It looks like TI is doing good work.

[scalz]

@NeverDie they have sort of equivalent for processing IOs, sensors, i2c etc without waking up the mcu. it's called Sensor Controller (accessible by code or they also provide a small ide for it).
about LORA I've never been really interested in it, I prefer to have my own "micro" network than being a part of a larger network. I would also prefer narrowband.
Sure if you use LORA nodes, maybe narrowband is maybe not the best bet for you. in some cases, widespectrum LORA can have range issues, not heard, when narrowband is used (they made a video+appnote about coexistence)
My need is subghz for long range reliable delivery + BLE for shorter range stuff.., using one broadband antenna or two differents of any kind, to be able to use a module or a bare ic (sometimes a module doesn't fit well in design regarding placement of the module or the antenna orientation&keepout area, so with two modules it's "worse"), and I've been very disappointed to see Nordic changed its mcu footprint (needs premium pcb, and more soldering care). That's why TI picked my curiosity (it ticked all my checkboxes, all in one).
But you're right if you feel more confortable with nrf, it's nice mcus too. Both needs some work anyway (one mcu needs BLE/MySensors, the other needs to get its dualmode compatible with MySensors messages&serial api)

[NeverDie]

@scalz I found this: https://training.ti.com/simplelink-academy-introduction-sensor-controller , which says:

Also, the sensor controller has not any direct interface to the radio or system flash.

[scalz]

@NeverDie yes. SC is also accessible from app, it can be independant. If goal would be for sort of lowpower listenmode, there are code examples too, not the goal of SC, sure (no link with rf). I don't think I tried it, but will take a look once I've other stuff ok.
I guess, even if PPI doesn't wake up mcu, the task function with a timer still uses somes power.

Maybe you should keep on nrf if you feel more familiar with these. Truth is I have played too with it, but I stopped on my side, a while ago..and started to take a look at TI (so I could say I'm as familiar or maybe "more" with TI now,..). And perhaps, I already said it, but I'm not interested to pay 12$ for bt840f (limited accessible IOs), or less money but with 840 ceramic antenna. When for the same price I can assemble myself a dualband mcu and pick antennas I need. Like people says, pick what fits best your needs (and the application)

[heinzv]

@scalz regarding LoRA (RFM95), I think you might confuse LoRa with LoRaWAN. LoRa is a protocol and you can have your own "mico network" (so do I). It is the most efficient and easy to use 868MHz radio (in my opinion) and has long range and high energy efficiency and cost is low (a little bit more than RFM69).
The nRF52840 has a good amount of Flash/RAM (1MB/256kB) and good sleep current even keeping RTC and RAM up or even using radio Rx.

But the TI MCU's like the CC1352P is certainly a very interesting new candidate and it look very very promising with it's BLE 5.0, ZigBee AND 868MHz radio. And I like the SC coprocessor. No doubt that look very attractive. Thus I ordered the CC1352P1 Lunchpad. But that seem to be the only available option to get this MCU and this is for learning purposes only.
When I look at the TI product page it says Status: PREVIEW, no stock: http://www.ti.com/product/CC1352P/samplebuy
I have also seen anounced prices with 10 US$ for the chip itself.
Not sure when it will be really available, get a reasonable price and modules offered (such as for any other MCU's like nRF52).
Same story for the CC2652R, also in PREVIEW.
If you have sources or even PCB's (designed by you) for this MCU's, I would be eager to order and test it.

[scalz]

@heinzv
yes you're right about lora, and that they're using some juice too (they can even be compatible with a rfm69 when you take a look at the datasheet. TI's too though).
I know about nrf52840 power modes, I just replied about PPI feature (depending what you implement, it can't be completely free).
About Ti mcus, they are new and available at their store only. about sharing my work.. when I'll get time. for the moment I'm very busy (with my job too). In the meantime, you still can play with their devboard and try their courses, or energia.

[heinzv]

@scalz and @NeverDie today I got my nRF52840 dongles (6 pieces) as well as the TI CC1352P1 launchpad. Now the fun will begin (latest at the weekend)
See the picture below (the dongle in blue and the launchpad in red).
If you have already some more code to share for testing (send/receive, I2C sensor read etc.) please post it (some code was postetd by NeverDie) other wise I'm looking at the Nordic pages, they provide a lot of examples (I will probably use/try Segger).
For the TI part, I only have one launchpad, so I have to verify, if I can use BLE 5.0 to communicate with my mobile or between TI CC1352 and nRF52 ...
Not sure if the TI can also communicate with the CC1101 at 868MHz (using the Sub 1GHz capabilities) using the same modem settings. So a lot to find out.

[NeverDie]

@heinzv Please do keep us posted with your impressions as you develop them.

I found out that Nordic does have OTA firmware updates, though it looks rather laborioius to set up: https://devzone.nordicsemi.com/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader

Maybe it's easier with TI (?).

[heinzv]

@NeverDie okay, a very first testing yesterday late-night when setting up the Segger / nRF52(840) tool chain and a very quick dongle testing
I used the nRFconnect and uploaded all 5 demo/test applications which worked. No big achievement but just a very basic testing (maybe not even worth to mention)
Here is the result of the BLE app test: I did the BLE scan with the dongle and it found some devices around such as the BLE WiT power plug with the energy meter. Thene I did the oposite and installed the nRF connect on the Android Galaxy S8 phone and scanned for the nRF dongle.
Attached the two results (one from the dongle and one from the mobile phone)
As you see the Galaxy S8 finds all BLE WiT smart plugs in the flat (also the ones which are in other rooms) while the nRF dongle sees only the one which is close in the same room.
I would assume, that the Galaxy S8 has a much better BLE antenna than the dongle (which has almost no antenna), but what I interpret the RSSI, the dongle reports a better signal strength of the WiT powermeter in the room?!

Today I received also the breakout PCB's for the nRF52832, thus I'll probably try to do a sender/receiver test with them using one as mySensors Gateway and one as mySensors Node (both in nRF24 mode). Not sure if the compile/build will work, because I have to also provide the proper pin-map (as the E73 module is not mapped in the Arduino IDE).

[NeverDie]

@heinzv Regarding, the dongle, its antenna seems to be highly directional, so that may play a factor in what you are observing.

[NeverDie]

Found these relatively inexpensive TI modules:
https://www.ebay.com/itm/REYAX-RYB080I-BT-4-2-5-0-Bluetooth-module-BLE-TI-CC2640R2F-Antenna-AT-Command/183413364598?hash=item2ab449d776:g:dOEAAOSwOZtbRu7A

that presumably are compatible, at some level, with ti's cc2640R2F launchpad

Also, I found the info on how to do the OAD (over the air download): http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_30_00_25/docs/blestack/ble_sw_dev_guide/html/oad/oad.html

Regarding the Nordic gear, I'm hoping that micropython, if installed, might prove to be easiest for OTA updates, since, in theory, a micropython app should be able to update itself through its inherent REPL process. It turns out that maybe because of the BBC micro bit, micropython runs on the nRF51. In general, though, it seems like the ESP8266 has a lot more micropython support.

[heinzv]

@NeverDie I'm still at the basics (where you have been probably one year ago). I have now soldered my nRF52832 modules (the E73...B from EBYTE) to the breakout boards and tried to find the best way to program and flash them.
I started with Segger Studio and with ST-Link upgraded to Black Magic Probe but as far as I have understood it supports only their own J-Link HW for flashing (at least the J-Link EDU is required). I also converted a ST-Link Dongle to a J-Link dongle but that can only flash STM MCU's (license restrictions).

I have then tried to use Aruino Studio with all 3 dongle types (Black Magic, J-Link and ST-Link). I was only successful by using ST-Link. It does flashes the sketches and it runs (just used a simple blink example for flash testing).
But using the ST-Link (V2), there is no serial devices and thus no Serial Windows for log output (Serial.println()).
I've also tried to use the Black Magics with the GDB but it did not work either and I found it also not convinient with the commandline.

So what are you using for flashing with Arduino Studio (with it's limited nRF52 support) and flashing with Segger Studio an what are you using for debugging and logging (print lines to output/serial ...)?

[nagelc]

@heinzv For the NRF52832, try using the MySensors MyBoardNRF5 board type. In MyBoardNRF5.h, there is a section for the serial interface. Set PIN_SERIAL_TX to the pin you want to get serial output from. Set PIN_Serial_RX to some unused pin. It isn't used anyway. (A tip I got from @NeverDie).
I like the Black Magic Probe because it has both the SWD and Serial in one device, but you could program with the ST-Link and listen to Serial with an FTDI. I hear J-Link is the best, but have not used it. Might try it now that I know there is an educational version.

[NeverDie]

@heinzv I use the Nordic development kit for flashing. At least for me, it's the easiest.

[Nca78]

@neverdie said in Everything nRF52840:

@heinzv I use the Nordic development kit for flashing. At least for me, it's the easiest.

Same here. NFR52 DK, works perfectly with Segger ES and I just do drag & drop of the compiled file to the virtual drive of the DK when using Arduino.

[heinzv]

@neverdie and @Nca78 thanks for the quick response, I have ordered the nRF52840 DK from Nordic (via Mouser). That works with Segger and also with Arduino Studio too (for the simple and existing 52832 projects like mySensors)?
And fo the Arduino Studio (or VS Code) is there a serial terminal for debug output too?
How to you flash then the bare nRF52 modules which have only the SWD interface (I have plenty of them)?

@nagelc I have again tried my Black Magic Probe Dongle with Arduino IDE, but it does not yet work for me (maybe I still have not understood it). In Arduino Studio I have tge GDB serial port but neither the upload works properly nor I have understood how to use it with the GDB debug window.

I attach the devices (Windows 10) and the output from Arduino IDE. Maybe you can give me further hints:

I used a simple blink sketch which works with ST-LInk V2 upload but not with BMP. Here is the output from the upload:

Sketch uses 3600 bytes (0%) of program storage space. Maximum is 409600 bytes.
Target voltage: unknown
Remote debugging using \.\COM58
Available Targets:
No. Att Driver
1 Nordic nRF52
2 Nordic nRF52 Access Port
Attaching to Remote target
0x00000ad0 in ?? ()
Reading symbols from nRF52832_Blink.ino.elf...done.
Loading section .text, size 0xe10 lma 0x1c000
Loading section .ARM.exidx, size 0x8 lma 0x1ce10
Loading section .data, size 0x74 lma 0x1ce18
Start address 0x1c5fc, load size 3724
Transfer rate: 26 KB/sec, 620 bytes/write.
Temporary breakpoint 1 at 0x1cb4c: file D:\mcdev\arduino\portable\packages\sandeepmistry\hardware\nRF5\0.6.0\cores\nRF5\main.cpp, line 28.
Starting program: C:\Users\internet\AppData\Local\Temp\arduino_build_189520\nRF52832_Blink.ino.elf
Note: automatically using hardware breakpoints for read-only addresses.
An error occurred while uploading the sketch

[NeverDie]

@heinzv I haven't ever used BMP, but I'm guessing that maybe you need to bulk erase your target device first. That would remove any read-only protection. If so, you only need to do it once. After that, it should upload OK.

[heinzv]

@neverdie I can do upload with the standard ST-Link V2 Dongle on the same bare E73 module but for the BMP it is read-only?
How do you flash the bare modules (not the DK)?

[NeverDie]

@heinzv said in Everything nRF52840:

@neverdie I can do upload with the standard ST-Link V2 Dongle on the same bare E73 module but for the BMP it is read-only?
How do you flash the bare modules (not the DK)?

Not sure I understand your question. I can flash bare modules using the DK. I'll let others comment how they do it without using the DK, as that's about all I know. One final tip though: Generally it's important to power your target module independently of whatever programmer you're using. For instance, on the DK, it will detect the voltage level on the target and adjust accordingly, but it isn't meant to power the target.

[heinzv]

@neverdie To my first statement: I was just wondering why I can upload sketches with teh ST-Link V2 dongle (but no serial output/debug windows) but the BMP might face read-only protection (I thin kthe upload script should have some kind of mass erase before upload)?
Regarding my question: I think I you understood my question right and I also read the nRF DK features and it says it features a SEGGER J-Link OB Debugger with debug out functionality. So I guess it's a flasher/debugger not only for it's on-board nRF52840 MCU but also for external nRF modules connected to the DK right?

Are you're also using the DK with the Arduino IDE (though with restrictions like no full nRF52840 support) and the mySensors project?

Meanwhile I'm exploring the nRF52840 USB dongles. And maybe I'll get along with the BMP modules and understand how the work with the Arduino IDE (so far I spent many hours with Google und no success).

[alowhum]

The easiest way to get started with NRF5 might actually be the BBC Micro:bit

[NeverDie]

@heinzv said in Everything nRF52840:

Regarding my question: I think I you understood my question right and I also read the nRF DK features and it says it features a SEGGER J-Link OB Debugger with debug out functionality. So I guess it's a flasher/debugger not only for it's on-board nRF52840 MCU but also for external nRF modules connected to the DK right?

Right.

Are you're also using the DK with the Arduino IDE (though with restrictions like no full nRF52840 support) and the mySensors project?

Not presently. I made a weak attempt recently but something is broken (probably on my end) to where I couldn't get it to compile anymore, whereas previously I could. So, I decided to see what else was available, which led me to mbed, and then now to SES, which has no trouble compiling. As long as I can directly manipulate the nRF52 registers and have access to serial output for debugging, I can do pretty much do whatever I need to do.

[NeverDie]

@alowhum said in Everything nRF52840:

The easiest way to get started with NRF5 might actually be the BBC Micro:bit

Yes! From what I can tell, a lot of development work has gone into the micro bit to make it easily programmable using any of a handful of different languages including C, C++, and micropython. Apparently it's somehow possible to do a hybrid of C and micropython, where the time sensitive parts can be written in C/C++ and the rest in micropython. Not sure how that works exactly, but it sounds interesting.

Originally I thought the BBC micro bit was purely a toy, but when I saw it could scroll text across its 5x5 matrix of LED's I realized that it could be more than that. Very clever!

You can also program the microbit using the Arduino IDE:
https://learn.adafruit.com/use-micro-bit-with-arduino

My hope is that somewhere there's an easy-to-use way to:

1. Do OTA updates.
2. Interface with bluetooth.

It seems there may be a way to OTA update the micro bit, probably from a bluetooth phone:
https://phwallen.github.io/microbit-swift/

What I'd prefer, obviously, is doing the OTA update from a computer (maybe using a dongle of some kind?) If that were possible, then nRF51 modules are so cheap you could imagine putting them in almost anything, even if it's to control a different kind of radio.

https://www.aliexpress.com/item/nRF51822-04-BLE-4-0-Mini-AT-Command-WIFI-Wireless-Bluetooth-Module-TTL-Slave-Low-Power/32840163615.html?spm=2114.search0104.3.1.12f72932SZIor6&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_10130_10547_10546_10059_10884_10548_315_10545_10887_10696_100031_10084_531_10083_10103_10618_10307_449,searchweb201603_60,ppcSwitch_0&algo_expid=1b57e3dd-d427-4abc-81b4-4ecb74b14cbd-0&algo_pvid=1b57e3dd-d427-4abc-81b4-4ecb74b14cbd&transAbTest=ae803_4&priceBeautifyAB=0

[nagelc]

@heinzv I'm running a different sketch, but I get almost the same output as you except at the end: instead of "An error occured . . .":

Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main ()
    at D:\carln\Documents\Arduino\libraries\MySensors/hal/architecture/NRF5/MyMainNRF5.cpp:23
23	{

Program complete!

There are a couple of differences.
" Sketch uses 17856 bytes (3%) of program storage space. Maximum is 524288 bytes."
Not sure why my maximum storage space would be higher than yours.
"Start address 0x2fa0, load size 18080"
Different sketch, so I would not expect the load size to match, but not sure why the Start address would be different.

On the Arduino Tools tab, are you selecting Bootloader/SD: None?

[heinzv]

@nagelc Thanks for your response and trying to get me further.
I'm trying to get you as much infos as possible:
I made a couple of screenshots and picture of my environment. Maybe that helps to trace down to the problem.
I followed exactly the instructions from sanseeps Arduino/nRF5 configuration/installation.
Uploading the bkink example with the ST-Link V2 works, but there is no serial print, no debug, thus I'm trying the BMP way.

Here some setttings from my Arduino IDE (Tools section)

Here are my different BMP modules I have used

and the COM devices in Win 10

I have tried all kind of driver (using Zadik 2.4), but WInUSB, lisbusbK, libusb ... they all create USB devices only but no COM devices, which Arduino IDE does not "like") only the usbser driver gives me COM devices

and the target device I'm using (which works, when I load the sketch with the ST-Link and select ST-Link in Arduino IDE)

[heinzv]

@neverdie good discussion, but in order to get my desired solution which is sensor nodes with E-Paper and working with OpenHAB I need I either get the nRF52 modules running with mySensors (ideally just using the Arduino porject and IDE) using the nRF option (I think there is some initial nRF5 support) and using the older nRF24 protocol, or using LoRa with an RFM95 module (which is also supported) or I switch completly to Segger and make a ZigBee V3.0 solution (requiring a ZigBee gateway for OpenHAB). With my new Philips Hue HW version and the new SW firmware upgrade. It is claiming to support ZigBee V3.0 devices which includes also Temp/Hum sensors.

I'm also looking forward for the solution from berkseo where he does exactly that with and nRF52, but that seem to take some time to make it available.
https://www.openhardware.io/view/629/Temperature-and-humidity-sensorverNRF52832E-Ink-display#tabs-instructions

[NeverDie]

@heinzv Fair enough.

Probably soon I'll take a crack at doing an OTA DFU with an nRF52840. The good news is that Nordic is reasonably responsive to questions with about a 24 hour turnaround, so that means any sticking points should be resolvable. Failing that I may try writing my own basic OTA uploader.

[nagelc]

@heinzv For Softdevice, pick None. MySensors doesn't use the Softdevices and I don't think you want it for Generic NRF52 either.
The Low Frequency Clock depends on your board. If it has an external crystal outside the NRF 52, use Crystal Oscillator. Otherwise pick RC Oscillator to use the internal oscillator.
Your BMP ports look correct. In your setup, 58 for the programmer. Use the UART port , 51, to listen to serial debug.
The Black Magic Firmware Upgrade is for use with DFU Util to upgrade the firmware on the probe. I'm not sure what the Trace Capture is.

[heinzv]

@nagelc I have tested both w/ and w/o softdevice, it doesnt make a difference but yes I'll remove it again.
My boards (the E73 module) have an external 32kHz crystal osci for RTC.
In Arduino, you can only select one port. If COM58 is set (for the programmer) then it would open the serial monitor also on that port. However I have tried to use port 51 with another terminal (putty) and it does not connect (I've tried with different baud rates).
I'm not sure but I think (and read) that the second port is only for the SW update of the BMP and not for debugging. Debugging is most likely also on port 58 but for the GDB and not for Arduino, but if it is used (initiated) via Arduino, I could not connect to GDB with a command terminal, so I think the programm has to be started with the command windows and GDB. I've also tested that from that direction and was also not succesfull (I spnt many hours with Google and BMP docu and GDB).
I also don't know how to use the non COM (USB only) devices like the "Trace Capture" as thery are not visible/offered in Arduiono IDE.

You're using BMP with Arduino IDE? How are you doing the serial output?
How can you used two different ports in Arduino (there is only one port setting)?

[nagelc]

@heinzv Yes. I'm using with Arduino IDE, but I connect a terminal program (TerraTerm) to the UART com port. You need to do more setup to get the serial out from NRF52832. The easiest way is to use the MyBoardNRF5 board type to select a pin to be TX. But that is a bit much for a blink sketch.
There is yet another usb driver for the Trace and Firmware Update ports. I forget how that is loaded (zadig I think), but you can safely ignore it.
Seems like your setup should just work uploading the sketch on your COM58.

For the GDB connection. There is a syntax difference for ports higher than 9. Try this. I had it in my notes, but haven't tried it since my ports are less than 9.

"target extended-remote \.\com58"

[heinzv]

@nagelc So everything works now with the BMP using the MyBoardNRF5. At least it supports the nRF52832 (if I'm lucky also the nRF52840) but I started with my barebone 832 modules.
So it upload the sketch and it does also reset and start.
I could also do the connection to the second serial port now with Terra Term and get the Serial.println. Cool.
The secret was, that I created another BMP for my blackpills (I did a couple of tweaks) and connect now the HW serial of the nRF52 to the BMP serial (UART2) and it forwards it via the USB of the BMP to the COM port.

The output looks now like yours when I do an upload:
WARNING: Spurious .ci folder in 'MySensors' library
WARNING: Spurious .mystools folder in 'MySensors' library
Build options changed, rebuilding all
Sketch uses 3720 bytes (0%) of program storage space. Maximum is 524288 bytes.
Remote debugging using \.\COM58
Target voltage: unknown
Available Targets:
No. Att Driver
1 Nordic nRF52
2 Nordic nRF52 Access Port
Attaching to Remote target
0x00000ae0 in ?? ()
Reading symbols from nRF52832_Blink.ino.elf...done.
Loading section .text, size 0xe88 lma 0x0
Loading section .ARM.exidx, size 0x8 lma 0xe88
Loading section .data, size 0x74 lma 0xe90
Start address 0x5f8, load size 3844
Transfer rate: 27 KB/sec, 640 bytes/write.
Temporary breakpoint 1 at 0xbc4: file D:\mcdev\arduino\portable\packages\sandeepmistry\hardware\nRF5\0.6.0\cores\nRF5\main.cpp, line 28.
Starting program: C:\Users\internet\AppData\Local\Temp\arduino_build_913185\nRF52832_Blink.ino.elf
Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main ()
at D:\mcdev\arduino\portable\packages\sandeepmistry\hardware\nRF5\0.6.0\cores\nRF5\main.cpp:28
28 {

Program complete!

Here is the picture of my BMP and the nRF module:

[heinzv]

My nRF52832 moduls with MySensors in nRF24 mode seem to work, I have to start another node acting als Gateway and see if they communicate and what distance can be reached in the nRF24 mode.

---

| / |_ / | ___ _ __ ___ ___ _ __ ___
| |/| | | | _ \ / _ \ _ \/ __|/ _ \| _/ __|
| | | | || || | / | | _ \ _ | | _
|| ||_, |/ ___|| ||/_/|| |/
|__/ 2.3.1-beta

24 MCO:BGN:INIT NODE,CP=RNNNN---,VER=2.3.1-beta
28 TSM:INIT
30 TSF:WUR:MS=0
31 TSM:INIT:TSP OK
33 TSM:FPAR
40 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2048 !TSM:FPAR:NO REPLY
2050 TSM:FPAR
2057 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4064 !TSM:FPAR:NO REPLY
4066 TSM:FPAR
4073 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6081 !TSM:FPAR:NO REPLY
6083 TSM:FPAR
6090 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8098 !TSM:FPAR:FAIL
8099 TSM:FAIL:CNT=1
8101 TSM:FAIL:DIS
8103 TSF:TDI:TPD
18105 TSM:FAIL:RE-INIT
18107 TSM:INIT
18108 TSM:INIT:TSP OK
18110 TSM:FPAR
18117 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20125 !TSM:FPAR:NO REPLY
20127 TSM:FPAR
20134 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
22142 !TSM:FPAR:NO REPLY
22144 TSM:FPAR
22151 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
24159 !TSM:FPAR:NO REPLY
24161 TSM:FPAR
24168 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
26176 !TSM:FPAR:FAIL
26177 TSM:FAIL:CNT=2
26179 TSM:FAIL:DIS
26181 TSF:TDI:TPD

[NeverDie]

I built the micropython firmware for running on the nRF52840:

Here's the proof:

MicroPython v1.9.4-623-g34af10d2e on 2018-10-05; PCA10056 with NRF52840
Type "help()" for more information.
>>> 1+1
2
>>>

You can download it from here: https://forum.micropython.org/viewtopic.php?f=2&t=5348

[NeverDie]

So, the idea for doing OTA code updates is simple enough: you transmit each line of code and the target assembles it into a string. Then the target executes the string, which updates the code on the target. QED

Here's a notional example of what I mean:

>>> simpleCode="def j(x): return x**2"
>>> simpleCode
'def j(x): return x**2'
>>> exec(simpleCode)
>>> j(5)
25
>>>

You can use whatever radio transport you want, including Nordic's "proprietary radio" that we are all familiar with. There's no reliance on bluetooth or Nordic's DFU.

[heinzv]

@NeverDie great job! I'll definity try it on my holyiot bare modules, but I'm still fighting with the flashing via either the Nordic DK and/or ST-Link v2SO far I was not successfull (I only got it to run with Arduino IDE and BMP, but that is not usable in that case). DK seem not recognize my external nRF52840 and the ST-Link wants some address ranges so I'm trying to get it run with openocd, but that also returns errors. So I'm stuck and wasting many evenings/nights (with Google).

[NeverDie]

@heinzv Using the DK should be easy. If you want to post how you're wiring your connections to the target, maybe I could help you identify what mistake you are making. Or, if you prefer, you could post to the Nordic support forum, as they would be obligated to help since it's a Nordic product. Or, better yet, do both, because then you'll at least get the ball rolling with Nordic in case you have a defective DK (unlikely, but who knows).

[heinzv]

@NeverDie thanks for the hints/offer:
I have connected to the nRF52840 DK via the P20 connector
Here is the wiring setup

VDD---> VTG of P20 in DK board
SWDIO--> SWDIO of external board
SWDCLK-->SWDCLK of external Baord
GND DETECT--> GND of external Board
GND--> GND of external baord.

[NeverDie]

@heinzv How is it that you are powering the target?

[heinzv]

@neverdie I admit that I also powered the module via the DK because it takes less than 20mA. I used this connection description:
But I'll try to use a complete an external PS next time and see if it makes a difference.

[NeverDie]

@heinzv Nice picture. Hmmmm..... Seems like your wiring should work. Maybe try VDDnRF instead of VDD? I'm not sure what the difference is, but I think that may have been what I used most recently.

Are you dragging the hex file to the virtual drive on the PC to upload it to the target? If so, what exactly happens when you do? It should be as simple as that.

I'm using Windows 10. What about you? Not sure if the version of Windows has anything to do with it.

It appears that you are using the nRF52832 DK. Correct? What exactly is the target that you are trying to upload to?

One way or another we'll get this thing solved for you.

[heinzv]

@NeverDie thanks, appreciate your help as you are far ahead.
Here is my update: I have build 4 nRF52832 boards with the E73 EBYTE modules and two nRF52840 board with the tiny holyiot modules (see picts below).
It seems that by using the wiring shown in my last post, I can flash the 840 boards. I'll also try again one of the working 832 boards later (I'm in business trip the next few days).
But I have a couple of questions to you:
1.) I don't know how to identify which MCU will be flashed. I only see the J-Link adapter in Segger or the board with the Segger Serial in nRFgo Studio. How can I know, that I'm not flashing the DK onboard MCU? Where is this shown, indicated where the flashing will go? That is strange to me. Another example is my sel build Black Magic Probe: It shows which devices are connected to it and you can select one (if multiple are shown in a select - select target 1,2 ...)
2.) How can I make use of any bootloader (DFU, Serial, USB, OTA, ANT etc.) so that flashing with the DK is not always required? I have not found a good way so far to flash any useful bootloader (I have tried some of the examples). The onyl one which creates a serial devices is the example for the PCA100059 (the USB dongle) which shows a serial device: nRF52 SDFU USB (COM75). HOw to make use of that (I have tried all of the offered programmer als oin Arduino IDE but could not upload/flash my blink sketch)
3.) How to you flash the USB dongle beside using the nRFconnect which requires the compiled image?
Are you also soldering the SWD pins and use them with the Segger and the DK?
4.) When I flashed your micropython (or circuitpython?) for the 840 (my board). How to I connect and use it? My 840 boards have it's own USB port (see topic 2, which shows the nRF52 SDFU port when I flash the one bootloader). When I flash the MP, the ports are gone (how to connect via USB, Serial, Terminal etc.)?

I've also tried a couple of other things like a DFU bootloader with a S140 softdevice (as it was recommended by Nordic) but was not sucessful to combine them (the S140 was flashed, but then?)

I have many more questions but I hope we can sort out some of the 1-4. I hope I have described them so that you can follow my thoughts and questions

nrf52840 on DK

nRF52832 on BMP

[NeverDie]

@heinzv said in Everything nRF52840:

@NeverDie thanks, appreciate your help as you are far ahead.
Here is my update: I have build 4 nRF52832 boards with the E73 EBYTE modules and two nRF52840 board with the tiny holyiot modules (see picts below).
It seems that by using the wiring shown in my last post, I can flash the 840 boards. I'll also try again one of the working 832 boards later (I'm in business trip the next few days).
But I have a couple of questions to you:
1.) I don't know how to identify which MCU will be flashed. I only see the J-Link adapter in Segger or the board with the Segger Serial in nRFgo Studio. How can I know, that I'm not flashing the DK onboard MCU? Where is this shown, indicated where the flashing will go? That is strange to me. Another example is my sel build Black Magic Probe: It shows which devices are connected to it and you can select one (if multiple are shown in a select - select target 1,2 ...)

If it's wired corectly, then only the external board gets flashed.

2.) How can I make use of any bootloader (DFU, Serial, USB, OTA, ANT etc.) so that flashing with the DK is not always required? I have not found a good way so far to flash any useful bootloader (I have tried some of the examples). The onyl one which creates a serial devices is the example for the PCA100059 (the USB dongle) which shows a serial device: nRF52 SDFU USB (COM75). HOw to make use of that (I have tried all of the offered programmer als oin Arduino IDE but could not upload/flash my blink sketch)

I don't know.

3.) How to you flash the USB dongle beside using the nRFconnect which requires the compiled image?
Are you also soldering the SWD pins and use them with the Segger and the DK?

Yes.

4.) When I flashed your micropython (or circuitpython?) for the 840 (my board). How to I connect and use it? My 840 boards have it's own USB port (see topic 2, which shows the nRF52 SDFU port when I flash the one bootloader). When I flash the MP, the ports are gone (how to connect via USB, Serial, Terminal etc.)?

So far I've only flashed MP to the 832 and 840 DK's. In those instances, you can do serial IO over the USB connection using putty or similar terminal.

I've also tried a couple of other things like a DFU bootloader with a S140 softdevice (as it was recommended by Nordic) but was not sucessful to combine them (the S140 was flashed, but then?)

I have many more questions but I hope we can sort out some of the 1-4. I hope I have described them so that you can follow my thoughts and questions

[cascade]

Howdy y'all first off thanks @NeverDie for this thread, I spent a good time lurking at these NRF52 posts and learned and re-learned a few things here and there.

I've built an E73 NRF52832 PCB and successfully did a blink using Espruino and Adafruit's Bluefruit FW for Arduino and just noticed the $10 CAD E73-2G4M08S1C (NRF52840) back in-stock (as of October 8). I am in the process of designing a pcb board layout for it but in the meantime thought that the community might find the following useful if you plan on designing/using these modules:

1. E73-2G4M08S1C and other footprints in the same 'family' are readily available in Altium Designer format here: http://www.cdebyte.com/en/data-download.aspx?id=356&pid=202

2. Library.io allows you to convert '.pcblib' / altium files to an Eagle Library format, you just need to specify the Symbol and Package, from here you can convert to KiCad or similar I'd reckon but have not used KiCad enough to verify this. This saved me a lot of time.

In case someone was wondering: I've had no issues using the J-Link Edu Mini with the NRF52832, will update here when I get to the NRF52840.

Just starting my own NRF journey and thought to add this here in case someone is looking for E73 module specifics WRT NRF52832/NRF52840 .

[Redferne]

Big thanks to @sandeepmistry, @lpercifield, @jeremypoulter and all others contributing to the NRF Arduino development effort. I have borrowed a lot and forked off another project for adding support for the NRF52840 dongle (PCA10059). If you are using PlatformIO and have access to a NRF52840 you can take it for a spin here PCA10059. I have tested UART, TWIM, SPIM and the BLE Led toggle example works.

[NeverDie]

@redferne Thanks for your post. How are you liking PlatformIO? Does PlatformIO have full support, with all the extra pin names etc., for the nRF52840?

[Redferne]

@NeverDie I never liked the Arduino IDE, so I think PlatformIO is next logical step, it is very easy to get going and it opens up for advanced usage. Your own choice of editor, has great debugging capabilities with VSCode integration.

If you build the PCA10059 example I linked you should have GPIO (digital) access to all 47 pins. I've made it simple in the pca10059 variant so that D0 (0) is p0.00 -> D47 (47) is p1.15.

Some external pins on the dongle which I have tested:
Serial pins RX->P1.10, TX->P1.13
I2C, TWIM, Wire on pins CLK->P0.29, SDA->P0.31
SPI here MISO->P0.13, MOSI->P0.15, CLK->P0.17, CS->P0.22

[heinzv]

@redferne thanks for your effort spent to support nRF52840 for VS Code/Platform.io. I'll certaily give it a try. The good thing with platform.io is that it's easier to use/import existing arduino (ino) projects than in e.g. Segger Studio which only supports licensed J-Link flash/debug adapters.

Two questions:
1.) Does your "port" support also the 15.2 SDK features of the 840 (Softdevice S140, BLE 5.0 long range, ZigBee, Thread ...)
2.) What flash method is supprted/used or you're using? Just plug the USB dongle in and it can be uploaded?

Oh, a third question: If I use bare nrf840 Modules, what flash adapter/mode would you recommend or have you tested (I have the 840 DK board, a ST-Link v2 and a Balc Magic Probe adapter)?

[NeverDie]

@nc78 Earlier you had asked about vendors for the dongle. I found an alternative dongle that ships from China:
https://www.tindie.com/products/Zelin/nrf52840-micro-dev-kit-usb-dongle/
Price is very similar. I like it better than the Nordic dongle, because it exposes pins P0.06 and P0.08, which are used by the DK for UART communications.

[Redferne]

@heinzv

1. It does use the S140 v6.1.0 Softdevice, however I have only "ported"/test the most basic SDK 15.2 BLE feature of @sandeepmistry BLEPheriphal BLEPeripheral. The example shows as BLEService and Read/Writeable BLECharCharacteristic used to toggling the onboard LED. I was hoping we could get more developers involved and "port" the missing pieces, if there's interrest. My main focus was just to get something Arduino-like running using PlatformIO build system on the cheap (~$10) NRF52840 dongle.

2. I have tested Black Magic Probe (Bluepill) and JLink Mini on the PCA10059 with great success. It also possible to use the nrfutil to create a dfu.zip. The Nordic Open DFU Bootloader (which is pre-flashed on PCA10059) allows easy programming without soldering, just plug-in USB.

First get and install the nrfutil from here

1. Linux environment example, first build the PCA10059 example project:

pio run -e ble

1. Generate a dfu.zip including the softdevice:

nrfutil pkg generate --hw-version 52 --debug-mode --sd-req 0x00 --sd-id 0xAE --application .pioenvs/ble/userfirmware.hex --softdevice ~/.platformio/packages/framework-arduinonordicnrf5/cores/nRF5/SDK/components/softdevice/s140/hex/s140_nrf52_6.1.0_softdevice.hex dfu.zip

1. Plugin the PCA10059 dongle in a USB port. Make sure that the Bootloader is executing by checking the RED led, should be "breathing". Else press the reset button. Now flash the new firmware, here the dongle was enumerated as ACM3.

nrfutil dfu usb-serial --package dfu.zip --port /dev/ttyACM3

... and Bob's your uncle

[Nca78]

@neverdie said in Everything nRF52840:

@nc78 Earlier you had asked about vendors for the dongle. I found an alternative dongle that ships from China:
https://www.tindie.com/products/Zelin/nrf52840-micro-dev-kit-usb-dongle/
Price is very similar. I like it better than the Nordic dongle, because it exposes pins P0.06 and P0.08, which are used by the DK for UART communications.

Thank you for the link, it looks like an interesting dongle. But after asking for a quote at Arrows and giving up (looked like a big mess to get items shipped here as it cannot be included in another order and they would only deliver in US), I realized that they now have them in stock.
So I bought 2 at 9.5$ each + 12% discount on the website, so less than 8.5$ each and as I bought other items (including BT840 modules) I have free express shipping too. Cheapest price + free express shipping, I think it's called "having it both ways" So I'll be able to join the little nrf52840 club next week.

[heinzv]

@redferne wow and thanks again for your fast and complte/detailed answer.
I like especially

• that you already started to use/support softdevices S140 and thus BLE 5.0, thread and Zigbee is "potentially" available
• that you also succesfully use Black Magic Probe, as I also wante to use it because it works in Arduino IDE and Platform.io and it supports also an UART Port to communicate (I also use Blue/Blackpill BMP's)

It would be great if it would be posssible (if not already) to use BLE 5.0 with the long range feature (that is not supported by the older S132 or nRF52832). Zigbee would be also great. But not sure what of the features (for a reliable longer indoor range) would be usable from within the MySensors project (beside using the nRF52 as/with the nRF24 proticol).

[Uhrheber]

One interesting thing I stumbled upon:

https://github.com/insane-adding-machines/unicore-mx

UniCore-MX | Universal Core for ARM Cortex-M0/0+/3/4/7/X

Supports nRF51/52

[mtiutiu]

This post is deleted!

[NeverDie]

@uhrheber said in Everything nRF52840:

One interesting thing I stumbled upon:

https://github.com/insane-adding-machines/unicore-mx

UniCore-MX | Universal Core for ARM Cortex-M0/0+/3/4/7/X

Supports nRF51/52

I looked at the link, but I can't figure out what problem it's solving. What's the headline on that?

[heinzv]

@redferne I was trying to get your platform and board extention as wellas the BLE library added to platformio, but got stuck afetr many many hours and many attempts (too much to add all the problems in one post). I'm using platformio with Windows 10 (I guess you use it with Linux/Ubuntu and also with a couple of command line tools)

I was trying to install this two:
https://github.com/Redferne/arduino-nRF5
Redferne/arduino-BLEPeripheral

I was trying to build a couple of simple examples and also the

C:\users\internet.platformio\lib\BLEPeripheral\src\BLEBondStore.cpp:11:12: fatal error: nrf_soc.h: No such file or directory

and
C:\users\internet.platformio\lib\BLEPeripheral\src/BLEPeripheral.h:136:5: error: 'nRF52840' does not name a type; did you mean 'NRF52840'?

and all other following errors are probably the result of the above ones.

Any hints?

Another question: How to define/declare the usage of the S140 softdevice in the project?
Using the PlatformIO IDE, not the command line.

[NeverDie]

As pointed out by @reinhold, here's a handy tool for programming your nRF52840 dongle, and possibly other nRF52 projects too:

https://www.tindie.com/products/ElectronutLabs/pogoprog-model-c-pogo-pin-programmer-swd-2-pack/

I think I'd like it better if it could somehow latch itself to the board, though, so that I could also get debugging information hands free without having to continually press the tool up against the board.

[Redferne]

@heinzv I'm sorry if I was unclear. I have only updated and tested one example which is the PCA10059 It should build without errors, but you might need to specify build type as "ble" or "dongle" as per the readme.

To enable the NRF52840 support use these flags:

-DNRF52 -DNRF52840 -DNRF52840_XXAA

and if building with the BLE Peripheral library and Softdevice S140 add:

-DNRF52 -DNRF52840 -DNRF52840_XXAA -DNRF52_S140

[NeverDie]

I have basic radio code now working in micropython: https://github.com/rabbithat/micropython_nRF52840/blob/master/README.md

So, I'm inching closer toward being able to do OTA code updates.

[alowhum]

@neverdie Does this also mean we're slightly closer to a MySensors implementation in MicroPython?

[NeverDie]

@alowhum said in Everything nRF52840:

@neverdie Does this also mean we're slightly closer to a MySensors implementation in MicroPython?

Theoretically.

[NeverDie]

By the way, I have it now to where you can send long strings (up to 255 characters if so desired) in a single packet from one node to another using micropython: https://github.com/rabbithat/Micropython_nRF52840_send

So, it's starting to get useful. I expect OTA code updates should be within range fairly soon. Since it's all written in micropython, I'll be able OTA update even the radio code as well, which is slick.

[alowhum]

Very cool!

[NeverDie]

I have my first pass on nRF52840 OTA updates working with micropython. So, proof of concept works. I feel I should improve the code a bit before posting it though. I should probably add a hash function like MD5 or SHA256 to make sure the transmitted update is valid before making it go live.

[monte]

@neverdie YAY for transport-agnostic mysensors-python-edition!

[Omemanti]

@neverdie would this also be usable for the nrf52832? (Not asking for an ETA here :))

[Wormhole]

Hi,

I've recently purchased a couple of the nrf52840 dongles and was searching web for ways to flash them and came across this post. I am a complete NOOB with this stuff, so I've found the information here really useful, so thanks to all who have contributed.

During my searches, I can across this; HOME SMART MESH (https://www.homesmartmesh.com/). It seems very similar to what MySensors is doing, but geared towards nrf5 hardware. Was wondering if you had seem this before, or had any thoughts on the project re: pros and cons?

[heinzv]

@wormhole I took a quick look at this HomeSmartMesh project and it's certainly interesting.
However, the MySensors project is more mature, has a large community, supports more MCU's and sensors and many HW projects are using/supporting it. It also supports nRF51 and nRF52 MCU's already to a certain extent (I guess using the internal nRF24 radio protocol and external RF chips like RFM69/95).
Beside that, it supports also a couple of home automations suite like FEHM, OpenHAB etc.
I'm currently on OpenHAB 2.3 using the MySensors Gateway for OpenHAB.
I think it would be rather a good idea, that we get the new nRF52840 features and RF protocols supported by MySensors (such as the BLE 5.0 with the long range feature).
We had already the discussions on IEEE 802.15.4 / Thread / Zigbee which are also great for home automation. The question was also, if we can/should include it in MySensors or are these competing technology stacks to MySensors.
I personally like the MySensors project, because it project a good development infrastructure with a lot of supported/preconfigures sensors which makes it quite easy to creates sensor nodes..
Now we are exploring how to best integrate and use the nRF52840 boards. NeverDie seem to be quite ahead of us and exploring also micropython option (not sure how far that fits into the MySensors concept

[NeverDie]

I now have working OTA update code for micropython programs on the nRF52840. I posted it on github: https://github.com/rabbithat/NRF52840_MicroPython_OTA_Updates

[heinzv]

@neverdie You are a hero Now the question is of course what comes next? Do you see any chance to get some of the findings implemented into the MySensors project? or will it be a completly new nRF52840 thread/story? Like using ZigBee or BLE 5.0 long range (remember the discussion we had with @scalz if it makes sense to use MySensors aor use a full standard stack like ZigBee or BLE 5.0).
What are your thoughts and plans? Best option to build sensor nodes/actors with nRF52840?

[NeverDie]

@heinzv said in Everything nRF52840:

@neverdie You are a hero Now the question is of course what comes next? Do you see any chance to get some of the findings implemented into the MySensors project? or will it be a completly new nRF52840 thread/story? Like using ZigBee or BLE 5.0 long range (remember the discussion we had with @scalz if it makes sense to use MySensors aor use a full standard stack like ZigBee or BLE 5.0).
What are your thoughts and plans? Best option to build sensor nodes/actors with nRF52840?

Well, as the saying goes, Rome wasn't built in day. I think there's no doubt that MySensors could be built using MicroPython, but right now there is no Rome and there's barely even a camp site. It's all just green fields and a few scattered tents. Also, I am just one person, and this is still early days. My near-term plan is to improve the OTA code to make it faster and more efficient. Right now, perhaps ironically, maybe the only reason to prefer Micropython over C is the existence of this OTA code. If someone writes an OTA bootloader for the nRF52840 in C, maybe that reason goes away. I might have done that instead, but this seemed a shorter path to getting an OTA.

In the end, programming the nRF52840 is, at this stage, almost like writing micro code. In other words, it almost doesn't matter which language you pick (provided it has an OTA updater), because the focus ends up being the same: fiddling with the registers and programming the PPI in order to get the highest efficiency.

[heinzv]

@neverdie sure, I did not epect Rome to be built in one day by one person I was just curiuos in which direction you're heading.
If the OTA feature is one of the key features, I was thinking of using a couple of information provided by Nordic such as as details on the OTA/flashing process of the nRF52 as well as the OTA DFU bootloader example provided as part of the 15.2 SDK.

OTA/Flash process
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.0%2Fbledfu_architecture.html
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.tools%2Fdita%2Ftools%2FnRF_Connect%2FnRF_Connect_DFU.html

OTA/Flash sources in C/C++
Just a few thoughts (I have to investiage) if we could use the sequence from the bootloader examples and they used libs for receiving data/code and initialized the flash process using the provided libraries
nRF5_SDK_15.2.0\components\libraries\bootloader
here I see in the dfu sub-dir the required function to observer, receiver and flash code

There a multiple examples how the code is transfered: via USB/serial, BLE/Zigbee, ANT ... and I guess we could use also the nRF24 protocol. Also encryption functions are available in the samples (secure dfu bootloader).

We need to derive, what nee to be done on the sender side to start to set the target to dfu mode and initiate the code transfer. Maybe that is also a tricky task.

Do you see that this approach can work and could be added to own C/C++ sketches and thus also added the MySensors project (of coure we need to include and use the required nRF52 libs for dfu)?

[NeverDie]

I don't doubt that it can be done. The amount of effort? It could be a little or a lot. I just don't know.

[NeverDie]

By the way, I now have the micropython code in a state where it is more easily demoed: https://github.com/rabbithat/NRF52840_MicroPython_OTA_Updates

Rather than continuing to post here about it, I'll just make future updates there. So, if anyone here is interested in it, you may want to check the github repository from time to time.