Hardware Discussion: Standardisation of BSL and RF Switch pins (and an LED?) for CC1352/CC2652 based designs

[omerk]

With the number of open-source hardware boards increasing around the newer TI chips, I think the time has come to agree on and standardise the BSL and RF Switch control pins (for -P parts) as otherwise @Koenkk's firmware repository is going to end up with very many variants of the same thing that is undoubtedly going to confuse new users trying to pick the right firmware for their boards.

This is a summary of the current situation and a proposal to try and lock these down for the future to reduce firmware support complexity for everyone involved going forward. From "what firmware do I pick" to "I accidentally disabled BSL by flashing the wrong firmware", there are a scale of user issues we might have to deal with as both hardware and software developers...

BSL

The beauty of BSL (the ROM serial bootloader) is that unless it is disabled in CCFG, it allows you to burn new firmware to your devices over serial without needing an external programmer. One caveat: Given than an external pin is involved in this special boot mode, you can accidentally "disable" BSL by picking a firmware image that moves the BSL trigger to a different physical pin than what your board might have.

Unfortunately TI documentation is confusing and has errors (see here and here).

Looking at the boards in the wild and ones I am currently working on as @electrolama projects, here's a summary of the current situation:

On CC2652R/RB, DIO_13 is the BSL backdoor enable pin used:

• TI LAUNCHXL-CC26X2R1 (BTN1)
• @electrolama zzh
• @slaesh cc2652rb usb dev stick
• (anything else, please comment below)

On CC1352P/CC2652P, this pin appears to be DIO_15:

• Launchpad LAUNCHXL-CC1352P-2 (BTN1)
• @electrolama zoe2, zzhp and zzhp-lite
• @mercenaruss Zigbeer E79 Stick
• (anything else, please comment below)

Proposal: Let's lock this down and use DIO_13 for CC2652R/RB and DIO_15 for CC1352P/CC2652P as the BSL backdoor enable pin for any hardware that is aiming to make use of this repository for firmware support.

"Auto-BSL"

On boards with USB-UART adapters that expose the extra control signals, following arrangement is used on some of the boards noted above:

• Computer side DTR - WMCU BSL pin
• Computer side RTS - WMCU RESET

Purpose of this is to get the device into BSL mode by cleverly toggling these pins in a special sequence so that automatic firmware updates could be done with, say, zigbee2mqtt without the need to unplug the coordinator board used.

Proposal: Let's lock this down and use the DTR-BSL/RTS-RESET mapping for any hardware that is aiming to make use of this repository for firmware support.

RF Switch pins for -P devices

This is a complex issue without an easy answer/proposal.

On -P devices, RF switches are used to switch between different RF paths. See this and this for the nitty gritty.

For example, this is how LAUNCHXL-CC1352P-2 deals with it:

Popular module maker Ebyte has two modules, E72 (CC2652P):

...and E79 (CC1352P):

On @electrolama zzhp (CC2652P):

So already we have a variety of pins being used for RF Switch control with some clashes. For instance, zzhp DIO_6 is the inverse of the Ebyte switch control (from what I can gather, I am waiting on a shipment of Ebyte modules to verify this). If that is indeed the case, I am happy to modify zzhp design so that the control signal matches the behaviour of Ebyte modules (so they can share the same firmware).

Generalising this is not going to work as nicely as the BSL proposal, for now at least for the @electrolama boards I am working on I am going to mimic Ebyte modules as they appear to be used by other designs as well.

Perhaps we can solve this by having a Launchpad firmware and "everything else" that utilises DIO_5 and DIO_6, @Koenkk?

A standard LED

DIO_7 is a common LED pin on the open-source boards, active high (Pin state 1 or high: LED On). Perhaps it can be the standard LED for features like #202 ?

Comments and additions welcome!

Please tag/add/mention any hardware developers/projects that might be working on similar hardware.

[mercenaruss]

Following @omerk request we agree with him,many DYI devices now based on Ebyte modules,what are very cheap and easy to get:
E79-400DM2005S(CC1352P),E79-900DM2005S(CC1352P),E72-2G4M20S1E(CC2652P), all of them have different Truth Table(@omerk show them upper) what is obviously different from standard LAUNCHPAD.
@egony and @palko are developing/testing some hardware based on this modules from EByte, firmware is giving us headache to adjust for this modules.
We all agree with @omerk that is required to standardize and make a firmware for this modules.

BSL - DIO_15

Perhaps we can solve this by having a Launchpad firmware and "everything else" that utilises DIO_5 and DIO_6, @Koenkk?

We agree with this and think is the best solution for DYI devices and Sticks based on EByte modules.

DIO_7 is a common LED pin on the open-source boards, active high (Pin state 1 or high: LED On). Perhaps it can be the standard LED for features like #202 ?

About this i think is better to have 2 LED on DIO_7 and DIO_8

[mercenaruss]

@omerk better to make a full list of all pins/DIO's used for our hardware.

[omerk]

Here's a first stab at the list of adapters and hardware details:

Adapter	TI Chip/Module Used	Firmware to Flash	BSL Trigger Pin (1)	Auto-BSL (2)	RF Switch Control Pins (3)	LED(s)
TI LAUNCHXL-CC26xR1	CC2652R	CC2652R	DIO_13	No	N/A	DIO_6 (Red) DIO_7 (Green)
TI LAUNCHXL-CC1352P1	CC1352P	CC1352P_CC2652P_LAUNCHPAD	DIO_15	No	DIO_28: 2.4Ghz DIO_29: 20dBm PA DIO_30: Sub-1GHz	DIO_6 (Red) DIO_7 (Green)
TI LAUNCHXL-CC1352P-2	CC1352P	CC1352P_CC2652P_LAUNCHPAD	DIO_15	No	DIO_28: 2.4Ghz DIO_29: 20dBm PA DIO_30: Sub-1GHz	DIO_6 (Red) DIO_7 (Green)
TI LAUNCHXL-CC1352P-4	CC1352P	CC1352P_CC2652P_LAUNCHPAD	DIO_15	No	DIO_28: 2.4Ghz DIO_29: 20dBm PA DIO_30: Sub-1GHz	DIO_6 (Red) DIO_7 (Green)
Electrolama zzh	CC2652R	CC2652R	DIO_13	No	N/A	DIO_7 (Pink)
Electrolama zzhp-lite	CC2652P (Ebyte E72)	CC1352P_CC2652P_DIO5-6	DIO_15	Yes	DIO_5: 20dBm PA ?? DIO_6: 2.4GHz ??	DIO_7 (Pink)
Electrolama zzhp	CC2652P	CC1352P_CC2652P_DIO5-6	DIO_15	Yes	DIO_5: 20dBm PA ?? DIO_6: 2.4GHz ??	DIO_7 (Pink)
Electrolama zoe2	CC1352P (Ebyte E79)	CC1352P_CC2652P_DIO5-6	DIO_15	No	DIO_5: 20dBm PA ?? DIO_6: 2.4GHz ??	DIO_7 (Pink)
slaesh's CC2652RB stick	CC2652RB	CC2652RB	DIO_13	Yes	N/A	DIO_7
mercenaruss ZigStar	CC2652P (RFStar ?)	CC1352P_CC2652P_DIO5-6?	DIO_15	No?	?	DIO_7 DIO_8
mercenaruss Zigbeer E79 stick	CC1352P (Ebyte E79)	CC1352P_CC2652P_DIO5-6	DIO_15	No?	DIO_5: 20dBm PA ?? DIO_6: 2.4GHz ??	DIO_7 DIO_8

Note 1: Pull this pin down on power up to trigger BSL mode
Note 2: Toggle RTS (RESET) and DTR (BSL Trigger) to put the device in BSL mode
Note 3: Pin mentioned high, all others low

@mercenaruss Can you please have a look and add missing details for your adapters? Also, ISTR you mentioning that you had some success with the firmware for Ebyte modules, can you add a bit more info here? Thanks!

/cc: @Koenkk @sjorge

[mercenaruss]

Please be notified that E79 chip is not taking in consideration for future developments, only E72.
Firmware is described HERE

Adapter	TI Chip/Module Used	BSL Trigger Pin	Auto-BSL	RF Switch Control Pins	LED(s)
ZigStar	CC2652P - RFSTAR RF-BM-2652P2	DIO_15	Available for CH340C ver.	DIO_28: 2.4Ghz , DIO_29: 20dBm PA	DIO_6(Green) DIO_7(Red)
Zigbeer E72 by Egony	CC2652P - Ebyte E72-2G4M20S1E	DIO_15	No	DIO_05: 20dBm PA , DIO_06: 2.4Ghz	DIO_7(Green) DIO_8(Red)

Zigstar is firmware compatible with:

• TI LAUNCHXL-CC1352P1
• TI LAUNCHXL-CC1352P-2
• TI LAUNCHXL-CC1352P-4
  with small exception: PA i think is not enabled in @Koenkk firmware.

I think to build firmware following some instruction is easy, single hustle in my view is PA and patches.

UPDATE: RFSTAR RF-BM-2652P2, is working perfectly with existing firmware for CC1352, still not able to test if output Power matches 20 dbm,but for sure module is working perfectly following last tests.

[Koenkk]

Added new firmwares: https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

[mercenaruss]

@Koenkk I think existing firmware CC1352P2_CC2652P_launchpad_20201103.zip is not suitable for sticks/coordinators where amplifier is required. In my personal opinion I think is required 2 firmware's:

1. CC1352P2_CC2652P_launchpad - where amplifier is not enabled
2. CC1352P2_CC2652P_launchpad_amplifier - with 20 dbm amplifier

or possible i do a mistake here.

[Koenkk]

@mercenaruss what would be the differences between these firmwares?

[mercenaruss]

@mercenaruss what would be the differences between these firmwares?

Enabled amplifier???
Or amplifier can be enable manually in Z2M?

P.S. Maybe i dont understand something

UPDATE: Ohh now i get it, Launchpad have a amplifier,but was not enabled till now,so is not required to differentiate them.
One firmware is enough,but TX need to be 20dbm, correct?

[Koenkk]

@mercenaruss I've just published new firmwares: https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator/Z-Stack_3.x.0/bin

Defuault tx power is 20dbm now (up from 0dbm). It can be lowered by adding the following to the configuration.yaml.

experimental:
  transmit_power: 5

[mercenaruss]

@Koenkk a big thank you!!! Testing is ongoing!

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days