reset_pin_enabled state not being retained?

[mightymos]

I'm trying to set the reset_pin_enabled target option. However it does not ever appear to be set to true after repeated power cycles/isp reads.

I do know that options like eeprom_erase_enabled persist after erasing chip and so remain true until cleared.

I also tried driving the pin high anyway but it does not seem to force a reset. I have a CP102x based usb to uart with output DRT pin which I inverted with 2N2222 transistor. This makes the reset pulse active high, but again no reset appears to occur.

What am I missing?

[area-8051]

Does this happen with a STC15W104 or another MCU? It's probably a bug in the protocol implementation. It has been reverse engineered, so this kind of bug is to be expected. The flashing protocol of the STC8H has been documented (unfortunately in Chinese), I'll see if I can find some useful information there.

[area-8051]

Another easy to test idea: look at the autodetected protocol. If it's stc15, try and add -P stc15a to your command line; if it's stc15a, try with -P stc15. One of the differences is that the value of the reset_pin_enabled flag has the opposite meaning in both protocols... If none work, add -D to your command line (without the -P option) and post the output. If one works, tell me which and I'll update the source code.

[mightymos]

For now I'm working with the STC15W101 since I removed radio circuitry from that board to avoid interfering with reset pin (radio was not working here anyway). I've normally been specifying -P stc15 option explicitly. I tried -P stc15a option but I get strange Target frequency: 8158.629 MHz listed so I assume that's never going to work.

Here's debug output:

$ ~/stcgal-patched/stcgal.py -p COM3 -D -b 19200 -o reset_pin_enabled=true -e
Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 8F C0 5F 87 F7 3B 9F 00 52 9E 00 FF 00 CC 00 00 7
2 54 00 F2 A1 05 06 70 87 02 14 18 1A 1C 22 80 14 04 04 E5 EA 59 FF FF FF 19 10 21 01 11 9A 16
done
Protocol detected: stc15
Target model:
  Name: STC15W101
  Magic: F2A1
  Code flash: 1.0 KB
  EEPROM flash: 4.0 KB
Target frequency: 5.414 MHz
Target BSL version: 7.2.5T
Target wakeup frequency: 36.800 KHz
Target options:
  reset_pin_enabled=False
  clock_source=internal
  clock_gain=high
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=256
  low_voltage_reset=True
  low_voltage_threshold=3
  eeprom_lvd_inhibit=False
  eeprom_erase_enabled=True
  bsl_pindetect_enabled=False
  por_reset_delay=long
  rstout_por_state=high
  uart2_passthrough=False
  uart2_pin_mode=normal
  cpu_core_voltage=low
Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80
00 C0 00 0A D3 16
<- Packet data: 46 B9 68 00 20 00 0C 00 4A 00 68 00 86 00 8B 00 D1 01 0D 01 21 01 99 02 0C 01 C6 02 75 02 CA 06 0A 16
-> Packet data: 46 B9 6A 00 20 00 0C 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 62 40 63 40 64 40 65 40 66 40 67 40 0A EC 16
<- Packet data: 46 B9 68 00 20 00 0C 00 5E 00 5E 00 59 00 5E 00 5E 00 5E 01 7B 01 80 01 80 01 80 01 85 01 85 05 CE 16
5.414 MHz
Switching to 19200 baud: -> Packet data: 46 B9 6A 00 0E 01 63 40 FB 80 F9 40 81 04 51 16
<- Packet data: 46 B9 68 00 07 01 00 70 16
-> Packet data: 46 B9 6A 00 0B 05 00 00 5A A5 01 79 16
<- Packet data: 46 B9 68 00 07 05 00 74 16
done
Erasing flash: -> Packet data: 46 B9 6A 00 0B 03 00 00 5A A5 01 77 16
<- Packet data: 46 B9 68 00 0E 03 F2 A1 C4 0C 02 22 15 03 15 16
done
-> Packet data: 46 B9 6A 00 07 82 00 F3 16
Disconnected!

[area-8051]

I can reproduce the problem on an STC15W408AS, it will make troubleshooting much easier. :)

[mightymos]

Here's debug output for STC15W104. Thank you for looking into it.

$ ~/stcgal-patched/stcgal.py -p COM3 -D -b 19200 -o reset_pin_enabled=true -e
Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 8D 1D 63 86 F7 BB 9F 00 A6 1D 00 FF 00 CC 00 00 7
2 54 00 F2 A4 05 06 70 86 02 18 1C 1F 20 29 80 14 10 04 E8 EA 5E BF FF FF 22 05 24 01 11 3A 16
done
Protocol detected: stc15
Target model:
  Name: STC15W104
  Magic: F2A4
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 10.886 MHz
Target BSL version: 7.2.5T
Target wakeup frequency: 36.125 KHz
Target options:
  reset_pin_enabled=False
  clock_source=internal
  clock_gain=high
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=256
  low_voltage_reset=True
  low_voltage_threshold=3
  eeprom_lvd_inhibit=True
  eeprom_erase_enabled=True
  bsl_pindetect_enabled=False
  por_reset_delay=long
  rstout_por_state=high
  uart2_passthrough=False
  uart2_pin_mode=normal
  cpu_core_voltage=low
Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80
00 C0 00 0A D3 16
<- Packet data: 46 B9 68 00 20 00 0C 00 4A 00 68 00 86 00 90 00 D1 01 0D 01 21 01 9E 02 0C 01 C6 02 75 02 CA 06 14 16
-> Packet data: 46 B9 6A 00 20 00 0C 56 80 57 80 58 80 59 80 5A 80 5B 80 5E 40 5F 40 60 40 61 40 62 40 63 40 09 6C 16
<- Packet data: 46 B9 68 00 20 00 0C 00 B8 00 B8 00 BD 00 BD 00 BD 00 BD 01 7B 01 7B 01 80 01 7B 01 80 01 80 07 EF 16
10.886 MHz
Switching to 19200 baud: -> Packet data: 46 B9 6A 00 0E 01 60 40 FB 80 F9 40 81 04 4E 16
<- Packet data: 46 B9 68 00 07 01 00 70 16
-> Packet data: 46 B9 6A 00 0B 05 00 00 5A A5 01 79 16
<- Packet data: 46 B9 68 00 07 05 00 74 16
done
Erasing flash: -> Packet data: 46 B9 6A 00 0B 03 00 00 5A A5 01 77 16
<- Packet data: 46 B9 68 00 0E 03 F2 A4 C4 B4 1E 16 E0 04 9B 16
done
-> Packet data: 46 B9 6A 00 07 82 00 F3 16
Disconnected!

[area-8051]

So I found the explanation: options are modified only during programming. This means that you should add them to the command line in your Makefile, for instance by adding: STCGAL_OPTIONS := -a -o reset_pin_enabled=true before or after the ISP_PORT line.

[mightymos]

Thank you, the '101 is resetting now (with radio removed). I'm not sure yet if the '104 boards will cooperate since the reset pin is there used to enable power to the radio chip. Apologies I have a few questions...

Can the processor switch reset pin from input to output even with target option set (sec. 2.2.1)? How do we change pin mode using HAL GpioConfig during execution?

I still get some timeouts or frame errors when resetting '101 with DTR pin. It seems to be on the trimming step though I did not give -t flag. Is it possible to disable trimming to test further?

[area-8051]

Unfortunately, the only way to switch between the reset function and the GPIO function is through flashing, there's no SFR to control this - which makes sense, because if you use it as a reset pin, you'll have to connect an RC circuit to this pin to properly initialise the MCU, so this pin won't be available for I/O.

If you need to change a GPIO pin mode during execution, you can just change its pinMode and configure it again, that is: someGpioCfg.pinMode = SOME_OTHER_MODE; gpioConfigure(&someGpioCfg);

Again, external circuits are connected to GPIO pins, so it's difficult to imagine a use case for this, but it's programmatically possible.

Finally, the -t option is absolutely required with chips using an internal RC oscillator. Like the -o options, the clock frequency is one of the project's configuration parameters, since it directly affects the whole device's operations.

[mightymos]

Thanks, I think that clears up a number of things. The frustrating part is that when cycling power for flashing I seem to get lots of timeouts until finally it works. I'm concerned that the usb to uart is parasitically powering the STC15 by data pins or possibly something else is going on. Anyway I may need to make a little adapter board or maybe just disable the beep speaker on my power supply...

Thanks again.

[area-8051]

To avoid parasitical powering, you can use Schottky diodes (e.g. BAT43 or BAT85), exactly how depends on your schematics. Also, when powering a circuit through USB, I've learned to always check the supply voltage. With an STC15W, you won't have any issue with the MCU, but maybe with the circuits around it. I have an example with an LCD display designed for 5V and a USB port delivering only 4.4V...