CC2538 und CC2530+CC2592 ZigBee Raspberry Pi Modul

trapperjohn · January 27, 2021, 5:44am

Did someone already have a look at the NVRAM data that is stored a) before pairing, b) after pairing and c) after a power cycle?

This script could be modified to read out all data (of course use nvRead instead of nvDelete )

github.com

Koenkk/zigbee2mqtt/blob/dev/scripts/zStackEraseAllNvMem.js

const {ZnpCommandStatus, NvSystemIds} = require('zigbee-herdsman/dist/adapter/z-stack/constants/common');
const {ZnpVersion} = require('zigbee-herdsman/dist/adapter/z-stack/adapter/tstype');
const {Subsystem} = require('zigbee-herdsman/dist/adapter/z-stack/unpi/constants');
const {Znp} = require('zigbee-herdsman/dist/adapter/z-stack/znp');


class ZStackNvMemEraser {
    constructor(device) {
        this.znp = new Znp(device, 115200, false);
    }

    async start() {
        await this.znp.open();
        const attempts = 3;
        for (let i = 0; i < attempts; i++) {
            try {
                await this.znp.request(Subsystem.SYS, 'ping', {capabilities: 1});
                break;
            } catch (e) {
                if (attempts - 1 === i) {

This file has been truncated. show original

edit: Here is the link to the definitions of the request/response packets:

github.com

Koenkk/zigbee-herdsman/blob/master/src/adapter/z-stack/znp/definition.ts

import {Subsystem, Type as CommandType} from '../unpi/constants';
import ParameterType from './parameterType';
import {MtCmd} from './tstype';

const Definition: {
    [s: number]: MtCmd[];
}
= {
    [Subsystem.SYS]: [
        {
            name: 'resetReq',
            ID: 0,
            type: CommandType.AREQ,
            request: [
                {name: 'type', parameterType: ParameterType.UINT8},
            ],
        },
        {
            name: 'ping',
            ID: 1,

This file has been truncated. show original

pmayer · January 27, 2021, 5:27pm

Ich hab momentan leider zu viel auf der Arbeit um die Ohren, weswegen ich nicht zum Testen komme.
Hab aber anstatt des CC2538 mal nen CC2530+CC2592 mit Z-Stack 3.0.x genommen und damit sind nach dem Reboot auf dem selben Pi die Geräte noch angelernt.

trapperjohn · January 27, 2021, 5:27pm

NV memory definitely changes after a power cycle.

This is the content of NV memory with no devices in Z2M:
1_no_dev.txt (13,5 KB)

This is the content of NV memory with paired (and functional) devices in Z2M:
2_working_dev.txt (13,5 KB)

This is the content of NV memory after a power cycle:
3_power_cycle_broken.txt (13,5 KB)

(and this is the modified Javascript to extract the NV memory:)
zStackReadAllNvMem.js.txt (4,4 KB)

Here is a web view of the NVRAM difference between working Z2M and broken Z2M after power cycle:

pmayer · January 27, 2021, 5:28pm

@Adrian Do you have any insights on this?

pmayer · January 29, 2021, 1:27pm

Hey @trapperjohn,

just tested it with external 3.3V… works. Well, should be the same as a z2m restart as the 3.3V are present from the external source.

Will build an LDO circuit on a breadboard.

pmayer · January 29, 2021, 1:40pm

Testing with LDO from 5V Pi:

	Revision		cold reboot	reboot	z2m restart
jethome	20201010		no	yes	yes

“cold reboot” means sudo halt, power down, power up.

iobroker_biicii.de · January 29, 2021, 9:58pm

habe gestern den J-Link erhalten, heute vormittag vor dem Dienst, MODKAMRU_V3_USB.hex geflasht.

ein Osram-Plug und Eine Trafri Bulb angelernt., und vor dem Dienst, den gesammten Schreibtisch Stromlos gemacht.

der Stick ist ein “Bausatz” von Ebay, “Hersteller” ludwig.it, der CC2538+CC2592 wird per USB angesprochen, nicht UART

Plug und Birne funktionieren nach dem Inbetriebnahme des Raspi4 mit SSD an USB3 mittels IoBroker-Bedienung.

Coordinator firmware version: {“type”:“zStack30x”,“meta”:{“transportrev”:2,“product”:2,“majorrel”:2,“minorrel”:7,“maintrel”:2,“revision”:20200327}}

Ich werde jetzt noch eine andere Firmware ausprobieren, und später dann mal das cod.m-Modul mit dieser Firmware (UART-Version) bespielen, ich berichte weiter

Update 1, da war ich wohl zu euphorisch, ein zweites mal “shutdown now” und stromweg schalten bringt wieder das Problem das die Geräte nicht ansprechbar sind, das soll mal einer verstehen

Update 2, möglicherweise, vielleicht, anscheinend lag der Stick beim update1 zu nah an der SSD ?!?, hab nun 30cm dazwischen

habe inzwischen auf Variante ohne ioBroker nur mit zb2m umgestellt (frontend/Webinterface), als Firmware läuft im Moment JH_2538_2592_ZNP_USB_20201010.hex

hier läuft ebenfalls der Stick wie gewollt, nach shutdown now, “Stromlos”, einige Minuten warten, hochfahren, zb2m starten, etwas warten, status der Osram-Dose abrufen, umschalten vom webintercae und auch schalten an der Dose wird von zb2m erkannt, funktion OK.

jetzt “Stromausfall”,
beim booten des RPi4 von SSD kamen inode-fehler…, nach einem harten shutdown nichts ungewöhnliches, zweiter Neustart lief dann problemos durch.
zb2m gestartet, alles OK, sauber.
die JetFirmware läuft normal und erwartungsgemäss, allerdings bis hier mit dem selbstgelöteten “USB”-Modul, NICHT UART

ich werde nun das cod.m Modul versuchen zu flashen mit der JH-UART-Version. *kabel suchen"

Zwischenstand:
da ich das cod.m-modul nicht auf den rpi4 stecken, wegen dem flirc gehäuse, umzug des USB sticks auf einen rpi3 und anschliessendem zb2m test, POSITIV alles normal

Schritt: Reproduktion des Fehlers, shutdown now, strom weg auf dem Raspi3,

Zigbee2MQTT:info 2021-01-29 22:18:51: Coordinator firmware version: ‘{“meta”:{“maintrel”:2,“majorrel”:2,“minorrel”:7,“product”:2,“revision”:20200211,“transportrev”:2},“type”:“zStack30x”}’
Zigbee2MQTT:info 2021-01-29 22:18:51: Currently 2 devices are joined:
Zigbee2MQTT:info 2021-01-29 22:18:51: 0x7cb03eaa0a0c49e6 (0x7cb03eaa0a0c49e6): AB3257001NJ - OSRAM Smart+ plug (Router)
Zigbee2MQTT:info 2021-01-29 22:18:51: 0x000d6ffffe115045 (0x000d6ffffe115045): LED1624G9 - IKEA TRADFRI LED bulb E14/E26/E27 600 lumen

leider totaler Gedächtnisverlust des Moduls, erst nach erneutem anlernen … ist bekannt

nun gehts ans flashen…

Zigbee2MQTT:info  2021-01-29 22:47:57: Coordinator firmware version: '{"meta":{"maintrel":2,"majorrel":2,"minorrel":7,"product":2,"revision":20201010,"transportrev":2},"type":"zStack30x"}'
Zigbee2MQTT:info  2021-01-29 22:47:57: Currently 2 devices are joined:
Zigbee2MQTT:info  2021-01-29 22:47:57: 0x7cb03eaa0a0c49e6 (0x7cb03eaa0a0c49e6): AB3257001NJ - OSRAM Smart+ plug (Router)
Zigbee2MQTT:info  2021-01-29 22:47:57: 0x000d6ffffe115045 (0x000d6ffffe115045): LED1624G9 - IKEA TRADFRI LED bulb E14/E26/E27 600 lumen, dimmable, color, opal white (Router)

flashen hat funktioniert, aber leider ist der Fehler nach PowerDown immer noch vorhanend.

iobroker_biicii.de · January 29, 2021, 10:00pm

nun dürfen die Experten ran und herrausfinden, was der Unterschied zwischen der USB und der UART Version ist, da bin ich raus, ich habe lediglich beide Arten von Modulen hier liegen und konnte den Vergleich ziehen.

ps, ich möchte gerne das Aufsetz Modul verwenden, aber im Moment muss ich wohl oder übel die USB Version vorziehen. denn diese funktioniert.

mfG BC

pmayer · January 29, 2021, 11:04pm

Vielen vielen Dank für dein Testen.

Nur zum klarstellen, USB funktioniert komplett mit gleichen (USB vs UART) Firmware-Stand wie das UART-Modul?

iobroker_biicii.de · January 30, 2021, 8:46am

?!, das USB Modul benutzt zur Datenübertragung die Pins 12 (USB-) und 13 (USB+) der cc2538/92 Platine (Schaltplan liegt vor, werde ich scannen und zusenden, kein veröffentlichen, da geistiges Eigentum … usw.)

JH_2538_2592_ZNP_UART_20201010.hex
JH_2538_2592_ZNP_USB_20201010.hex

das sind die verwendeten Dateien. von hier:

was an der Firmware anders ist, das müssen die Programmierer der Firmware wissen (ich kann löten, LKW fahren und noch ein paar andere für die meissten nutzlose Dinge)
beim Programmieren bin ich raus

pmayer · January 30, 2021, 2:13pm

Thank you so much @iobroker_biicii.de for all the testing.

In the meantime I’ve tested some hardware tips from @malli. Namely Pull-Ups on RX/TX and 220Ω in series on RX/TX. Sadly none of the ideas made it work. Still have the cold-boot problem, as the LDO from the 5V rail rules out the reboot problem.

I’m tilted… out of ideas. At this point I think it must be something with the UART version of the firmware as, like @iobroker_biicii.de confirmed, the USB version works without problems.
Also, I think it’s not a hardware issue of the black CC2538 modules as this problem is present on testboards and customer boards.
I have a green one here for testing, but this had some other issues.

@iobroker_biicii.de could you possibly try to use the USB version as a UART one?
Schematics of my module are here: GitHub - codm/cc2538-raspberry-pi-module: ZigBee CC2538 Coordinator for direct use on the GPIO of the Raspberry Pi

Thank you all for your help. I hope we will solve this…
Cheers,
Patrik

trapperjohn · February 1, 2021, 6:39am

Then it seems to be an issue of the Texas Instruments ZStack implementation. The modifications done by MODKAMRU or JH are minimal and basically only enable/disable UART or USB via preprocessor directives. The implementation is inside the TI sources… Unfortunately a lot of details are only available as binary libs.

@pmayer Soldering an USB plug to the open pins should be worth a try

Adrian · February 1, 2021, 11:53am

Hi,

May I suggest also asking questions about cc2538 on TI forums?

Zigbee & Thread forum - Zigbee & Thread - TI E2E support forums

Some people giving answers there are very knowledgeable about both the hw and zstack.

pmayer · February 1, 2021, 12:23pm

Thank you @trapperjohn and @Adrian. I could talk @tsmt into checking the Z-Stack SDK and check what goes wrong with the nvram (probably) when using UART.

Sent him hardware for testing, so hopefully he can work on it this week.

dr_snuggles · February 3, 2021, 9:14pm

Hey guys,

First of all Thank you all for your testing and time you invest. It’s great to see that so many smart people helps us to figure this out.

I tried to understand what you did and maybe partly I understood. What I’m not fully aware of is do you have an idea or do we still have no clue why this happens?

Thanks again for the support and no pressure just interested

Felix

pmayer · February 3, 2021, 9:47pm

@tsmt will have a look into this in the next days. I’ve sent him some testhardware which should arrive today or tomorrow.

tsmt · February 3, 2021, 10:10pm

They arrived today, thank you! Will continue setting up my testing environment the upcoming days and keep you up2date here!

ijdqq · February 20, 2021, 5:25pm

Hi everyone. While waiting for a proper solution on firmware-level and given the assumption that the non-volatile memory is somehow corrupted on, or during boot-up from power outage: Can someone with a “test setup” maybe try if dumping the nvram of the cc2538 to json with zigpy-znp (GitHub - zigpy/zigpy-znp: TI CC2531, CC13x2, CC26x2 radio support for Zigpy and ZHA) after pairing of devices has finished and restoring it (also with zigpy-znp) from the backup after a simulated power outage/pulling the psu from the raspberry pi allows to circumvent the re-pairing process? I would be happy to try that on my own, but my zigbee-net is used “in production” including some battery powered devices in non-tool-free accessible places and my girlfriend is probably gonna kill me if I put the whole thing into dysfunctional state again.

pmayer · February 20, 2021, 5:27pm

Hey @ijdqq,

thank you for your support. @tsmt is currently working on the problem and has a test setup. I also can test if you wich.
Sadly I currenntly have any spare modules, otherwise I could have sent you one.

Best,
Patrik

tsmt · February 26, 2021, 6:09pm

hey guys

Sorry for leaving out updates here. I was pretty occupied the last weeks. So I wasn’t able to spend meaningful time on the topic and just did some babysteps to get myself going:
Until now, I was basically able to reproduce the issues known and build an environment for myself where I can make changes to the Z-Stack code, build and deploy it to the CC2538 module @pmayer provided.

Thanks, @ijdqq for the detailed update. I will get my hands on the topic again in the next days and test dumping and restoring the nvram with zigpy-znp after a power outage.