CC2538 und CC2530+CC2592 ZigBee Raspberry Pi Modul

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, :confused: 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.

image

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

  1. 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 :slight_smile:

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.

1 Like

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

1 Like

Vielen vielen Dank für dein Testen.

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

?!, 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 :wink:

1 Like

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

1 Like

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 :wink:

2 Likes

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.

2 Likes

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.

5 Likes

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

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

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

3 Likes

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.

1 Like

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

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.

3 Likes

Currently discussing the problem in the jethome github:

@tsmt, could you check what @ijdqq suggested here?

Didn’t try what ijdqq suggested yet, but it seems that we got a solution in github:

Link to Solution

Do this:

Stop z2m
Delete z2m backups
Clean the NV_MEM script zigbee2mqtt/zStackEraseAllNvMem.js at master · Koenkk/zigbee2mqtt · GitHub
Cold restart stick 2538
Start z2m
Set up a new network, add devices.
Stop z2m and check that the NIB table is 116 bytes. If so, then your network will work stably.

Use the firmware for 2538 20201010.

After this, the NIB table was 116 bytes for me and cold restarts, power losses etc. were not a problem anymore. I will try to put this into some kind of script, but here are the commands I run on my machine assuming

Warning: you will lose all pairings of course.

device: /dev/ttyAMA0
z2m installation: /opt/zigbee2mqtt/

systemctl stop zigbee2mqtt
mv /opt/zigbee2mqtt/data ~/backup/zigbee2mqtt
mkdir /opt/zigbee2mqtt/data
cp ~/backup/zigbee2mqtt/configuration.yaml /opt/zigbee2mqtt/data/configuration.yaml
[Wipe all network related data from /opt/zigbee2mqtt/data/configuration.yaml]
node /opt/zigbee2mqtt/scripts/zStackEraseAllNvMem.js /dev/ttyAMA0
shutdown -h now
[unplug raspberry, replug it]
[boot, start zigbee2mqtt, re-pair all devices]

Try with one or two devices first If you have done this, then cold restart (unplug power) and test if the devices are still available. If yes, connect the rest of your network.

1 Like

Just to mention.

To me the problem seems to be that the initial firmware either doesn’t make sure that the NVram is in a defined state after flashing, or it has some weird pre-flashed values in there.

1 Like

Thank you so much @tsmt. If this indeed will solve the problem I will of course do the nvram-reset after flashing the firmware and before sending them out.

Cheers!

1 Like

Confirmed fixed, see

1 Like

hey guys,

thx for your invested time to fix this issue.

Maybe there is somebody who can write an low level description step by step to fix. german would be great. english also ok.

Thanks again everybody.

Felix