This blog post is a continuation of my road test review for the Panasonic PAN 1780 Bluetooth LE Eval Kit

In part 1, http://https://www.element14.com/community/groups/roadtest/blog/2020/11/01/panasonic-pan1780-roadtest-unboxing-and-cold-start, I followed along with the tutorial (more or less) and got to a point of 2 way Bluetooth communication between the dev kit and my phone in under 5 hours. Not bad, but we now need to explore some more.

What are we doing here?

for the RoadTest, I wanted to try to replicate a real-world situation, such as I might find in my work place. The focus of the road test is the usability of the kits, documentation and development environment, because that's one of the most important and often overlooked things when choosing a part to put on a board. of course, price, performance, availability etc are also crucial, but a cheapo part with a poorly written datasheet can end up costing you a lot in development time & re-spins.

My overall plan for the road test is to see how quickly and easily I can create a proof of concept working demo of a simple project. I’m trying to time how long it takes, as a measure of how well documented the board is.

In my original proposal I didn’t plan for this section to be a blog in its own right, because I didn’t imagine it would be that big. However, during the first phase of the project I noticed a hole in the documentation, both from my own exploration and also from working with another RoadTester to try to figure out the power supply modes and USB connections.

When I come to tackle the second phase, I discovered that the hole was too big and needed to be plugged! By which I mean, the documentation was missing some information I needed to begin phase 2 of the project as I had planned it. This is of course a thing that can happen in real life as well as RoadTests, so the extra work as a result, and consequently the time it has taken has got to be part of the RoadTest.

In this part, I will document the missing information, and the work I had to do to get around this issue. I did my best to keep a track of the time, but this type of work is rarely documented in this much detail, and it wouldn’t be fair to include the time taken to repeatedly take screen shots and explain your thinking in written form, since I would never do this in my real job. for that reason, I don't really mention the time keeping aspect, but I'll give you an estimate at the end.

Fair warning, this is reasonably dry as a blog post. Its tedious tables and screen shots of text and stuff. I don't think there's even a single picture of the board, and no report of any programming or any activity as such. I’ve tried to put as much colour and imagery in as I can, but you can only do so much!

The reality is that sometimes engineering is exactly this, and you find yourself digging through documents for days on end trying to find the technical detail, when all you really want to do is make an LED flash!

I suppose I should be pleased that my aim to replicate a real-world situation was more successful than I had ever imagined!

Lets get stuck in ...

Following on from part 1, the next logical step is to choose a project from the provided firmware examples and try to understand it and adapt it to fit our use case. Remember we are looking for the quickest working proof of concept demo. Bodged code may not be ideal for a maintenance perspective, and there are certainly advantages to planning out the software structure from the start, but that can all be done later after our quick and dirty “look what we can do” demo is approved by the corporate management. So which software examples can we choose from? What are the options?

The SDK we downloaded in part 1 includes a large number of examples, separated by high level Bluetooth function. For example, here’s the ones where the device is behaving in the role of a Bluetooth peripheral:

That’s a pretty good list! I spent a bit of time going through each one trying to understand what they are, but repeating that here would be a bit too tedious.

To summarise, they seem to demo every plausible use for Bluetooth low energy connectivity, including the beacon and eddystone profiles, a variety of things you might find in a wearable device (Heart rate, Blood pressure, cycling speed) and one project for a company called “tile” who sell Bluetooth locators beacons so you can find your car keys.

I guess that for a modest fee you too can become part of the tile product ecosystem and manufacture things that your customers cannot lose.

Inside each of the examples, is a series of folders called PCAxxxx, each of which contain project files for the various IDEs and soft devices that are supported.

PCA stands for printed circuit assembly, and the number is a unique identifier. (the letter might be board revision or build variation?). So, all we need to do is work out which Hardware code relates to the board we have, and choose from the available demos right?

Fortunately, the online Nordic SDK help centre provides the mapping we require:

(by the way, when writing this up I found it really difficult to re-find this table. Its here in case you need a link: https://infocenter.nordicsemi.com/topic/ug_gsg_ses/UG/gsg/chips_and_sds.html)

So, uh, okay. The PAN1780 isn’t listed. But we used two of these examples in the first part as part of the Panasonic getting started guide. Those examples were targeted at PCA10056, so maybe the nRF52840-DK refers in some way to our PAN1780 eval kit?

No, No it doesn't.

At this point, I went and read all of the documents from Panasonic, and found no mention of any way to get a list of compatible firmware examples. add on another few hours to my total without making any progress!!

On the Nordic side, there’s a bit more info. As well as the mapping table above, we get some special Hardware related defines in the SDK

Great, so the SDK covers more than just the Nordic dev kits, but I can’t see PAN1780 in that list.

There is a remark that you could create your own “custom_board.h” if your development hardware is not listed.

I've got a sinking feeling about this. I'm reasonably sure I've read every relevant document, and I feel confident in proclaiming:

Missing information
There are no details provided on the compatibility between the Nordic software examples and the PAN1780 hardware

… oh dear. one of the key things about lashing together a proof of concept demo like this is having readily available software examples to adapt.

All of the Nordic provided software examples are written for hardware other than the PAN1780. Even the one we used in part 1 is for the nRF52840-DK. This is particularly annoying, because there aren’t any “pick up and go” examples beyond the blinky and RF blinky from the tutorial.

Its even more frustrating that since the nRF52840-DK and the PAN1780-USB Reference design have a very similar feature set, its reasonably likely that the many of the PCA10056 examples are compatible. However, because Panasonic have not explicitly told me this, and Nordic have not acknowledged the Panasonic module eval board, I can’t assume it’s true.

At this point some of you might be screaming at me “just try it, see if it works!” and you’re probably right, and it probably will just work, but I want to at least attempt confirmed compatibility because the number of things that could go wrong is huge, and I’ve had hardware bugs make software behave intermittently badly that was incredibly difficult to track down.

In my imaginary office, assuming compatibility could cause the demo to randomly fail just as I’m presenting it to the C-level decision makers, or create a bug that takes far longer to track down than it should because I’m looking in the wrong place, delaying the project. In the real world, assuming compatibility could damage the eval kit, causing me to have to end the RoadTest at that point, or create a bug that takes far longer to track down than it should because I’m looking in the wrong place, delaying the project. Or, leave me constantly wondering if my inability to make the program work was because of the hardware or software.

In either case, it feels risky. But that’s okay, I can confirm compatibility myself, and if necessary mod the examples and create my own custom_board.h file for the PAN1780.

Comparing evaluation kits

The first thing to do, following my nose, is to have a closer look at the nRF52840-DK and see if the schematics are similar enough that we can use it as a starting point.

We have a schematic for the PAN1780 eval kit in the “module integration guide”, and the nRF52840-DK has the “Hardware files” available from

https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52840-DK/Download#infotabs

in this case Hardware files means a complete set of design files including the Altium project with schematic and layout, separate BOMS, Gerbers, assembly drawings, and even pick and place files.

This pack really does put the PAN1780 dev board hardware files to shame! Panasonic only provide un-searchable pdf prints midway through the module integration guide.

This really does feel like an oversight - if you can think of any reason it makes sense for Panasonic not to share the design files please tell me in the comments! there's just no good reason for it.

Comparing  Apples to Apples

But wait! We can’t just compare the nRF52840-DK supporting circuitry to the equivalent for the  PAN1780 just like that, its apples to oranges. First, we need to understand how the nRF52840 pins relate to the PAN1780 pins.

While the module integration guide does have the module pad arrangement and numbering, it doesn’t list the pin functions. For this we turn to the product specification:

Here is the pin table provided in the product specification. As you can see, the description is pretty basic. This isn’t typically a problem, but it is all of the detail we get about the pins.

Ok, its not all the detail we get, we are also shown the recommended operating conditions:

And the absolute maximum ratings

But this just isn’t enough.

Missing information
there is no detailed pin description for the PAN1780

To highlight the slightly belaboured point I’m making, what do we know for sure about the GPIO?

V_oh? V_il? Are they pulled up or down? Maximum current output? What should we do with them if we do not require them? Its not unheard of for modules like this to have different IO voltages to the power supply.

Ultimately, I know that in the case of GPIO it is extremely likely that they are directly connected to the GPIO of the Nordic IC with no intermediate circuitry, so we can just take the specs to be the same as are stated for the nRF52840.

But that isn't stated anywhere that I've seen, and it doesn’t always appear to be the case. For example, the Module pins A8 and A9 are labelled NFC on the pan1780, but the nRF54820 says that they can also be used as GPIO. Why the difference? Is there some circuitry on the PAN1780 module that precludes their use as IO pins?

Being a fan of Matt Parker, and realising that I only had a small set of data and that I wasn’t running a life critical government health database in a time of national crisis, I made a spreadsheet of the mapping between the modules pins and the Nordic Pins.

I took the WLCSP as reference because I think the QFN version is bigger than the PAN1780 module

Here is a table of the pins which have a common name, and can easily be matched (ignoring ground pins):

...ah, something seems to have gone wrong there.

Ok, well here is a table of the pins which have a discrepancy, but which are pretty obviously mapped to specific WLCSP pins:

ok no problem with that. but here is a table of pins which actually took some thinking about to work out that they were mapped:

Lets deal with the 32kHz pins first, C2 and B2. Its not at all obvious how to relate 1 and 2 to in and out, but the instructions are to leave them open anyway. Lets see what the Panasonic docs have to say. First the module integration guide has this in the headline Features list:

So, some of our 48 GPIO are shared with the 32kHz IN/OUT feature. But the module block diagram has it shown as though the crystal was on board. Could it be that its integrated into the module? The product specification has this:

There is no other mention* of the 32 kHz pins or crystal in the module integration guide or the product specification.

Actually, no other “searchable” mention. The block diagram text isn’t apparently text, so my initial ctrl-f effort didn’t pick up the crystal block on the diagram because its not searchable. I don’t have the patience or goodwill to read through every page to find all of the non-searchable images and see if there’s any relevant data in them.

So, I conclude that there is an onboard 32 kHz crystal, and that these pins are probably connections for test or debug purposes.

Here’s how Panasonic could have saved me doing all this work: (time which I will never get back!)

and then something like this:

What about the power supply pins? Well, I had already looked into this because of some back and forth on the RoadTest landing page about USB power supply mode.

There is no real data in the Panasonic docs about what the pins do unless you start trying to interpret the intention of the reference design schematic. Outside of the reference design we get:

and the pin descriptions table:

and

we also get this table:

and these design notes:

So, given this info, you would be forgiven for thinking that you must supply the “LV Mode” pin with 1v8 or 3v3, and you could optionally unlock extra features by applying additional voltages to the “HV mode” or “USB Mode” pins. Its tempting to brush off the DC/DC stuff, since it doesn’t seem to be connected to any pins. (note that USB is listed as optional in the recommended operating conditions table, but no comment is made in the pin list - implying it is mandatory).

But looking at the Nordic docs reveals a different story. The product specification for the nRF52840 IC version 1.1 is here:

https://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.1.pdf

There, we have a whole chapter (5.3) about the power supply, in which it says:

So, it seems like on the Nordic we can either,

• Tie both pins together and supply a voltage between 1v8 to 3v3 nominal, or…
• Only supply VDDH with a voltage between 2.5 and 5.5V

It seems like it would be mind-boggling if the Nordic pin VDD and VDDH didn’t map to Panasonic pins LV mode and HV mode respectively. Their input voltage ranges are the same, and the Nordic “Normal/High voltage mode” nomenclature would seem to hint at these names.

If that is the case however, the Nordic docs disagree with the Panasonic docs. I'm inclined to trust the Nordic docs over the Panasonic ones, so the only conclusion I can draw here is that the Panasonic datasheet is wrong.

DATASHEET ERROR?
putting a voltage on the VDDH pin aka “HV Mode” IS NOT OPTIONAL, despite it being consistently marked as such in the Panasonic documentation.

Otherwise, either the Nordic docs are wrong, or Panasonic have drastically changed the behaviour of the Nordic power input with external supporting circuitry added on to the module, not explained it, and given it a name which is far too close to the original pin name.

incidentally, a cursory look at the schematic for the PAN1780 eval kit would appear to support the idea that VDDH is in fact optional, but a careful reading of the link jumper options tells us otherwise:

looks like you can remove JP12 which supplies the "optional" power to pin VDDH right? wrong. unless you actually power the module through pin 1 of JP12:

USB mode is a similarly (though less catastrophically) confusing story, but lets move on.

Summary of pin pain

it feels likely that this is about as far as we can get. I'd say its a reasonably good guess that any pins we see in the product specification for the PAN1780 are connected without additional circuitry to the Nordic nRF52840 pins of similar names, and we can treat them as such (despite what the Panasonic documentation might say).

where a pin on the Nordic doesn't appear on the Panasonic, I think we can assume that its been taken care of on the module and forget about it. there are a couple of exceptions to this:

the 32kHz pins - which have presumably have a 32.768 kHz real time clock crystal attached on-module, so we shouldn't connect to them

and, this one remaining pin:

the Panasonic Eval kit provides a coaxial connector for this pin, its probably for an external antenna.

Schematics comparison

Okay, we should now be able to compare the schematics, and see how similar the 2 evaluation boards are. remember that we are looking to see what changes (if any) we have to make to the software examples for the nRF52840-DK so that they will run on the PAN1780 eval kit.

the schematics for the nRF52840-DK came as printed PDF in the download, while the schematics for the Panasonic Evaluation kit are found in the Product integration guide:

https://mediap.industry.panasonic.eu/assets/custom-upload/Devices/Wireless%20Connectivity/Bluetooth%20Low%20Energy%20Mod…

for reference before we dive in, here is the whole thing:

The Nordic board schematic is much larger than the Panasonic, but at least some of that is the vast number of connectors, which shouldn't affect software at all.

lets start at the top, here's the immediate vicinity of the Nordic nRF52840:

Nothing really on this page yet. if I had to guess, I would sat that all of the stuff on this page is on the PAN1780 module itself.

there's a 32kHz crystal on XL1 and XL2, and a 32MHz crystal on XC1 and XC2. The Antenna is a u.fl or pcb trace antenna (PAN1780 has a chip antenna).

The other pins are all either de-coupling caps and DC/DC inductors (presumably all mounted on-module on the PAN1780), power supplies, or just routed out to off sheet connectors.

Notice the 32kHz clock pins can be disconnected using the solder bridges. - its possible, though unlikely that the software demos will require us to mod those. probably should bear it in mind.

here's probably the corresponding section of the Panasonic schematic:

sometimes its nice when things are done for you!

the next few pages of the Nordic are pin mapping and the on-board debug probe. I wont bother comparing those unless it comes up otherwise, since we know that the debugger works with the examples from part 1.

LEDS and BUTTONS

Starting with the LEDs, we should be pretty sure to find compatibility here, because we have used them in the blinky. Here are the Nordic LEDs:

which map to pins:

ok, so here are the Panasonic LEDs:

follow the net labels:

Great so they are about the same. If we give everybody the benefit of the doubt (and me a break from this tediousness) and assume that there are no firmware examples where you need to break the solder bridges on the Nordic, then the only difference is the resistors – no big deal. But that’s just for starters, what about the buttons?

Nordic:

(by the way, its a nice visual clue that the 2 schematics are done in different packages. I probably wont point out which is which too much, but just in case your not sure, the Panasonic is always the green wires/red pins /black text combo, while the Nordic is blue wires / yellow boxes / blue text format.)

Not quite so straight forward. Button 3 and 4 map to pins P0.24 and P0.25, but buttons 1 and 2 go through this analogue switch arrangement so there’s an option. It seems to be tied to the CTS switch too. Lets compare these to the PAN1780:

So we don’t get the options, only the default. Probably that’s fine right? A switch is a bit more trivial to change than a solder bridge, but default is the expected position for most things. again, be aware, but not a show stopper

NFC

Next on the Nordic – NFC pin configurations

So this actually goes from the chip to the resistor network (which are acting in the same function as solder bridges) to the NFC connector via a 300pf cap. The No-Stuff R43 and R45 would otherwise connect the pins to one of the headers D21, and D22

Compare to the PAN1780:

again, we don't get the options, but the circuit matches the default.

Flash Memory

compared to the PAN1780:

Not so similar– no flash memory and even if you wanted to add it on you couldn’t because we can’t get access to P0.23.

So, 1^st real criteria:

User USB to IC / Module

since this is functionally the same on both boards, I'll only show the PAN1780 here:

Debug serial port

The Nordic has a switchable serial port by the looks of it.

the IMCU ports go to pins on the on board interface MCU (aka debugger)

Its not clear without digging deeper if this switch is controlled by the debugger driving IF_ON, or if the debugger is also reading the state. Either way, the IF_ON signal also affects power switches and other things, so I’d suggest it was probably reasonable to assume the default is ON.

The Panasonic pins are spread out a bit, note that the optional CTS is NC on the Panasonic – we only get the default.

This is a bit of a departure.

The Panasonic routes the same serial port pins via some link jumpers to an FTDI chip serial to USB converter. The USB lines are then connected to a port of the 2 port USB hub, which has the main X2 USB connector as its up-stream connection, and the J-link on the other downstream port. There is 2 further twists though, the Link jumpers can be changed to route the serial port Rx and Tx to either the J-link directly:

or, to the outside world:

So we can just use it as UART1 on these pins by bridging the jumpers across the gap.

Again, I think this is ok. The only way we wouldn’t be able to use the examples was if they relied on having the RTS and CTS signals, but this is pretty rare in serial port use. Never the less we have to note it,

Speaking of DEBUG...

The Nordic allows the switching of the SWD signals away from the onboard debugger to an external connector

as does the Panasonic via link jumpers, but, there's another subtle difference -  the Panasonic doesn’t give us SWO, connected to P1.00 on the nRF52840-DK (that pin doubles up as TRACEDATA0/TRCDAT0)

For that matter, none of the TRCDAT pins are made available for use in the same way they are on the Nordic:

M_CTS can be disconnected by removing a link jumper, and the 2 buttons are Normally-Open, but we can’t even get a test wire onto TRCDAT0 or 3

On the Nordic however:

So what does SWO do? What do the TRACEDATA pins do?

Well, SWO is the output for the ITM (Instrumentation Trace Macrocell) data. This is basically a high speed debug data connection, which allows much faster debug information to be sent through the debug adapter than would normally be possible through a serial port.

The rest of the TRACEDATA pins provide access to the ETM (embedded trace Macrocell) - a much more in depth debug port which can give you things like the call stack in real time and even the history without disrupting the processor. Its obviously extremely valuable for a certain set of embedded problems, but adapters which are compatible must read and process much larger quantities of data, and so are proportionally more expensive. (think £1500+) it seems unlikely that we have that functionality on the on-board J-link of the PAN1780, so I don't suppose we will miss it that much. the lack of SWO should be noted though:

Rounding up

Most of the rest of the circuitry on the nRF54820-DK is just connectors, but there are a couple of extra features.

There are some pins marked SDA and SCL mapped to P0.26 and 27, which have switchable 4k7 pullups connected by default. This one again I think its fine, so long as we are aware of the lack of pullups on the eval kit.

on the PAN1780 eval kit, we can close out the comparison by looking at the GPIO pins on the module which don’t appear to be accessible.

We’ve already spotted the 2 debug related pins, and the one used for flash memory and CTS_OPTIONAL on the Nordic, but there are also a few more:

and our hopefully complete compatibility criteria for software examples provided by Nordic for the nRF52840-DK

In conclusion

so where are we left with this? well, to start with:

there are some failings we've identified with the documentation - some of it non-trivial.

that's pretty bad, because it means that the user (aka, me in this case) has got to find some way around it. My version was the above, which shows that its possible to make some reasonable assumptions, but it wasted a lot of my time.

another engineer might have decided to just try it and test everything, or even just to press ahead and assume it will work. in each case, you are sacrificing something (cost/time/confidence etc).

in the corporate world, any of those things are painful, because they will either slow down your project now, increase the cost, or run the risk of having the whole thing fail catastrophically at some unpredictable future point.

in this Road-test, there's been a direct cost, because this activity took up time I could have been developing or testing my proof of concept design. (This is exactly the same as it would have been in the office) I will have to re-asses my expectations for what I can achieve in the allotted time.

there are a few upsides too though

1. The next user who comes across this issue can read this blog post and it might save them some time.
2. I now have a good familiarity with the module on board features (DC/DC converters!) and also the Eval kit
3. I should now be able to easily pick which SW demos are compatible
4. I hope that I've done some useful work for Panasonic in suggesting improvements?

and last but not least - armed with this knowledge I might actually be able to get a project working!

Final thoughts

despite my frustrations probably showing in this post, I actually like the Panasonic circuitry better. its a more efficient use of the pins and features, and the board feels like more of a blank slate on which to build hardware than the Nordic version. I especially like the USB host / serial port combination, since we can use it for :

• serial comms to the PC with a single cable (independent of the debug probe)
• or,  (presumably) debug related messages via the connection to the j-link
• or, a basic inclusion of USB port without having to code up the USB stack

I'm a bit disappointed by the lack of SWO as I like using the ITM serial link for debugging, and it feels like it wouldn't have cost anything to hook it up, but maybe there's another way to achieve this. (I smell a second revision of the board to fix the power on JP12 thing, so maybe it will get fixed then?)

what about a time check?

that's really hard. in reality, this process has taken a huge amount of time, in part because I was documenting everything with "blog" levels of detail, but also because I did a load of other things that I didn't report here because they didn't have any outcome.

But I had to do them to know that there was nothing there, and I had to record the "blog" detail just in case it became the most interesting thing.

I think realistically, I've probably spent over 24 hours on this section when you count everything (aka, 3 working days), but lets say the non-documenting work was 1.5 days.

that puts my total at around 2.5 days work up to now, so I'm a bit behind my plan - I had hoped to have some customised software by this point, but with any luck, we'll get to that in the next post!