Closed slaesh closed 3 years ago
Would it be possible to automatically detect this? Which adapters require this?
Would be possible, could try to check the USB devices name.. My own CC2652 stick. Used for dev stuff, zigbee coordinator or thread border router..
Problem is that the CC2652's bootloader seems to don't have this magic start byte..
Will try to programm some custom name or something like this into the USB chip.. and trying to detect it then.
Thanks so far :)
Will come back to u ✌🏻
Koen Kanters notifications@github.com schrieb am Sa., 27. Juni 2020, 13:21:
Would it be possible to automatically detect this? Which adapters require this?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee-herdsman/pull/193#issuecomment-650546312, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANHZHR2K4IQ6JGROYFYFC53RYXI4JANCNFSM4OJMPOPA .
hey @Koenkk ,
detection will work!
my idea is now, to build generic "device-callbacks" .. so if a given "filter" matches (just a function), a set of given callbacks (maybe before-open, after-open, before-close, after-close, ...) will be called.
what do you think? :)
@slaesh what I'm also wondering, could there be an alternative for the magic CC2531 byte for the CC2652? Could you perhaps ask this to TI? (https://e2e.ti.com/)
asked! in the official docs is nothing..
RUN is not available:
maybe RESET will work, but if its a hard-reset we will go again into the BL ;D
that "magic byte" seems to be the EOF cmd.. so BL thinks that the upload process is done and starts the "newly" flashed APP.. could work on the CC2652 too, will test that..
anyway! i need another workaround.. cause the "normal" state of the RTS causes a permanent RESET on my board..
any idea how i could do that? :)
first way using the config.. the second using a generic device-callback-thing.. or dont u want to support any of those?
would love to see your great work running with my cool stick ;D
that "magic byte" seems to be the EOF cmd.. so BL thinks that the upload process is done and starts the "newly" flashed APP.. could work on the CC2652 too, will test that..
Please let me know.
Regarding setting DTR to false, involving @omerk here as I think this is also needed for the zzh-p (as I needed to unplug the DTR to make it survive the reset). Is that right?
So I feel there is a bit of a confusion here (or I might well be missing something): There is no "magic byte" to enter the BSL on CC1352/CC2652, you trigger it by pulling the BSL trigger pin (default: DIO_13
) low before resetting the device. @Koenkk on the "zzh-p" prototype you have, DTR
is connected to DIO_13
and RTS
is connected to RESET
directly, DTR
is probably set low as the device is powered up hence BSL being triggered. I would suggest adding a "set DTR
high and toggle RTS
(with final state high)" as a precautionary step as part of comms init to make sure device doesn't stay in BSL mode even if it was accidentally triggered.
This requires a bit more thought and experimentation before I lock down the zzh-p design...
Sidenote: Why DTR
/RTS
and not any of the other RS232 control signals? Well, cc2538-bsl.py
already uses these for autoreset so just sticking to that.
thats the point @omerk ! thanks for your resume! =) and exactly this is what my PR is actually addressing ;)
putting DTR to false and RTS to true, and then putting them both to false.. my board uses the same schematic: RTS --> RESET and DTR --> BL_EN
try it out, should do the trick ;)
this will reset the device on startup, but wont hold it in bootloader-mode or even worse, in reset-state.
My apologies, should have read the actual PR and not just the last few comments. At least we are all talking about the same thing though :-)
Would it be problematic if dtr
and rst
is always set to low on start? In that case we can get rid of the option.
depends on the timings i guess.. could lead to problems. will make some tests without doing it in two steps..
seems like it's working.. got a problem like once every 50 starts.. but do make it bullet-proof i would do it in two steps, just to be sure!
the 100% solution would be to make it configurable (BL_EN: high or low, RTS: reset or BL_EN, ...)
what do you think @Koenkk @omerk ? how will we proceed and who wants to do it? =)
i see those options:
option 1 will be done in several hours including tests and so on.. its easy! option 2 will take some more time, but not that much.. i guess option 1 would be better.. option 3 sound cool, would like to implement it.. but maybe there are some devices that cannot or wont change the serial-device's info.. could be an overkill for too less devices may support it..
I will test if it's possible to set dtr
, rst
and rtscts
to false by default and see if this works for various adapter (zzh, zzh-p, cc2531, cc2652r launchpad, conbee II)
I guess the launchpad isn't wired like this. but sure, test it! :) any time plans? can I support you?
@slaesh I've did some checks and the following works well for the zzh-p and doesn't break anything for existing supported adapters (launchpads, zzh, cc2531 1.2/3.0): https://github.com/Koenkk/zigbee-herdsman/pull/196 . Does this work for you?
closing this.. thanks!
Option for devices with automatic "reset to bootloader". Otherwise it will be held in RESET mode if the serial port is opened.
The "skipBootloader" is not working in this case. during writing this comment, i guess it would be better and more explicit to move my code into this function ;)
TODO: