Flashing and compiling issues #5
Comments
|
I use MSYS2 on Windows so I do not know if make will work with just windows command line or powershell. I'm going to try to work on a firmware solution that makes flashing more reliable. Otherwise a piece of hardware with diodes is likely required for more consistent flashing. But you can see an example that would hopefully work in sec 1.2.6.1 Application Circuit Diagram for ISP: |
|
Sorry it's actually: |
|
Hey, thanks for the feedback. I wired a microswitch inline to the ground side so I can click the power on and off and that made it much easier to cycle the power without disrupting the serial lines. I never did get STCGAL to program anything - it only got as far as erasing the flash...which did work as the device was then dead. After that I get serial port error: read timeout I had a lot more success with the STC ISP flasher (v6.91J). It detects the MCU every time (when I cycle the power with the microswitch), and claims to have programmed the device with the .ihx file (the activity log says all the right things and there us a little blue bar that progresses from zero to 100%). It did resurrect the one I killed with the STCGAL, so it is programming something...the light on the device again flashes as normal with a reed trip or tamper event. However, it doesn't seem to be transmitting anything. My Sonoff RF Bridges don't receive anything during these events. I don't have Portisch installed, so if the firmware is using another protocol, that would explain it, unless there is something else at play...do I need portisch to receive signals from this firmware? Thanks again, and sorry to take up so much time! |
|
That's progress at least. Does setting clock frequency fix it? EDIT: Stock timings and "protocol 1" timing from rc-switch/Portisch are now supported. |
|
Hi, no unfortunately setting the freq to 24 didn't seem to make a difference. There are lots of settings in the STC program, so perhaps there is something else that needs to be set. I tried to copy the settings listed in STCGAL, but some don't have the same names or aren't specific enough to copy into the official STC program. I tried STCGAL a bunch more times, and occasionally I get the incorrect frame start error but mostly the read timeout error. It could be a current leak from the serial pins, but it is odd that the official STC program seems to work every time (even if it does not transmit, it connects and flashes, and consistently resurrects the device after STCGAL has erased it). You'd think it would have the same issues. here is the STC official log from the last programming run: Checking target MCU ... Current H/W Option: MCU type: STC15W104 Adjusting frequency ... [0.765"] Re-handshaking ... Successful [0.125"] H/W Option upgrade to: MCU type: STC15W104 . Set frequency: 24.000MHz Complete !(2023-01-16 14:33:43) |
|
OK it's a little confusing because I am not sure how to reset to default settings in stc isp. Hardware do not enable Watch-Dog-Timer |
|
My output: Checking target MCU ... Current H/W Option: MCU type: STC15W104 Adjusting frequency ... [0.750"] Re-handshaking ... Successful [0.172"] H/W Option upgrade to: MCU type: STC15W104 . Set frequency: 24.000MHz Complete !(2023-01-16 14:13:41) |
|
Also do you know if you have the Sonoff hardware version v1 or v2? |
|
Wanted to share that I have one of the newer Sonoff RF bridges (v2.2) and am using the hack you mentioned in your README. I'm running ESPHome, not Tasmota. I can confirm that I'm seeing RCswitch protocol 1 codes on my Sonoff bridge with your firmware. I did have to increase the transmission count to 8 to increase the chance of a good code. I think 433mhz is busy/noisy in my area (or the hack causes some noise) as both the stock firmware and your firmware often send truncated codes along with good ones, and rare cases none would match (the hearbeat, which I enabled, will help keep things in sync but hopefully doesn't kill batteries). |
|
Ah, ok. I have the r2v1 hardware, but I don't run Portisch. I tried it once but the raw format was more trouble than it was worth to try and decode for door and motion sensors in home assistant. I don't use it for anything else so there wasn't much to be gained (and the RF noise is constant with raw signals). I was hoping with new firmware that the heartbeat could help indicate when a battery has died. I capture the battery low signals but in the stock firmware they are only sent once until the device is rebooted and the battery voltage crosses the threshold again (it's the crossing that triggers, not <). Thanks again for the time you've spent on this - it's really great that you've figured it out and it will potentially be useful in other 433 devices that I'm sure use the same chip. |
@mmotley999 Would you be willing to test the "...StockTimings.ihx" release file with your bypassed receiver? |
|
I had to add "-P st15" as shown below for the flashing to work. ~/stcgal-patched/stcgal.py -p /dev/ttyUSB0 -P stc15 -l 1200 -b 1200 -t 24000 ReedTripRadio.ihx Cheers |
|
README has been updated to explain flashing via make and manually. |
Hello, thanks for your work on this - I have been using this sensor for a while so I am excited to try a new firmware on it...but...
When I try to flash the prebuilt binary the flash tool (STCGAL) stalls at waiting for MCU.
When I try to compile the binary and flash using make, the compile crashes out with a problem with a problem with patsubst in 1-mcu-settings.mk (line 114), after I updated the paths in the makefile so it could find things (before that it couldn't find anything). I can't see any obvious problems with the syntax.
I've tried on a linux machine and a windows machine with same result for the prebuilt flash. I've checked and I have the 104 variant chip on the sensor with the tamper detection, so it is the same as you have mentioned (same board rev based on the photos as well).
SDCC won't work on the linux machine for some reason, so my data point is only the windows machine for compiling. That could be a windows issue if you built the makefile etc. for linux, so perhaps not surprising. When I get a minute I'll try it on another linux box.
I've flashed lots of chips in my day, so Tx goes to Rx etc...equally, I have compiled a variety of things before.
Before I beat my head against the wall for a while longer, do you have any advice? Is there a library I might be missing or something?
Thanks in advance!
The text was updated successfully, but these errors were encountered: