B3603 DC/DC Buck Converter mini review and how the SET key could be fatal...

[ticpu]

Ouch, that 2kb limit will really impair the plan I had to have a CLI on these :-/   I'm still waiting for a second board + programmer to check this out but you're right, a binary or really short commands protocol will be the only way to get something going on these.

Edit: and on my side, the fact that this is mostly programmable on Windows is another problem for me.

[flex]

Just a quick update: I reversed engineered the top board. The buttons are really strange . Maybe someone could (dis)confirm that part of the schematic? I don't have an oscilloscope right now, but I would suppose that the gpio pins are toggling to read all buttons...

Another thing: I just checked the Datasheet, because 2K is very limiting and it says: STM8S003F3 has 8K flash. (See STM8S003K3 STM8S003F3 Datasheet page 1 or page 9)
Actually the only 2K Flash STM8 is the STM8L101F1 (see http://www.st.com/web/en/catalog/mmc/FM141/SC1244).

@baruch: how did you determined the 2K flash you were talking about?

btw: I was able to use stm8flash under linux with my stlinv2 clone. (But the readout failed due to the protection).

Update: the bottom board had the labels lost. I added them again.
Update: see newer post for updated schematic

[baruch]

Edit: and on my side, the fact that this is mostly programmable on Windows is another problem for me.

I could program it from Linux with stm8flash, if you can help with figuring how to remove the ROP bit with stm8flash your road should be clear to work in Linux/Mac as you please. I believe that the first use of the Windows program upgraded the firmware such that stm8flash does not work anymore with the new firmware. I plan on ordering another programmer to check that theory.

[baruch]

Just a quick update: I reversed engineered the top board. The buttons are really strange . Maybe someone could (dis)confirm that part of the schematic? I don't have an oscilloscope right now, but I would suppose that the gpio pins are toggling to read all buttons...

At least the two left buttons (SET, DOWN) triggered separate pins on the STM8. One of the others (I forgot already) triggered one of the pins of the UART. They were going from high to low when I pressed the button.

Another thing: I just checked the Datasheet, because 2K is very limiting and it says: STM8S003F3 has 8K flash. (See STM8S003K3 STM8S003F3 Datasheet page 1 or page 9)
Actually the only 2K Flash STM8 is the STM8L101F1 (see http://www.st.com/web/en/catalog/mmc/FM141/SC1244).

@baruch: how did you determined the 2K flash you were talking about?

My bad, the flash is 8K, I somehow misread the code size when it failed.

btw: I was able to use stm8flash under linux with my stlinv2 clone. (But the readout failed due to the protection).

There is a report that stm8flash can't clear the ROP which is why I used windows and since then stm8flash doesn't work for me. I would suggest finding a way to erase the ROP with stm8flash if possible. I'm just not up to it to reverse engineer the usb protocol of the new firmware.

[baruch]

Just a quick update: I reversed engineered the top board. The buttons are really strange . Maybe someone could (dis)confirm that part of the schematic? I don't have an oscilloscope right now, but I would suppose that the gpio pins are toggling to read all buttons...

At least the two left buttons (SET, DOWN) triggered separate pins on the STM8. One of the others (I forgot already) triggered one of the pins of the UART. They were going from high to low when I pressed the button.

A few questions:

1. Pin 10 of the MCU goes to the two leds, how are they going to be controlled separately? We do see only one of them turning on at a time.

2. Pins 11 & 12 of the MCU, both come from VCC and driven by outside but from what I found so far, pin 11 seems to be CV/CC indication and pin 12 is output enable.

3. I'd have to check out that complex button setup, seems like it will require changing the pinout settings constantly from input to output to probe each pin at a time, if done fast enough it can work and I can think that it is possible that what I saw on the UART lines was just noise and not a real signal but I didnt probe that yet since I use the UART for debug and didn't control leds or lcd yet to enable a better probe into that.

[baruch]

@flex, one more thing.

That's an amazing work you did with the reverse engineering, if you do a video of that work in Dave's reverse engineering style I'd be sure to watch it!

Some of the lines go under a chip, others are completely obscured and I couldn't for the life of me keep a straight track of where each line goes at any time. The best I could hope for was to use my cheap multimeter to buzz points for connectivity.

[plazma]

A few questions:

1. Pin 10 of the MCU goes to the two leds, how are they going to be controlled separately? We do see only one of them turning on at a time.

Drive the pin low to enable the high side led. Drive the pin high to enable the low side led.

Nice switch and led tricks to reduce the needed pin count.

[flex]

One of the others (I forgot already) triggered one of the pins of the UART. They were going from high to low when I pressed the button.

3. I'd have to check out that complex button setup, seems like it will require changing the pinout settings constantly from input to output to probe each pin at a time, if done fast enough it can work and I can think that it is possible that what I saw on the UART lines was just noise and not a real signal but I didnt probe that yet since I use the UART for debug and didn't control leds or lcd yet to enable a better probe into that.

I just checked the buttons again and couldn't find any connection to RX/TX. The button solution looks a little crazy. I also think that changing the pinout settings is the only option to read them.

2. Pins 11 & 12 of the MCU, both come from VCC and driven by outside but from what I found so far, pin 11 seems to be CV/CC indication and pin 12 is output enable.

I think you forgot the question here?
Anyway, I think pin 11 of the mcu (pin7 of the pin header) is driven by the bottom board. There is no reason for R18 with this bottom board, maybe there is one with an open collector output. To proof my point, I just desoldered the R18 and it still works.
Pin 12 of the mcu (pin6 of the pin header) is driven by the top board to enable the output. Since it is active low the R16, R17 pull up ensures that the device is off even without the MCU. As soon as you pull it down, the out and the led is enabled.

That's an amazing work you did with the reverse engineering, if you do a video of that work in Dave's reverse engineering style I'd be sure to watch it!

Some of the lines go under a chip, others are completely obscured and I couldn't for the life of me keep a straight track of where each line goes at any time. The best I could hope for was to use my cheap multimeter to buzz points for connectivity.

There is no secret in my reverse engenerring. All I did was a combining a scan of both pcb sides. After that I tried to draw all the trace of the bottom layer at the top layer. Since some parts weren't visible I did some educated guesses an tested them with my multimeter (beep). Now  I transfered that to a CAD prog (Kicad). You just need some patience and the better your guesses the faster you are.  E.g. The buttons took forever, because I didn't expected that strange schematic for them.

[baruch]

2. Pins 11 & 12 of the MCU, both come from VCC and driven by outside but from what I found so far, pin 11 seems to be CV/CC indication and pin 12 is output enable.

I think you forgot the question here?
Anyway, I think pin 11 of the mcu (pin7 of the pin header) is driven by the bottom board. There is no reason for R18 with this bottom board, maybe there is one with an open collector output. To proof my point, I just desoldered the R18 and it still works.
Pin 12 of the mcu (pin6 of the pin header) is driven by the top board to enable the output. Since it is active low the R16, R17 pull up ensures that the device is off even without the MCU. As soon as you pull it down, the out and the led is enabled.

About pin12, if it is driven from the MCU, how comes it is connected to VCC? (at least in the version I have)

For pin 11, you mark it as coming from VCC as well but it's not always on, I can get sometimes when it goes down. Initially there was a thought it might be a power good signal but I don't think it's the case.

I'm mostly baffled by the connection you make to VCC it seems to me as it implies that it gets driven from outside. I might also be misreading it.

[flex]

About pin12, if it is driven from the MCU, how comes it is connected to VCC? (at least in the version I have)

Are we talking about the same pin 12? I'm talking about the PB4 of the STM8 (pin12 of the TSSOP package directly connected to pin 6 of the pin header). This pin has a pull up to VCC and also a LED. This is the "not Output enable" (~OE) pin and is driven by the MCU.

For pin 11, you mark it as coming from VCC as well but it's not always on, I can get sometimes when it goes down. Initially there was a thought it might be a power good signal but I don't think it's the case.

Same with pin11, are we talking about the same pin? PB5 of the STM8 (pin11 of the TSSOP package) is directly connected to pin 7 of the pin header and has a 10k pull-up resistor (that is not really needed). This pin indicates CC/CV and is driven by an opamp on the lower board and can be read by the MCU.

I'm mostly baffled by the connection you make to VCC it seems to me as it implies that it gets driven from outside. I might also be misreading it.

I'm not sure if we are talking about the same thing  . If you think your PCB is different to my schematic, please tell the exact position (like "I think pin12 of the stm8 is directly connected to VCC and doesn't have a pullup"). That way I can easily verify the schematic.

[baruch]

We are talking about the same pins exactly. I don't think the PCB is different. I may not understand than how the pull-up works. It should be noted that I'm a software guy and hardware is merely a side hobby of recent times so even the most obvious things in hardware may not be understood by myself. I've learned a lot in a short time but I still know a lot less than I need :-)

[baruch]

As for the double leds, I found that I can drive the three states we care for:
Green ON: PA3 OUTPUT=LOW CR1=1
Orange ON: PA3 OUTPUT=HIGH CR1=1
Both OFF: PA3 OUTPUT=HIGH CR1=0 or INPUT

CR1 means 1=push-pull 0=open-drain

[flex]

Let's take a look at pin 12.
a) pin 12 in "high impedance" mode (as it is at startup). The two resistors R16, R17 pull up the voltage of pin 12 (and the ~OE Pin) to VCC (we can assume inf resistance for the ~OE input pin and pin 12).
b) pin 12 output low. Now there is about 0V at pin12 (imagine a voltage divider with the lower resistor 0R). That means the potential of the ~OE Pin is 0V. This also means that a small current is sinked from VCC through the Out LED into pin 12.

I put an attachment to explain the idea.

btw. The output pin uses a tristate logic. So it has "low", "high", "high impedance". There usually also is an pull up/down that can be enabled. The drawing is an simplification. The chip has a mosfets integrated to do the switching. I didn't draw "high", "pull-up", etc.

[flex]

As for the double leds, I found that I can drive the three states we care for:
Green ON: PA3 OUTPUT=LOW CR1=1
Orange ON: PA3 OUTPUT=HIGH CR1=1
Both OFF: PA3 OUTPUT=HIGH CR1=0 or INPUT

CR1 means 1=push-pull 0=open-drain

This was expected, as plazma already said. 

[baruch]

This was expected, as plazma already said. 

Yes, of course. I just had to translate it to actual hands-on terms for myself.

As for the pins 11/12, the thing that bothers me in the schematics is that the top board schematics shows that the pins are connected to VCC and do not show that it is connected to the bottom board parts as well.

[flex]

I think you are reading the schematic wrong 

All signals with the same label are connected.

That means pin 12 oft the stm8 is connected by the label 6 to the pin 6 of the pin header and this pin header is connected to the lower part.

This way there is no need to draw all the wires (this can get quite confusing). This is the same concept as with the power signals "GND", "VCC", etc.

[baruch]

I'm using my pin testing firmware (https://github.com/baruch/STM8_reverse_engineering_aid) and when I press the down button I get that PA1 goes from 1 to 0 and back when I release it.

In the schematics published it should be connected to PD1.

[baruch]

I think you are reading the schematic wrong 

All signals with the same label are connected.

That means pin 12 oft the stm8 is connected by the label 6 to the pin 6 of the pin header and this pin header is connected to the lower part.

This way there is no need to draw all the wires (this can get quite confusing). This is the same concept as with the power signals "GND", "VCC", etc.

I'm fast to understand when I get repeated and slow explanations :-)

Does it also mean that the connection to pin 6 of the header from pin 12 is near the mcu?

[flex]

Does it also mean that the connection to pin 6 of the header from pin 12 is near the mcu?

I'm sorry, but I have not idea what you are asking. I'm not a native English speaker. What do you want to say with "is near the mcu"? I suppose you can't mean that it in the "short distance" sense.

However as I said pin 12 (stm8) is directly connected to pin 6 (pin header). Even if there is no wire. The label does the trick

I'm using my pin testing firmware (https://github.com/baruch/STM8_reverse_engineering_aid) and when I press the down button I get that PA1 goes from 1 to 0 and back when I release it.

In the schematics published it should be connected to PD1.

I can't see that it is connected to PA1. Are you sure about your code? Please try yourself by using the multimeter.

Update: just added an image to illustrate the down button connections
Update2: just enhanced the image

[jaxbird]

Did anyone evaluate the dynamic performance of this device?

E.g. set output to 5V 1A, then hook up a scope, short it and capture the behavior. followed by a release of the short and capture the behavior.

And also capture on and off switching between e.g. 100mA load and 1A load. With CC limit set above 1A.

[baruch]

Does it also mean that the connection to pin 6 of the header from pin 12 is near the mcu?

I'm sorry, but I have not idea what you are asking. I'm not a native English speaker. What do you want to say with "is near the mcu"? I suppose you can't mean that it in the "short distance" sense.

However as I said pin 12 (stm8) is directly connected to pin 6 (pin header). Even if there is no wire. The label does the trick

I'm not a native English speaker either but we don't have another common language, unless you speak Hebrew :-)

Let me attempt to explain my misunderstanding differently. In the diagram you showed me, there are three connections to the pin 12 circuit, there is VCC, pin 12 and ~OE. How do I understand from the schematics where each of them is connected?

EDIT: Looking now at the schematic, the small schematic for pin 12 and my question and it is obvious where I was mistaken, the small schematic shows a straight line with no component between pin 12 and ~OE. Now I understand what you meant above that the pin 12 is directly connected to pin 6 on the connector.

I'm using my pin testing firmware (https://github.com/baruch/STM8_reverse_engineering_aid) and when I press the down button I get that PA1 goes from 1 to 0 and back when I release it.

In the schematics published it should be connected to PD1.

I can't see that it is connected to PA1. Are you sure about your code? Please try yourself by using the multimeter.

Update: just added an image to illustrate the down button connections
Update2: just enhanced the image

You were right, my program had a bug.

[flex]

I just did a small hardware mod 

One problem with the b3603 is, if you connect power, the output will be on for a small period of time (even if the unit is turned off). This is a hardware bug, and happens because the 5V switching reg is starting up too slowly to disable the LM2596 from the beginning.

Solution: solder an additional pull up resistor between pin6 (easier access tha ~OE) and Vin+ on the bottom board to ensure that the output is off and remove R16 on the top board. This resistor has to be at least 10k, because otherwise you could exceed the absolute max injected current of the stm8 with 40V Vin. I used a 100k resistor. R16 has to be removed, because otherwise we'll get an unintended voltage divider.

Did anyone evaluate the dynamic performance of this device?

If noone does it, I'll test it at the end of next week. Btw we should be able to tweak the performance by changing R34, R35, C14 (current) and R20, R19, C10 (voltage).

@baruch I think you got the idea behind my drawing

I updated the schematic again, because the bottom board had lost it's component labels.

[Rick Law]

Just a quick update: I reversed engineered the top board. The buttons are really strange . Maybe someone could (dis)confirm that part of the schematic? I don't have an oscilloscope right now, but I would suppose that the gpio pins are toggling to read all buttons...
...

I double checked twice.  Your schematic looks right with the button connection!

- With D5-pin3 (double schottky) 3 goes top-side but under the button, then come back down to bottom-side under the same button.  The  top-side trace being under the button is not visible but DMM confirmed that the two holes are connected which subsequently connects to the OK button.

- D5-pin2 going to the SET button is a visible trace.  It subsequently go top-side on a visible trace that went back to the bottom-side under the MCU chip.  Since under the MCU the trace's path is not visible, but position suggests MCU-pint17 and DMM confirms MCU-Pin17 connects to MCU pin17 exactly as your schematic shows.

So, in so far as I can see, your schematic for the buttons is confirmed; AND they are indeed strange.

By-the-way

In an earlier post (where I purposed using header pin numebrs) I said no visible TxD/RxD connects HeaderPin 15 and 16 (Rx/Tx) to the MCU's Rx/Rx.  I found the traces connecting them to UART1 RxD and TxD.  I reedited that reply also to avoid confusion.

Rick

[flex]

@Rick Law or anyone else with an scope: Could you check the PWM frequency at pin 4 and 5? I don't have any scope nearby.

In an earlier post (where I purposed using header pin numebrs) I said no visible TxD/RxD connects HeaderPin 15 and 16 (Rx/Tx) to the MCU's Rx/Rx.  I found the traces connecting them to UART1 RxD and TxD.  I reedited that reply also to avoid confusion.

They are also in my schematic

So, in so far as I can see, your schematic for the buttons is confirmed; AND they are indeed strange.

thx for checking. This is an interesting design choice.

[Asim]

@Rick Law or anyone else with an scope: Could you check the PWM frequency at pin 4 and 5? I don't have any scope nearby.

1.293K Hz based on my Rigol DS1052E

I have been wanting to replace the interface on that module. with the pinout mapping provided I think I can do it.

my Ideal interface would include OLED display to display Vset,Iset,Vout,Iout. one rotary encoder with built in switch to vary the set voltage and current ( switch to change from voltage to current and vice versa) . one push button to switch the output on & off. 2 leds for CC & output ON.