add feature to do not invoke devices bootloader.

[slaesh]

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:

• - clarify naming convention for settings
• - clarify if it's possible to use serialport-object instead of seperate arguments
• - implement settings pass through-part in zigbee2mqtt
• - move into "skipBootloader" method if it will be approved!
• - add tests

[Koenkk]

Would it be possible to automatically detect this? Which adapters require this?

[slaesh]

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 <#193 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANHZHR2K4IQ6JGROYFYFC53RYXI4JANCNFSM4OJMPOPA> .

[slaesh]

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? :)

[Koenkk]

@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/)

[slaesh]

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

[slaesh]

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

[Koenkk]

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?

[omerk]

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.

[slaesh]

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.

[omerk]

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

[Koenkk]

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.

[slaesh]

depends on the timings i guess.. could lead to problems.
will make some tests without doing it in two steps..

[slaesh]

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? =)

[slaesh]

i see those options:

1. just put them to false (two-stepped) in case that "rtscts" is false
2. add a new option in our configuration for this behavior
3. build a generic device-callback thing based on the serial-device-infos

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..

[Koenkk]

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)

[slaesh]

I guess the launchpad isn't wired like this. but sure, test it! :)
any time plans? can I support you?

[Koenkk]

@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): #196 . Does this work for you?

[slaesh]

#196 works just fine!

closing this.. thanks!