Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
omerk opened this issue Sep 26, 2020 · 12 comments
Labels

Comments

@omerk
Copy link
Contributor

omerk commented Sep 26, 2020

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:

image
image

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

image

...and E79 (CC1352P):

image

On @electrolama zzhp (CC2652P):

image

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.

@omerk omerk changed the title Hardware Discussion: Standardisation of BSL and RF Switch pins for CC1352/CC2652 based designs Hardware Discussion: Standardisation of BSL and RF Switch pins (and an LED?) for CC1352/CC2652 based designs Sep 26, 2020
@mercenaruss
Copy link
Contributor

mercenaruss commented Sep 26, 2020

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
Copy link
Contributor

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

@omerk
Copy link
Contributor Author

omerk commented Nov 7, 2020

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
Copy link
Contributor

mercenaruss commented Nov 7, 2020

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
Copy link
Owner

Koenkk commented Nov 10, 2020

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

@mercenaruss
Copy link
Contributor

mercenaruss commented Nov 13, 2020

@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
Copy link
Owner

Koenkk commented Nov 13, 2020

@mercenaruss what would be the differences between these firmwares?

@mercenaruss
Copy link
Contributor

mercenaruss commented Nov 13, 2020

@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
Copy link
Owner

Koenkk commented Nov 13, 2020

@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
Copy link
Contributor

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

@github-actions
Copy link

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

@sjorge
Copy link
Sponsor Contributor

sjorge commented Dec 22, 2020

Small update, the zzhp-lite compatible firmware seems to be working fine.

Need to give it a good stress test but ran into some unrelated issues. Hope to look at it soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants