Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to select Voltage on ZY12PDN post upgrading with zy12pdn-oss Master branch #4

Open
ncounterspecialist opened this issue Dec 13, 2021 · 14 comments

Comments

@ncounterspecialist
Copy link

Hi,

I have bought ZY12PDN which was working perfectly, i wanted to add current limit circuit so that Source charger 9Mac 61W) doesn't trip. But after upgrading with this code, ZY12PDN no longer able to select any voltage than 5V. Led color still changes on pressing the button.

On debugging i found that sourceCaps array was empty. Can you please help me with this?

@manuelbl
Copy link
Owner

That's difficult to diagnose without access to the real hardware.

Since the LED colors still change, it's very unlikely that sourceCaps is empty. More likely, it's an artifact of debugging.

How do you debug? The debug pins overlap with the I2C pins. So with the regular ZY12PDN it's not possible to debug it once a charger has been connected. Well, you can. But the I2C communication will no longer work.

@ncounterspecialist
Copy link
Author

Thanks for lookikg into this. I was able to fix the problem by changing the mcu frequency to 32mhz in platform.ini file, it seems the one i bought had hk mcu (it's chinese clone of stm32) and works on 32mhz.
Debugging: I persisted all the parameters that I was interested into eeprom and then read it through STMCubeProgram software. Code is still not working for the power sources which can act as both source and sink. I still have to debug that, but i thought this maybe the limitation of the code.

@manuelbl
Copy link
Owner

The code is written for a device that acts as a power sink only. But it should be capable of handling both power sources and dual role devices at the other end of the USB cable. I will look into it...

@manuelbl
Copy link
Owner

I think a can reproduce the problem with a laptop. But it'll take me some time to setup my debugging for investigating it in more detail.

@manuelbl
Copy link
Owner

I have to correct myself. The tests with the laptop are working correctly, and are not very helpful as the laptop only outputs 5V. So I cannot reproduce it.

What exact device do you have problem with? I assume it's not the Apple 61W power supply anymore as it does not support dual role.

When writing debug information to the EEPROM: Are you sure it does not take too long? If you exceed certain time limits, the power supply will start over with the communication. This is another reason it's so difficult to debug.

For debugging, you can define the build flag -D PD_DEBUG and then use debug_log(). It will write the debug output as serial output to PA2 (you need to solder a wire to it). The baud rate is 115,200 bps. This debugging is quite safe as it uses DMA and is unlikely to interfere with timing.

@Leseratte10
Copy link
Contributor

Looks like I'm having a similar issue.

Tried two different PD chargers from Anker, with stock firmware all four of my boards worked fine.

Then I broke the first board because I fucked up soldering and ripped off two of the programming pins.
Then I broke the second board because I accidentally fried it by connecting 3.3V to the GND pin.

I've successfully flashed the other two boards with the (unmodified) firmware, but when I now connect them to a charger they only ever output 5V. The LED changes correctly when I press the button, but the output voltage doesn't.

I don't think my soldering skills are good enough to solder a wire to the PA2 debug pin to get any logs.
I tried adding board_build.f_cpu = 32000000 to the platformio.ini file (no idea if that's the correct parameter, just found that on Google) but that didn't help either.

Any other ideas?

@manuelbl
Copy link
Owner

I've tested a variety of chargers and cables and experienced the described effect once. But I couldn't repeat it.

So there is likely an issue with the firmware (e.g. an incorrect timing). But it will be very difficult to find it. What's the exact charger model you're experiencing the issue?

Chaning board_build.f_cpu most likely has no effect at all.

@Leseratte10
Copy link
Contributor

Leseratte10 commented Dec 12, 2022

"exact charger model" is a bit of a difficult question with Anker products as they keep making new revisions of products under the same name :P

The first one is a variant of the Anker PowerPort+ Atom III that came with one of my Anker powerbanks and has only a USB-C port instead of a USB-C and a USB-A port.

The other charger I tested is the Anker PowerPort Atom III Slim, the variant with two USB-C and two USB-A ports (which according to Anker also supports PPS).

I also tested the Chicony W20-045N1B that came with my SteamDeck, to rule out Anker-specific issues - same problem.

Both of these chargers support PD, and both of the chargers worked just fine on the ZY12PDN with stock firmware. The cable I'm using is a cheap one from AliExpress which has worked fine with all other chargers/devices. I also tried a different cable but that didn't change anything.

Can the issue be due to how I'm flashing the board? Not really, right? I don't have an ST-Link so I'm using a Flipper Zero with its DAP Link application, and I changed "upload_protocol" in the config file from "stlink" to "cmsis-dap".

Building in release mode
Checking size .pio/build/zy12pdn/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]  12.8% (used 524 bytes from 4096 bytes)
Flash: [====      ]  42.9% (used 7032 bytes from 16384 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, serial, stlink
CURRENT: upload_protocol = cmsis-dap
Uploading .pio/build/zy12pdn/firmware.elf
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-16-21:15)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

swd
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0x0800199c msp: 0x20001000
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

@manuelbl
Copy link
Owner

In a recent shipment from China, I got ZY12PDN boards using a "domestic" XM1008F6P6 microcontroller (instead of a STM32F030F4). Which one do your boards have?

@Leseratte10
Copy link
Contributor

Leseratte10 commented Dec 30, 2022

The ones in my most recent shipment have the XM one, too (but I haven't tested these yet). "XM1008F6P6 2116BT". As for the old ones I had / tested when I commented on this issue, no matter what camera I use and how much editing I do, I cannot "decipher" the text on that chip - so it's probably a different fake chip instead of the legit STM32 one. Damnit.

I'd guess it says something like "GKIGK - 32F03?F?P6 - CHN122RQA" (can't read the ? characters). It does have the STM logo, but apparently the whole text is in a much worse quality than on the original one (according to photos on the internet). Great, so two shipments of fake crap instead of an actual ZY12PDN. Thanks for the tip.

Did you already test if your opensource firmware works on the XM1008F6P6 chips, or would it need to be adapted?

@manuelbl
Copy link
Owner

The board with the XM1008F6P6 MCU – as delivered – didn't correctly work with the power supply I've used (Anker PowerPort Atom III Slim). I could successfully switch up to 20V. But with the next button press, the LED went off and the voltage stay at 20V. Further button presses didn't have any effect.

This open-source software could be uploaded without any problem. The XM1008F6P6 chip seems to be fully compatible with original STM part.

In further tests (with an board with an STM MCU), I could likely reproduce your problem several times. The problem is obviously that the board incorrectly goes into configuration mode. The configuration mode is apparent as cycling through the colors also includes the purple color, which is not used in the other modes.

@Leseratte10 Can you check if you your board enters configuration mode too?

@manuelbl
Copy link
Owner

BTW: I have a copy of the original firmware (from a board of 2nd half of 2020). If anyone is interested, let me know.

@Leseratte10
Copy link
Contributor

@Leseratte10 Can you check if you your board enters configuration mode too?

Looks like it does. I've attached it to a charger, plugged it in, switched to Yellow (9V), held the button down until the LED went off, then unplugged it. Plugged it back in, and it starts red. Then when I push the button, it cycles through yellow, green, light blue, dark blue, purple, then back to red.

@manuelbl
Copy link
Owner

manuelbl commented Jan 2, 2023

I've pushed several changes that increase the robustness and compatibility with different power supplies. They will likely fix your issues:

  • Better button debouncing so voltage spikes while connecting to power supply cannot trigger configuration mode
  • USB PD communication is active even in configuration mode (to prevent USB PD supply from resetting power)
  • Configuration mode now blinks LED constantly to indicate the mode
  • Improved compatibility with USB PD 3.0 (e.g. for Anker PowerPort Atom III Slim)
  • Limit maximum voltage to 20V (as some power supplies go higher, e.g. Anker PowerPort Atom III Slim goes to 21V)
  • Fixed timer button that would delay start of PD communication

Tested with STM32F030F6 and XM1008F6 MCUs and about 8 USB PD power supplies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants