$0.25 HK32F030M - Cortex-M0, 32MHz, 16KB flash, 2KB RAM (Actually 4KB!)

[DavidAlfa]

Another MCU drama, soon I'll be needing more PIC16LF18323 but they have 1 year delay!
Also they're starting to get expensive for what they are.

For the same price I can get the STM32F030C6 for $0.56 or the  STM32F103C6 for $0.75, but they consume way more than the PIC (2mA at 32MHz).

I need the low consumption because I'm studying the possibility of removing external power requirement and directly feeding from the logic signals, this interfaces old electronics, each device pin has a 680R pullup to 5V, and there're at least 4 inactive pins at any given time, so 1mA*(680/4)=0.17V drop per mA, there's some room for a low power mcu, I should be able to load 3-4mA without causing inputs to be read as 0.

Another visit to lcsc showed this cheap $0.25 Cortex-M0 HK32F030MF4P6, but damn, chinese datasheet again.
Clicking at the English link at https://www.hsxp-hk.com did nothing, but I wondered if https://en.hsxp-hk.com existed.
To my surprise it did, and I was able to get the HK32F030M English datasheet.

Quick links:

- CubeIDE Patch adding support for several devices, including HK32F030M.
- HK32 folder with docs and CubeIDE sample project. Patch must be applied before attempting to open this project, otherwise CubeIDE will crash.
- Flash config bits issues and fix.
- EXTI issues and fix.
- Overclocking.

Edit: Fix PCB:
- Missing GND trace for CH340E !!
- CH340E RTS/DTR not working as expected, remove them.

[thm_w]

Puya might make them too https://www.eevblog.com/forum/microcontrollers/wch-$0-10-risc-v-mcu/msg4505176/#msg4505176

But wouldn't HK32F030 have similar or greater power use than the STM32F030?
47c from LCSC if you buy enough: https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_STMicroelectronics-STM32F030F4P6TR_C89040.html
32kB flash if needed. There is also the G series for a few cents more, which uses less power.

Honestly from the application you are describing, to me it doesn't make sense to try to penny pinch to this level.

[PCB.Wiz]

Another MCU drama, soon I'll be needing more PIC16LF18323 but they have 1 year delay!
Also they're starting to get expensive for what they are.
...
I need the low consumption because I'm studying the possibility of removing external power requirement and directly feeding from the logic signals, this interfaces old electronics, each device pin has a 680R pullup to 5V, and there're at least 4 inactive pins at any given time, so 1mA*(680/4)=0.17V drop per mA, there's some room for a low power mcu, I should be able to load 3-4mA without causing inputs to be read as 0.

If you want phantom / higher resistance power source, you may want to check the RESET current consumption of your MCU ?

Nuvoton have a new part designed for higher impedance power sources, where startup matters
https://www.nuvoton.com/products/microcontrollers/8bit-8051-mcus/low-power-mug51-series/mug51tb9ae/

I also spotted the XM003/XM004 series parts appear to specify a peak Icc during power up too.

https://www.lcsc.com/search?q=XM00

[woofy]

Another MCU drama, soon I'll be needing more PIC16LF18323 but they have 1 year delay!

If the variant is OK, Mouser have over 6k in stock.
https://www.mouser.co.uk/ProductDetail/Microchip-Technology-Atmel/PIC16LF18323-I-SL?qs=PQDAUpz3sUPfUYfJi7oGkw%3D%3D

[DavidAlfa]

The topic was mostly "Another cheap chinese MCU" and "There's english datasheet!".

I know Mouser have them, it's in the last resort option, the problem with them is their expensive shipping.
I always bought from RS because it's 5€, but Mouser wants 20!

Nah, the peak consumption is not a problem, inputs won't care for a logic "0" unless it stays there for several milliseconds.
It's the continuous running power what
What can't be is 25ma all the time!

[PCB.Wiz]

Nah, the peak consumption is not a problem, inputs won't care for a logic "0" unless it stays there for several milliseconds.

You miss the key point - the MCU needs to not draw too much power, during the reset phase to ensure the power supply can be high enough to start reliably, when fed from a series resistor type source.
ie there will be some series resistor value, above which, the MCU will not start.

Once the MCU is started ok, you can select CLOCK dividers and modes, but during reset you have no control at all.

[thm_w]

Yeah the english datasheet is interesting.
I personally would not use it at the momemt, as stm32f030f4p6 gets me 32kB, and almost certainly this one only has 16kB without hidden flash.

But you were right:

HK32F030

Typical operating current
◦ Run mode: 2.3mA@32 MHz@3.3V (71 μA/MHz)
◦ Sleep mode：1.2mA@32 MHz@3.3V (37 μA/MHz), wake-up time: 21 ns
◦ Deep Sleep mode：0.61mA@114 kHz@3.3V, wake-up time: 7.8 μs
◦ Stop mode：30μA@3.3V, wake-up time: 10 μs (woken up by an external pin or an internal timer)

Its a big improvement in the F030 which is 10-20mA in the datasheet.

They also have a SOIC8 package: https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_HK-HK32F030MJ4M6_C907709.html

[PCB.Wiz]

To my surprise it did, and I was able to get the HK32F030M English datasheet.

Hmm.. That's only a 3.3V rated part, to power from 5V logic pullups, you really need a wide Vcc part. (eg 1.8~5.5V)
I'm surprised anyone releases a small MCU these days with narrow Vcc, it really limits the market.

[thm_w]

Hmm.. That's only a 3.3V rated part, to power from 5V logic pullups, you really need a wide Vcc part. (eg 1.8~5.5V)
I'm surprised anyone releases a small MCU these days with narrow Vcc, it really limits the market.

I mean wider is nicer, especially if OP is going to interface at 5V, but if not is it that different than adding a few cent LDO?
https://www.lcsc.com/product-detail/_LR-_C914128.html

[PCB.Wiz]

Hmm.. That's only a 3.3V rated part, to power from 5V logic pullups, you really need a wide Vcc part. (eg 1.8~5.5V)
I'm surprised anyone releases a small MCU these days with narrow Vcc, it really limits the market.

I mean wider is nicer, especially if OP is going to interface at 5V, but if not is it that different than adding a few cent LDO?
https://www.lcsc.com/product-detail/_LR-_C914128.html

Sure, you can add parts, for more cost and area, and add engineering time (and even more parts?) to check that 3v3 really does stay at 3v3 when those pullups are trying to pull things up to 5V (few LDOs can sink current), plus ensure the pin ratings are ever exceeded in all combinations of startup and brownout ....

I was surprised as the other recently released, low pin count MCUs I've looked at, are all wide Vcc

eg
XM004       Fuman    2.0~5.5V
APM32F003 Geehy    2.0~5.5V
CW32F003F4U7   CW 1.65V~5.5V

[DavidAlfa]

Sure, there're lots of other mcus available. Those you listed are 2-3x more expensive, some way less powerful.

Powering from 5V pins doesn't mean it's just 3 wires flying around in the air, of course there's a proper ldo!

I'm using a uln2003v12 (MOSFET version) to interface the pins, lower conduction voltage (Darlington won't go below 0.7V) and almost zero driving current.
Every source has a very convenient diode to a common pin for inductive load protection, which in this case I'll be using to feed the ldo.

Anyways the main power will come from a USB-C plug, however I'm trying this power scheme on this iteration.
The devices using this connection vary a lot, so I'll try to lower the power as much as possible (And detect external power, cutting features, like blinking the LED on activity), trying to provide this functionality as plus, but might not work with all, so the instructions will clearly state this and advice to use the USB power if not working.
I think a 10uF capacitor + power-on reset delay should be enough, but this all will be tested when the PCBs arrive.

These cheaps xx32F030 are very attractive, I might buy a few and try to program them.

By the way, a picture of the thing in a earlier prototype.
Yeah most of the stuff is hidden under the button and at the bottom layer.

[DavidAlfa]

Something that always annoyed me was the fact all Chinese makers only supplied Keil cmsis-pack (DFP format).

I discovered this plugin for Eclipse:
https://github.com/ARM-software/cmsis-pack-eclipse

Libraries can be taken from here:
https://github.com/IOsetting/hk32f030m-template

Will give it a try!

[DavidAlfa]

Finally I bit the bullet and bought 25 chips for $7.48, ST/Microchip parts would've been not less than 3x that, so I'm fine with the adventure even if I don't get it working at the end.

It seems these chips actually have 4KB SRAM, which is also reflected in the Linker script! Tested, yes, 4KB!
This device seems to be a lower-clocked HK32F0301M ?
Well, the CMSIS-Pack plugin was pretty useless. Also, installing it into CubeIDE will break everything.
But there was hope of making it work using the  hk32f030m template.

Which was suprisingly easy!
It's great to have all the good stuff from the IDE like Syntax highlighting, Stack analyzer, Code completion/Declaration dialogs...
So I made a basic project, the included libs are very similar to ST's LL lib.
The selected MCU was set to STM32F030F4Px so it selects the correct architecture (-mcpu=cortex-m0), but uses no ST code at all.
Takes the included toolchain "GNU Tools for STM32 compiler" which is gcc-arm-none-eabi with some ST's tweaks.

The MCU target is easily changed by declaring HK32F030MJ4M6 / HK32F030MD4P6 / HK32F030MF4P6 / HK32F030MF4U6 in the preprocessor tags (Currently set to HK32F030MF4P6).

So, it only takes installing the IDE and importing the project. I love simple setups!

Yet to see if it debugs nicely with a DIY Bluepill J-Link OB.
Edit: It seems it will, current J-Link software included in CubeIDE already supports this devices:


It only requires to properly set the Device field when creating a launch profile:


Edit: Create Google Drive folder:
- Google-translated RM, English datasheet.
- HK32F030M project for STM32 CubeIDE.
- Original library.
Download.

Trying to import this project in a non-patched IDE will cause all sort of errors, it's asking for a non-existing MCU, so it goes completely nuts !

[thm_w]

Finally I bit the bullet and bought 25 chips for $7.48, ST/Microchip parts would've been not less than 3x that, so I'm fine with the adventure even if I don't get it working at the end.

Its cool you are doing this, but, its not that big of a difference. 25 STM32F030's from LCSC or G030's from alix would be $16.

Jlink seems to be on top of things: https://www.segger.com/supported-devices/search/32f030 APM is there as well, wow.

[DavidAlfa]

Yeah, but where would be the fun then?
25 cents is crazy for a CM0 MCU! 16KB is plenty for simple stuff.
If it works as expected, I might buy more for the future.
I mean: I won't tell if it worked!
Otherwise everyone is going to hype and buy them all

Edit: another reason to buy is the extreme low power, 2mA@32MHz (Or 500uA@8MHz).
ST doesn't get even close!
Of course it could be BS or non-realistic testing (Like turning everything off except cpu).

[tellurium]

I mean: I won't tell if it worked!
Otherwise everyone is going to hype and buy them all

If you keep silent, we'll know it worked...

[DavidAlfa]

The tiny HK32 arrived!

Edit: It turns out all the issues were caused because pins 1 & 2 had a very hidden solder bridge.
Pin 2 is SWD, so very weird stuff was happening!

JLink:
It always detects the HK32F030M as read/write protected...
I can read the flash anyways , containing random data, also the RDP bits at 0x1FFFF800, containing "AA 55" ....
The User Manual states that this value is level 0 protection (No protection), so I guess Segger messed it up.
As I was always getting a dialog asking to remove these bits, I ended checking "Remember selected action" and clicking "NO", problem gone!
It debugs, programs, everything works, so it's just a minor issue.

And itt definitely has 4KB RAM! Perhabs only 2KB tested, can't tell.
I filled it entirely, the contents were correct!

I'm using DIY JLink and STM32 CubeIDE (Requires patching to bypass verification check).

It's working great!

Additonally I found this useful doc at Github:
https://github.com/gbm-ii/HK32F030

VCAP pin is actually fully usable, it's PD7!
They did some terrible job in the pinout drawing, but it's later described in the GPIO functions as "VCAP/PD7", seems they copied a lot from other datasheets.

[DavidAlfa]

I'm almost finished porting the code from the PIC, only some IO toggling and LED PWM remains.
For debugging purposes, I added u8g2, interfaced a small OLED, I'm also using itoa() which adds another 4%...
And it's still using almost half of the flash the PIC did!
Both compiled optimizing for size!

It's not like a STM32H7 series, but I'm definitely buying more for everyday low-requirement projects!
Adding how much I hate MPLABX and the extremely slow and buggy Pickit3... not a hard transition! 

[voltsandjolts]

extreme low power, 2mA@32MHz (Or 500uA@8MHz).
ST doesn't get even close!
Of course it could be BS or non-realistic testing (Like turning everything off except cpu).

2mA@32MHz ? 

[DavidAlfa]

From the datasheet. Nothing about the testing conditions, assume all peripherals disabled.

[ralphd]

I hacked around with these 2 years ago but could only write code to RAM (and noticed it is 4 kB as you did).  I couldn't figure out the flash write process.
http://nerdralph.blogspot.com/2021/01/trying-to-test-ten-cent-tiny-arm-m0-mcu.html

I don't have a JLink.  I built a CMSIS-DAP SWD dongle using a CH551, which works fine with STM32 & GD32.  If someone else can figure out how to flash this with OpenOCD or PyOCD, I'll give it another shot.

[voltsandjolts]

From the datasheet. Nothing about the testing conditions, assume all peripherals disabled.

Sorry, I wasn't clear. I meant in your own hardware tests, are you seeing results that tie up with datasheet figures?

[IOsetting]

I hacked around with these 2 years ago but could only write code to RAM (and noticed it is 4 kB as you did).  I couldn't figure out the flash write process.
http://nerdralph.blogspot.com/2021/01/trying-to-test-ten-cent-tiny-arm-m0-mcu.html

I don't have a JLink.  I built a CMSIS-DAP SWD dongle using a CH551, which works fine with STM32 & GD32.  If someone else can figure out how to flash this with OpenOCD or PyOCD, I'll give it another shot.

Hi Ralph, your blog is helpful, I didn't know the 4KB RAM size till reading your blog. For flashing this chip, you can use PyOCD with HK32F0303M's DFP pack. I have tested it with ST-LINK V2 and DAPLink(not a CH551 one), both works.

[DavidAlfa]

From the datasheet. Nothing about the testing conditions, assume all peripherals disabled.

Sorry, I wasn't clear. I meant in your own hardware tests, are you seeing results that tie up with datasheet figures?

Not measured yet.

[ralphd]

Hi Ralph, your blog is helpful, I didn't know the 4KB RAM size till reading your blog. For flashing this chip, you can use PyOCD with HK32F0303M's DFP pack. I have tested it with ST-LINK V2 and DAPLink(not a CH551 one), both works.

Glad you got a working DFP.  I'll give it a whirl.

[DavidAlfa]

Finished porting the code!
Considering the initialization is a lot heavier in ARM compared to PIC, it's still using only 25% of the flash.
That's about 30% of what the PIC did.

Measured the current consumption, funny enough, it consumes those 2mA with the core halted by the debugger 
Real consumptions, nothing connected to any pin:
- 5mA@32MHz
- 3mA@8MHz.
- Holding nRST low: 1.2mA  How is this even possible?

Performance is not amazing: Seems to lack any form of flash prefetching!
At least, the flash bus seems to be 32-bit, so only one instruction suffers the wait delay.
This was very obvious when toggling a GPIO, I made a large loop of this:

Code: [Select]

    GPIOD->BRR=DBG_Pin;
    GPIOD->BSRR=DBG_Pin;
Which translates into single instructions:

Code: [Select]

   8000f84: 629a      str r2, [r3, #40] ; 0x28
   8000f86: 619a      str r2, [r3, #24]

Cortex-M0 STR instruction takes 2cycles, so theorically it should toggle at 8MHz...
But one STR instruction is waiting for the flash, taking a lot longer, while the second is executed right away, giving a very assymetric waveform.
Then I found the supplied lib was wrong, the datasheet specifies 1 wait state @32MHz, but the libs were setting it to 2!
Moreover, it seems to run nicely with 0 waits @ 32MHz, seriously boosting the execution performance by 50%:

Code: [Select]

Wait    Output    Effective
0       8MHz      32MHz
1       6.4MHz    25.6MHz
2       5.3MHz    21.3MHz

Later I tried to "hack" it by enabling the prefetch bit (PRFTBE) in FLASH_ACR register, like a STM32.
The bit gets enabled, but makes zero difference!

[PCB.Wiz]

Real consumptions, nothing connected to any pin:
- 5mA@32MHz
- 3mA@8MHz.
- Holding nRST low: 1.2mA  How is this even possible?

it depends on the details of the chip designers, and many do not place much focus on RESET Icc.
Often, not all OSCs are stopped on RST, as they decide more stable exit from RST is looks better on a data sheet than Icc during RST, which few customers ask for.

Nuvoton has just released a 8-bit MCIU which does place a maximum value on RST Icc, ( < 200 μA)  and they target 'higher impedance' energy sources like solar cells and inductive coupling.
For other MCUs you may need to remove Vcc entirely to get to lowest power.

[DavidAlfa]

For some reason it seems impossible to get lower than that, I entered STOP mode, still reads 2mA, no idea what is taking the power.
(Ah, I know! The Chinese specs are always +-1000%  )

The ADC seems a bit noisy, about 3LSB! Adding caps and chokes did nothing.

Copy&paste errors:
- The datasheet states the ADC having hardware oversampler, not the case, not described anywhere in the RM or header files.
- ADC_CFGR1 RES bits (Resolution) are always 0, can't be modified, no matter if the ADC is enabled or not.

[Gribo]

Make sure you are measuring only the unit, not some leakage through the debugger.

[SiliconWizard]

Those cheap MCUs are rarely optimized for low power consumption.

[DavidAlfa]

Make sure you are measuring only the unit, not some leakage through the debugger.

Sure, I removed the mcu and it read 0.
But I think my DMM has issues, I get very different readings on different scales.

For some reason, programming the RDP was killing them.
The config bits are all set to 0 by default, and they come on complementary pairs (inverted and normal value), so the system ignores them if not matching.

However after setting RDP it also started using the value in User Config value, which is also 0, forcing hardware WDT (Can't be disabled), causing a bootloop (I'm not using the WDT).

Edit: Later I discovered a bug in the flash libs not generating the complement of the bits (config, nConfig).
Without it, setting any RDP level would actually set RDP1, as the bits and the complement won't match.
I fixed it and commited to the IOsetting repo, but there're still some issues left.

The chip doesn't come properly programmed from factory, the flash protection bits (WRP) are all zeored, causing a JLink warning telling you're about to program a protected device, everytime!
Although it will program fine by ignoring the warning, it's still very annoying.

So this is the final code that properly sets the config bits on first boot, so setting RDP0 will stop any JLink warnings, finally allowing to debug the damn thing in peace:

Code: [Select]

  // The default values are non-compliant, so it will make J-Link freak out.
  // Proper flash config initialization by checking that CFG and nCFG bits are complemented

#if defined ENABLE_RDP2 && defined I_KNOW_RDP2_IS_NOT_REVERSIBLE
  if(   *(uint32_t*)0x1FFFF800 != 0xFC0333CC ||         // RDP2, WDT OFF, No RST in Stop mode
        *(uint32_t*)0x1FFFF808 != 0x00FF00FF ||         // WRP0 = OFF, WRP1 = OFF
        *(uint32_t*)0x1FFFF80C != 0x00FF00FF) {         // WRP2 = OFF, WRP3 = OFF
   
      FLASH_Unlock();
      FLASH_OB_Unlock();
      FLASH_OB_UserConfig(OB_IWDG_SW,OB_STOP_NoRST);
      FLASH_OB_WRPConfig(OB_WRP_None);
      FLASH_OB_RDPConfig(0xCC);
      FLASH_OB_Lock();
      FLASH_Lock();
      NVIC_SystemReset();
    }
#elif defined ENABLE_RDP1
  if(   *(uint32_t*)0x1FFFF800 != 0xFC0344BB ||         // RDP1, WDT OFF, No RST in Stop mode
        *(uint32_t*)0x1FFFF808 != 0x00FF00FF ||         // WRP0 = OFF, WRP1 = OFF
        *(uint32_t*)0x1FFFF80C != 0x00FF00FF) {         // WRP2 = OFF, WRP3 = OFF
   
      FLASH_Unlock();
      FLASH_OB_Unlock();
      FLASH_OB_UserConfig(OB_IWDG_SW,OB_STOP_NoRST);
      FLASH_OB_WRPConfig(OB_WRP_None);
      FLASH_OB_RDPConfig(OB_RDP_Level_1);
      FLASH_OB_Lock();
      FLASH_Lock();
      NVIC_SystemReset();
    }
#elif defined DISABLE_RDP
  if(   *(uint32_t*)0x1FFFF800 != 0xFC0355AA ||         // RDP0, WDT OFF, No RST in Stop mode
        *(uint32_t*)0x1FFFF808 != 0x00FF00FF ||         // WRP0 = OFF, WRP1 = OFF
        *(uint32_t*)0x1FFFF80C != 0x00FF00FF) {         // WRP2 = OFF, WRP3 = OFF
   
    FLASH_Unlock();
    FLASH_OB_Unlock();
    FLASH_OB_UserConfig(OB_IWDG_SW,OB_STOP_NoRST);
    FLASH_OB_WRPConfig(OB_WRP_None);
    FLASH_OB_RDPConfig(OB_RDP_Level_0);
    FLASH_OB_Lock();
    FLASH_Lock();
    NVIC_SystemReset();
  }
#endif


[PCB.Wiz]

But I think my DMM has issues, I get very different readings on different scales.

Measuring across a low value sense resistor can give better results with meters.

The ADC seems a bit noisy, about 3LSB! Adding caps and chokes did nothing.

The data says "ADC 位数 12-bit (8 bits in valid)"  which I think is trying to say it's only good for 8 bits ?

For some reason it seems impossible to get lower than that, I entered STOP mode, still reads 2mA, no idea what is taking the power.

It's not super low power, but should get to close to 115μA, from the data.
114 Khz Osc is typ 80uA and core stop mode is typ 34.08 μA at 25°C  and 213.6 μA at 85°C

[DavidAlfa]

Measuring across a low value sense resistor can give better results with meters.

I did few hours ago, was too busy with the programming.
24.4mV over on 5.1Ohms, so it was right, 4.7mA.

The data says "ADC 位数 12-bit (8 bits in valid)"  which I think is trying to say it's only good for 8 bits ?

Ahh the small hidden details! Anyways not using the ADC for anything critical.
Just for an idea I had, basically ensure I'm not loading the power supply to much.
Good enough for checking via resistor divider if there's >4.5V at the input.

The internal bandgap reference is a mess, with same VDD, one chip reads 980, other reads 1040.
It's supposed to be 0.8V, so you make 4095*0.8/ref.
980: 3.34V
1040: 3.15V

[IOsetting]

It's "Superchinese" specs. For sure they're completely untested and fake.

I just asked one of their sales reps about these current consumption numbers.
He didn't say straight yes or no, but he recommend another type that have *real* low current consumption. The type he recommends is HK32F0301xxxxxC (end with 'C').

[voltsandjolts]

...he recommends is HK32F0301xxxxxC (end with 'C').

I don't see anything matching that description on their website.
Can you provide a link to the device, on their website or a disti site?

[IOsetting]

I don't see anything matching that description on their website.
Can you provide a link to the device, on their website or a disti site?

It seems they didn't update their EN website. The new types can be found at https://www.hsxp-hk.com/product/74/, The datasheet and user manual https://www.hsxp-hk.com/companyfile/180/ (chrome can translate the web pages to English).

[PCB.Wiz]

I just asked one of their sales reps about these current consumption numbers.
He didn't say straight yes or no, but he recommend another type that have *real* low current consumption. The type he recommends is HK32F0301xxxxxC (end with 'C').

The 'C' parts look to be wider Vcc, so it's no surprise he suggested those.
Narrow Vcc parts in the smaller generic MCU space, are fading, as users select the more useful wider Vcc parts.

Even the suggested HK32F0301xxxxxC parts are 2.4~5.5V and only 16kF on their spreadsheet ?  https://www.hsxp-hk.com/companyfile/22/

They do show HK32F04AK6T6 etc with 72MHz M0 and 16k/32k/64k choices in the common packages and 2.0~5.5V Vcc  -   lcsc shows 2500 of the 64k LQFP-32 HK32F04AK8T6  at 90c/1k
They spec :
Sleep：60uA/MHz
STOP：10.5uA
Standby：1.6uA with 100us wakeup time

[DavidAlfa]

Somewhere in the datasheet:

(*) These values are completely untested and probably 100x larger.

[DavidAlfa]

(I decided to move here the "unlocking" of Cube IDE here).
*This is for personal use only, I'm not having any benefit from it, neither using ST libraries, just for fun! *

> Genuine check bypass

The OpenOCD hack no longer works, so I took a moment to investigate.
I turns out the latest IDE versions have additional checks in the IDE itself (Previously, it was only done in ST-Link GDB server).

STLINK GDB server (ST-LINK_gdbserver.exe) will still check it, so use OpenOCD or J-Link.

I found the genuine check and patched it, was very simple, I was able to program and debug clones, tested with:

- STLink+OpenOCD: Air32F103.
- J-Link: Air32F103, HK32F030M (HK needs specific flash algorithm, only supported by J-Link).

I didn't had to modify the OpenOCD files.

Attached the patched file, plus the patching details (So it doesn't become too obvious, just in case some ST guy searchs for those strings).

> Add custom device support

The HK32F030M has different peripherals than any other STM32F030x, so I wanted to have native support for it in the IDE.

It turns out it also was pretty easy:

- Download the DFP pack, rename to zip, extract and rename the SVD file to something simple, ex, "HK32F030M.SVD".

- Copy to plugins\com.st.stm32cube.ide.mcu.productdb.debug_xxx\resources\cmsis\STMicroelectronics_CMSIS_SVD

- Edit plugins\com.st.stm32cube.ide.mcu.productdb_xxx\resources\board_def\stm32targets.xml

- Insert a new mcu block, note how we're defining the cpu architecture and the SVD file we copied earlier!
  Version can be anything, but must be there, the IDE will crash without that field.
  Also, parent must be stm32fx, or the debugger process won't start! Choose something close (Same architecture) from other existing entry.

Code: [Select]

  <mcu>
    <name>HK32K030MF4P6</name>
    <status>Active</status>
    <parent>stm32f0</parent>
    <cpus>
      <cpu>
        <id>0</id>
        <svd>
          <name>HK32F030M.svd</name>
          <version>v1r0</version>
        </svd>
        <cores>
          <core>
            <id>0</id>
            <apnum>0</apnum>
            <type>arm cortex-m0</type>
            <fpu>None</fpu>
          </core>
        </cores>
      </cpu>
    </cpus>
  </mcu>

- Save the file, open the IDE.

- Create a new C/C++ project (It won't appear under CubeMX, or under a STM32 project), then choose the new MCU in the list.

- Add your code, compile, start a debugging session, and you'll have all the peripherals defined in the SVD!

- Note: STM32 projects and Cube MX are a totally different thing, this is just to be able to use the CMSIS SVD when debugging!

[DavidAlfa]

So I was trying to enter stop mode and check the power consumption, thinking on using it for a friend's battery-powered circuit.
For testing, I'm running LSI (~114KHz).

This gives a consumption or 1.2mA:

Code: [Select]

  RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA | RCC_AHBPeriph_GPIOB | RCC_AHBPeriph_GPIOC | RCC_AHBPeriph_GPIOD, DISABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, DISABLE);
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM1, DISABLE);

  while(1);

Whenever I enter stop mode, the current doubles to 2.1mA, wtf?:

Code: [Select]

  RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA | RCC_AHBPeriph_GPIOB | RCC_AHBPeriph_GPIOC | RCC_AHBPeriph_GPIOD, DISABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, DISABLE);
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM1, DISABLE);

  PWR_EnterStopMode(PWR_Regulator_LowPower, PWR_Entry_WFE);
  asm("nop");    // Not getting there, so it's stopped

  while(1);

So my guessing is it's chinacrap? Good for basic stuff, but forget the fancy features.
I might still try the $0.10 PY32F002, though.

I found some SDK examples here (Taken from here I guess).
Will have a look at them...

[SiliconWizard]

 

[ataradov]

Try  PWR_Entry_WFI

In the library for this function there is a loop waiting for AWU timer. It might be stuck in that loop.

There is absolutely no way that it would not get close to the claimed 30 uA.

[DavidAlfa]

This works (But keep reading), I'm now using 32MHz HSI.

Code: [Select]

  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  PWR_EnterStopMode(PWR_Regulator_LowPower, PWR_Entry_WFI);

The main issue was the system reset not doing its job properly.
- After programming, the system keeps using 2mA.
- Pressing reset button - same.
- Cycling power - 150uA  .

Not impressing ultra-low power, but still better than nothing.

I was also forgetting to enable the PWR peripheral.
It seems to switch off the internal power for most peripherals, not enabling it might keep everything powered on?

5.1.2 Voltage Regulator

    After reset, the voltage regulator is always enabled. Depending on the application, the regulator works in 2 different modes.
     • Run Mode: The regulator provides 1.2 V in normal power mode (core, memory, and peripherals)
     • Stop Mode: The regulator supplies 1.2 V in a low-power mode to preserve register and SRAM contents.

Consumption in stop state:
PWR Disabled: 600uA.
PWR Enabled: 150uA.

Finally used the AWU timer to wake it up:

Code: [Select]


static void AWU_EXTI_NVIC_Config(void)                          // From the SDK example
{
  EXTI_InitTypeDef EXTI_InitStructure;
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);
  EXTI_InitStructure.EXTI_Line = EXTI_Line11;
  EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt;
  EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising;
  EXTI_InitStructure.EXTI_LineCmd = ENABLE;
  EXTI_Init(&EXTI_InitStructure);
  EXTI_ClearITPendingBit(EXTI_Line11);
  NVIC_SetPriority(EXTI11_IRQn, 2);
  NVIC_EnableIRQ(EXTI11_IRQn);
}

static void AWU_Config(void)                                    // From the SDK example
{
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_AWU, ENABLE);
  if(RCC_GetFlagStatus(RCC_FLAG_LSIRDY) == RESET)
  {
    RCC_LSICmd(ENABLE);
    while(RCC_GetFlagStatus(RCC_FLAG_LSIRDY) == RESET);
  }
  AWU_CLKConfig(AWU_CLK_LSI128);                                // Actually 114KHz
  AWU_EXTI_NVIC_Config();
  while(ERROR == AWU_TimerCounterAndStart(114000 * 5));         // Wake every 5 seconds
}

int main(void)
{
  system_init();
 
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
  AWU_Config();
  while(1)
  {
    PWR_EnterStopMode(PWR_Regulator_LowPower, PWR_Entry_WFI);
    BLINK_LED();                                                // Blinks every 5 seconds
  }
}


Then I added a 100uf cap to the mcu pins (Just picked the first one I found), the current went down to 120uA.

With AWU + LSI, it drained 130uA.

Pretty acceptable for a lot of applications.

[DavidAlfa]

Edit:
So I was disabling the SWD pins when not in debug mode, setting them as analog.
This was the culprit! Why does it consume more? No idea.

Leaving them at reset defaults: 58uA
Setting them as analog: 120uA.

Edit: After cleaning the board from flux etc, I got 35uA in stop mode with AWU and LSI!
Disabling SWD pins still increases consumption to 90-110uA, doesn't matter if the debugger is removed or not.

[DavidAlfa]

Updated the CubeIDE patch for v1.12.1.
Adds support for HK32F030Mxx, Air32F103, GD32F10x and PY32F002x.
After patching, you should be able to import and compile the project I posted here.

[DavidAlfa]

Ahh this bugged crap!
Yeah you might save a lot in high quantities, but the development will be HARD!
The libraries are bugged, everywhere. Of course no docs.

I found De-init functions doing not was it was suppposed to do.
I mean, if you want to reset some register, do it following the manual, right?

Ex. A register says "Bits 31:10 reserved, keep at reset values".
The library does "register=0" 
Other Deinits do "Set periheral defaults, turn it ON"...wtf? Just reset it!

So I'm fixing all the Deinits as per Reference manual - it might do nothing but I have to start somewhere!

If not getting it working soon, I will completely scrap them, only using them for a project they are already working on.
(And try PUYA hell )

[ataradov]

Using standard libraries is a bad idea even under the most ideal conditions. In this case it just makes no sense. The device is trivial, why do you need libraries here?

And I doubt PUYA will be any better in that regard.

[DavidAlfa]

Using a decent library is ok, unless yo get paid by hours, then of course, just one week to get something started!

I'm getting serious issues with EXTI, I've tried every way, baremetal, library...

It works after first initialization, but when I get the button interrupt I wanted to stop it, get the software to processed the event and later enable the interrupt again while changing the edge.fine


I can enable/disable the nvic interrupt just fine  but whenever I modify the EXTI RTSR or FTSR registers to enable or disable the Rising/Falling Edge, everything breaks, even the AWU timer, the device goes to sleep forever.
ONLY using EXTI works:

Setup:

Code: [Select]

void setup(void){
  // Enable Clocks
  RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA | RCC_AHBPeriph_GPIOB | RCC_AHBPeriph_GPIOC | RCC_AHBPeriph_GPIOD, ENABLE);
  RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_AWU, ENABLE);

  // Setup EXTI4
  SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOD, EXTI_PinSource4); // Use GPIOD4 as EXTI4 source
  NVIC_Init(&(NVIC_InitTypeDef){ EXTI4_IRQn, 2, ENABLE });    // EXTI4 IRQ (Button) ;
  EXTI_Init(&(EXTI_InitTypeDef){ EXTI_Line4,  EXTI_Mode_Interrupt, EXTI_Trigger_Falling, ENABLE }); // Configure EXTI4, Line 4, Interrupt mode, Falling edge, Enabled
}

ISR

Code: [Select]

void EXTI4_IRQHandler(void){
  if(EXTI_GetITStatus(EXTI_Line4) != RESET)
  {

    EXTI_ClearITPendingBit(EXTI_Line4);
    EXTI->IMR &= ~EXTI_Line4;                   // Disable EXTI nterrupt mask ->Breaks it

    NVIC_DisableIRQ(EXTI4_IRQn);                // Disable also NVIC IRQ  (Running out of ideas)
 }

Loop:

Code: [Select]

while(1){
    WritePin(LED,0);

    PWR_EnterStopMode(PWR_Regulator_LowPower, PWR_Entry_WFI);   // Stop system, wake from interrupt

    WritePin(LED,1);                                            // Woken
    delay_ms(1000);                                             // Do whatever

    if(EXTI->RTSR & EXTI_Line4){                                // Switch interrupt edge
      EXTI->RTSR &= ~EXTI_Line4;
      EXTI->FTSR |=  EXTI_Line4;
    }
    else if(EXTI->FTSR & EXTI_Line4){
      EXTI->FTSR &= ~EXTI_Line4;
      EXTI->RTSR |=  EXTI_Line4;
    }
    EXTI->IMR |= EXTI_Line4;                                    // Enable interrupt mask

    if(EXTI_GetITStatus(EXTI_Line4) != RESET){                  // Clear any even before enabling IRQ
      EXTI_ClearITPendingBit(EXTI_Line4);
    }   
    NVIC_EnableIRQ(EXTI4_IRQn);                                 // Enable NVIC interrupt, start over.
}


[jnk0le]

Ex. A register says "Bits 31:10 reserved, keep at reset values".
The library does "register=0" 

Is this actually an issue when ref manual (at least ST ones do) specifies "Reset value: 0x0000 0000"?

[DavidAlfa]

But if I combine both and stop with WFE, it works as intended, waking up every second.
But pressing the button also wakes it up, though it's configured as interrupt, and only WFI should wake from it right?

More mess:

This works:

Code: [Select]

  SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOD, EXTI_PinSource4);
  EXTI_Init(&(EXTI_InitTypeDef){ EXTI_Line11, EXTI_Mode_Event, EXTI_Trigger_Rising,  ENABLE });  // Configure EXTI11 (AWU) in event mode
  EXTI_Init(&(EXTI_InitTypeDef){ EXTI_Line4,  EXTI_Mode_Interrupt, EXTI_Trigger_Falling, ENABLE }); // Configure EXTI4 (Button)


This doesn't:

Code: [Select]

  SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOD, EXTI_PinSource4);
  EXTI_Init(&(EXTI_InitTypeDef){ EXTI_Line4,  EXTI_Mode_Interrupt, EXTI_Trigger_Falling, ENABLE }); // Configure EXTI4 (Button)
  EXTI_Init(&(EXTI_InitTypeDef){ EXTI_Line11, EXTI_Mode_Event, EXTI_Trigger_Rising,  ENABLE });  // Configure EXTI11 (AWU) in event mode

I can't touch EXTI after initializing AWU, or nothing will wake up.

Maybe I'm making mistakes, but looks to me like heavily-bugged peripherals!

[DavidAlfa]

I scrapped EXTI, f** it!  I would use button polling instead! 

Then spotted a bug in the AWU timer (But not related to my previous issues, I was not modifying AWU).
When changing its value, it would randomly hang.

Neither the datasheet or the code makes it clear.

RLR_WBUSY: Whether AWU_RLR is being written by APB bus
 • 0: AWU_RLR register is not being written by APB bus.
 • 1: AWU_RLR register is being written by APB bus.
(When RLR_WBUSY=1, the software prohibits writing to the AWU_RLR[21:0] register again.)

But it seems you must also check it AFTER writing, otherwise entering stop mode too fast will crash.
I would have had the same issue doing it from scratch, or even worse, thinking it would be my fault.

Code: [Select]

ErrorStatus AWU_TimerCounterAndStart(uint32_t TimerCounter)
{
    uint32_t TimeoutCnt = 0;
    while (TimeoutCnt++ < 0x1000)
    {
      if(!(AWU->CR & AWU_CR_RLR_WBUSY)){                    /*  Proceed if  AWU bus idle  */
        MODIFY_REG(AWU->CR, 0x7FFFFE, TimerCounter<<1);
        while((AWU->CR & AWU_CR_RLR_WBUSY));                /*  Wait for AWU bus completion  */ <------- WITHOUT THIS IT WOULD RANDOMLY CRASH
        return SUCCESS;
      }
    }
    return ERROR;                                           /*  AWU bus busy */
}

I'll commit this to IOsetting repo tomorrow!

[DavidAlfa]

Finally got it working... By always initializing AWU EXTI line after modifying any other line.

Functions:

Code: [Select]

void AWU_EXTI_cfg(void){
  EXTI_Init(&(EXTI_InitTypeDef){ EXTI_Line11, EXTI_Mode_Event, EXTI_Trigger_Falling,  ENABLE });
}


void EXTI_cfg(EXTI_InitTypeDef* init){
  EXTI_Init(init);                                                              // Configure EXTI Line
  AWU_EXTI_cfg();                                                               // Always Re-init EXTI11 (AWU) afterwards, otherwise AWU will stop working
}


void stop_AWU(uint16_t ms){                                                     // Enter stop mode for the specified time
  while(ms){
    uint16_t t;                                                                 // AWU is 22bit, that gives a limit of (2^22)/114000 =  36.79 seconds
    if(ms > 36000)                                                              // Check for AWU overflow
      t = 36000;                                                                // Load value for 36 seconds
    else
      t = ms;                                                                   // Load the remaining time
    while(AWU_TimerCounterAndStart((uint32_t)(LSI_VALUE/1000)*t) == ERROR);     // Load AWU timer
    ms -= t;
    PWR_EnterStopMode(PWR_Regulator_LowPower, PWR_Entry_WFE);                   // Stop the system
  }
}


void deepsleep(uint16_t ms){                                                    // Enter deep sleep for the specified time
  TIM_SetAutoreload(TIM2, ms-1);                                                // Timer 2 is preconfigured with prescaler of 113, at LSI freq one step is 1ms
  TIM_ITConfig(TIM1, TIM_IT_Update, DISABLE);                                   // Disable Timer 1 IRQ, but keep it running
  TIM_PrescalerConfig(TIM1, PREDIV_LSI, TIM_PSCReloadMode_Immediate);           // Adjust the prescaler so it outputs the same PWM frequency with LSI
  TIM_Cmd(TIM2,ENABLE);                                                         // Start Timer 2
  PWR_EnterDeepSleepMode(PWR_Entry_WFE);                                        // Enter deep sleep mode
  TIM_PrescalerConfig(TIM1, PREDIV_HSI, TIM_PSCReloadMode_Immediate);           // Woke up,  restore Timer 1 prescaler for HSI
  TIM_Cmd(TIM2,DISABLE);                                                        // Stop Timer 2
  TIM_ITConfig(TIM1, TIM_IT_Update, ENABLE);                                    // Re-enable Timer 1 IRQ
}

Test loop:

Code: [Select]

  while(1){
    WritePin(LED,0);
    EXTI_cfg(&(EXTI_InitTypeDef){ EXTI_btn, EXTI_Mode_Interrupt, EXTI_Trigger_Falling, ENABLE});    // Enable button wake-up interrupt on falling edge
    stop_AWU(500);                                                                                  // Load AWU and enter stop state (AWU is active in stop state)
    WritePin(LED,1);
    EXTI_cfg(&(EXTI_InitTypeDef){ EXTI_btn, EXTI_Mode_Interrupt, EXTI_Trigger_Falling, DISABLE});   // Disable button wake-up
    deepsleep(500);                                                                                 // Go into deep sleep mode (It starts Timer2 and enables the IRQ, this will wakeup the system)
  }

Now it finally behaves as expected. Both button and AWU wake the cpu from Stop state, but only timer 2 can wake it up from deep sleep.

Edit: After fixing AWU, the development literally took off.
No more bugs or issues were found, everything works fine.
I was stuck for two days not being able to make it sleep/stop properly! The MCU died and no longer woke up...

Once it damn worked I'm a happy mediocre programmer again .

[DavidAlfa]

I discovered nRST pin can also be disabled in the TSSOP20 package using IOMUX - it becomes PA0!
Though the manual says PROHIBITED, nothing is more appealing than trying forbidden stuff

Be careful with this, if you disable nRST and also SWC/SWD, it'll be converted to OTP, ask me how I discovered it! .

You might power it with nRST down, and y eah it won't init, but will have to release it at some point, to let the programmer do it's stuff, the only way woudl be with some really accurate timing. I wasn't able to connect - ever, another $0.25 to the trash.

If you do this, remember to implement some " mode", where pressing a button or making some jumper skips the reset disabling.

Code: [Select]

if(!ReadPin(BTN)){                                         // Enter safe mode if button pressed at startup (Initialize button IO port first!)
   while(1){
     Toggle(GREEN);
     delayms(100);
   }
 }

 // Disable RST pin
 RCC_APB1PeriphClockCmd(RCC_APB1Periph_IOMUX, ENABLE);   // Enable IOMUX
 GPIOMUX->NRST_PIN_KEY = NRST_PINKEY;                    // Write NRST Pin key
 GPIOMUX->NRST_PA0_SEL |= 1;                             // NRST = PA0 (Pin 4 TSSOP20)

Below you can see how the mcu only needs 700us from nRST release to start and initialize everything, while the J-Link delays the communication for 50ms.

Edit:
This chip definitely seems the same as the Hk32F0301M, which adds few features (But LSI runs at 48MHz)
Setting Standby mode worked (Measured ~1uA, didn't tried further), also the SAWU (Standby timer) works.


Tweaking flash wait states and HSICAL, I got this little thing running quite fast!

- 0 wait states, 52MHz  (HSICAL= 0x2C)
- 1 wait states, 104MHz (HSICAL= 0x39)
- 2 wait states, 144MHz (HSICAL= 0x3D)

HSICAL=0x3F does 200MHz 

Code: [Select]

  MODIFY_REG(FLASH->ACR, FLASH_ACR_LATENCY, 2);                               // 2 flash wait states
  MODIFY_REG(RCC->CR, RCC_CR_HSICAL, 0x3D<<RCC_CR_HSICAL_Pos);                // This generates ~144MHz

However when heating the mcu slighly, it caused HardFault, so not stable for everyday use.

While torturing the chip with the hot iron tip, I got these stable values:
- 0 wait states, 48MHz  (HSICAL= 0x2A)
- 1 wait states, 96MHz  (HSICAL= 0x38)
- 2 wait states, 108MHz (HSICAL= 0x3A) <--Not worth it. Reaching the chip limit?

Crazy!

[thm_w]

Ahh this bugged crap!
Yeah you might save a lot in high quantities, but the development will be HARD!
The libraries are bugged, everywhere. Of course no docs.

lol, you were warned 

[DavidAlfa]

I know!
Well, once the workarounds were done, I'm pretty happy.
Tried at least 3 chips, all run nicely @ 96MHz!

The only real issues were the f*** AWU EXTI line, and the f** AWU not working right away after programming (Requiring power cycling).

However these two happened together, so it was a real PITA to diagnose until I got an idea of what the heck was going on.
One was relatively easy, I already had read similar issues with other mcus not resetting all the periphery on reset signal, so I gave it a try... humm now AWU works!
The EXTI line was a different animal, I had to try every combination, tracing the issue, but in the end I got it!

To be honest, I've had similar situations with Microchip, ST... Some had really bugged peripherals!

Swear, break several shirts, more swearing, remove the chip and send it to the Hydraulic Press Channel to f** destroy it, put a new one, damn still the same, it's a bug!
Think on searching the HW designers's personal address to fly there to show some "gratitude", meh, too expensive and too many years in jail, keep bashing on the table...

After two days and a massive sweating, BANG! Got it! 

[IOsetting]

  Nice design~ I always hesitate to use Type-c, too hard for soldering

[DavidAlfa]

Nah, USB C is easy!
A trick: never touch the pins with the soldering tip, instead put some flux and make a slow pass with a small solder blob.
The solder will be the heating interface, heating up everything, but avoiding any mechanical forces that would ruin the plastic when hot.

The exposed pins are much shorter that in microusb, less prone to bridging.

An example, fully hand-soldered (After 5 minutes in ultrasonic bath with isopropylic alcohol).


I think I'll make the boards longer and thinner, so they fit better in a protoboard.

[IOsetting]

The solder joints look perfect! Sometimes I just heated it too long and screwed it up  ... more practices needed

[DavidAlfa]

Ideas... Adding CH340E, SPI flash, few buttons,  OLED.
Only parts placed, routing this in 2 layer pcb will be hard if not impossible.

[westfw]

Adding CH340E, SPI flash, few buttons, OLED.

Simpler is better, IMO.  People like features, but are frequently unwilling to pay for them, and won't like the details ("The buttons are too close together, the OLED is mounted wrong, and the SPI flash is interfering with my other SPI thing!")  :-(
Put the other stuff on a shield/hat/daughterboard/etc, if you want.

[DavidAlfa]

It's called "optional features". If I want a SPI flash, I can solder one.
If there's free space on the pcb why not leave room for it?

I want a button, two, or three.  Yeah, 4 user buttons might be too tight.

I hate using wires for everything, it's messy, specially those cloned Dupoint wires from Aliexpress.

How is the oled mounted wrong? Orientation is set in the controller itself.
It's exactly like that because I want to use the buttons at the same time!
Meant to be a female header where you can insert the display, not a permanent thing.

Having a UART converter is always good, specially for PY32F series (Can be programmer using the embedded bootloader).

[DavidAlfa]

Edit: Fixed spi flash, was using wrong footprint (narrow SOIC).
Also added 24cxx eeprom and missing i2c pullups.

Everything is using dedicated pins/peripherals without interfering each other.
UART (CH340), SPI (Flash), I2C(OLED and eeprom), SWD, Buttons, RGB led (Timer 2 CH1/2/3).

I think it's a pretty decent dev board in a very small size! 

[PCB.Wiz]

I think it's a pretty decent dev board in a very small size! 

yes 
Some suggestions :
There may be room to add an oscillator footprint for a part like ECS-TXO-2016MV ?
There may be room to add some solder-bridge/0-ohm jumpers to the UART TX.RX on the rear side, to allow them to move to other pins ?

[DavidAlfa]

I'll try. It was pretty hard to maintain the ground planes from splitting.
The uart will be easy, but the oscillator, hmm, it's really tight near the mcu.

[DavidAlfa]

Got it! Approaching nanometer spacing between parts  , TXCO connected to EXTCLK3/PD7, which was still free.
Attaching gerbers, feel free to look for improvements, but I feel like it's pretty much it.

[PCB.Wiz]

Looks nifty.
Only minor comment, is it looks like you managed to fit a 3225 oscillator, I like to make those a ‘universal’ footprint down to 2016 by using larger pads. Sometimes the oscillator you want is only available in smaller packages.

[DavidAlfa]

Please leave me alone 

[voltsandjolts]

The stated TCXO seems a little tricky to find. LCSC is quite good for cheap Chinese oscillators.

SMD3225-4P 32MHz 20ppm
https://www.lcsc.com/search?q=C2901581

[DavidAlfa]

Edit:
For some reason the file HK-PY.7z had a virus!
I downloaded the file I had uploaded myself to make sure everything was correct, DANG! Virus detected!!
No idea why, it only had few gerbers inside and two pictures!
If you downloaded the file before this message was edited, delete it inmediately!

The stated TCXO seems a little tricky to find. LCSC is quite good for cheap Chinese oscillators.

Not important, I simply picked parts from Snapeda which had 3D model, of course I ensured their pinouts were pretty standard, so anything compatible will fit  .
I think this is the final one.

Edit:
At last, I finished the PY32F002 board. It was a lot messier to work with, AF pins are less versatile than in HK.
In the end I commited some PCB crimes, like placing vias in some pads...

Replaced the resistors going from the CH340 to BOOT0 / nRST with diodes, so it won't push any power, only pull the signals to gnd when down.
I ended discarding the F003 and F030 versions, they're not so cheap to justify the heavy work.
But a 11-cent CM0+ mcu definitely deserves some testing...! 

Attached panelized pcbs, they're so small that 12 can be fitted in a 100x100mm pcb!

Basic BOM:

CH340E
PY32F002AF15P6TU
HK32F030MF4P6
SX3M32.000M20F30TNN
TYPE-C-31-M-12
ME6211A33PG-N
1N5819WT
HS91L02W2C01
XL-3216RGBC
CTS-3425J-V-TR

Rest are common parts easily sourced anywhere, 0402 resistors / capacitors, pin headers, 25xx/24xx memories...

[DavidAlfa]

Finally, everything was ordered at jlcpcb/lcsc  .
I feel the HK32F030 is a more versatile product after all!
I might change my mind if the PY32F002 has all the peripherals from the PY32F030 in the end, which seems very possible.

I also made a small crepuscular circuit for a friend to get rid of those f*** hogs, now also deer are destroying some young trees he planted recently.
The Beeper peripheral has proven to be extremely useful, consuming only 35uA while outputting a 1KHz signal to drive a small charge pump, boosting 2-3V to 12-15V, to turn on a mosfet.
I had to add an inverting gate to make the complementary signal, additional 5 cents and 1uA consumption.
Without it, the mcu would need to stay in sleep mode so the timers keep working, consuming way more power than in stop mode (600uA vs 35uA).

[PCB.Wiz]

Finally, everything was ordered at jlcpcb/lcsc  .
I feel the HK32F030 is a more versatile product after all!
I might change my mind if the PY32F002 has all the peripherals from the PY32F030 in the end, which seems very possible.

The PY32F002 is certainly cute and cheap.
They seem to have (too?) many part codes in the PY32F003/002 series.
PY32F002 has different pinout, and does not appear on the website, but it is in the downloads. Not a 'widely publicized' part ?

The PY32F002 has a SSOP10 (1mm pitch SO8 size), that does have OSC_In/OSC_Out, so that looks nice.
Then I see the PY32F003 mentions a MSOP10 (0.5mm pin pitch) but only in 64k model, and that lacks a OSC_IN / OSC_OUT ?!

PUYA also offer SO16N options, and in the TQFP32 package, their PY32F030K18T6 are a lot cheaper than  HK32F030
The TQFP32 also get both MHz and kHz crystal support.

PUYA also have multiple pinouts, eg I see PY32F030F18P6TU / PY32F030F28P6TU / PY32F030F38P6TU in TSSOP20 and  PY32F030K1/PY32F030K2 in TQFP32
PY32F030F38P6TU stocks at lcsc, but no data sheet showing the pinout ?

[DavidAlfa]

The datasheets are available at the Puya semi website.
It's a bit hidden, but in the product page, swipping all the way to the right, you'll see a folder icon, they all download the same 100MB file containing py32f002/003/030 datasheets, RMs, examples...
The pinout changes between 1x, 2x and 3x series, but they're same thing after all.

Finally I caught a small issue where the stop consumption had increased to 100uA.
It has a small header for inserting a display to configure the module, meant to be removed afterwards.
As the display already has the pullups, I omitted them in the pcb.
Well, I forgot to deinit the i2c module and set the pins as analog after configuring, so the i2c interface was left floating when removing the display, causing this increased power consumption.
Either with the pullups and the module enabled, or without them and disabled, the current stays at 34uA.
This is with LSI, AWU, EXTI and Beeper enabled and running.

25mAh/month is not too bad  , the device it will switch consumes a lot more.

BTW, the i2c module of this MCU is quite interesting, can generate start condition automatically when starting the first transfer, also can send the stop after a certain byte count was transferred, will also do it when receiving a NAK from the slave.

[DavidAlfa]

Lcsc kept asking for $22 for combining few small designs in a 100x100mm board.
Made few $4 orders panellizing only one design at a time, that worked.
I'll have enough PCBs to make some wall art, and lots of coasters 

[man_anyone]

Can you please test the HK32F030M on 5V?
Someone already did it on elektroda
https://www.elektroda.com/rtvforum/topic3731577-30.html#19358946
But he used "an older version" of SO8 and only tested a single chip, I suggest testing more than one, just to be sure
We already have a lot of evidence for the "HK32F0301M is just HK32F030M with a faster clock" theory, which means that the HK32F030M is a wide voltage chip and should be able to handle 5V no problem, and that will make USB powered designs simpler and (a little) cheaper
I'm particularly interested in the TSSOP20 package, I know that all the packages *should* be the same chip, but I also know that it's Chinese so...
Another thing, when you clocked it to 200MHz, what did you mean by "heating the mcu slightly", Does slightly mean a finger or a heat gun on a low setting?
Also can it run at that speed sustainably for short periods of time (minutes)?
And the third and final question: how easy (or hard) will be adding support for this chip to something like platformIO?
They already have a demo configuration
https://docs.platformio.org/en/stable/boards/ststm32/demo_f030f4.html#board-ststm32-demo-f030f4
But I don't know what to patch to make it support clones, I don't even know if that's needed
I'm using a blackmagic-espidf probe (esp32 with blackmagic firmware), which hopefully doesn't have such rigorous checks like the stlink, so I won't need to worry about that, hopefully (I would be grateful if you tested it and told me how to patch it -if it needs patching-, if you have some spare time that is)
Sorry if I asked too much questions, but I don't want to buy a chip that I can't program (I know it's cheap but I'll still have to wait for shipping)
Also this is my first post here, sorry if it's a little unorganized, I made this account *just* to ask those questions

[PCB.Wiz]

Can you please test the HK32F030M on 5V?

I notice the HK32F030 links have all ceased to work on lcsc ?
Still, there are many other wide Vcc parts. In fact in 2023 it is quite rare to hit a narrow VCC part in 20 pins and below.

[DavidAlfa]

Heating slighly = 50°C aprox, more than ~108MHz was unstable.
200MHz didn't work at all, I just knew it was running at that speed by checking the MCO output.
Max realistic working speed was 96MHz, I blasted it with hot air and it kept working at burning temperatures.

You have a video in YouTube testing up to 7V, I don't think the chip is different.
You can see how the current quickly increases over 4V, first indication of "not made for 5V".
The current meter in that PSU seems unreliable, as the HK32F030M already consumes about 4mA at 3.3V, with nothing else.
That board has several leds, yet measures "0.000".
So it seems to me the current consumption at 5v is much higher than shown there.



No idea about supporting plataformio, neither I use it, I patched STM32 CubeIDE and use DIY J-Link.

Anyways my attention is now in the Puya PY32F002A .

[man_anyone]

Anyways my attention is now in the Puya PY32F002A .

Are they overclockable too? Or is it a Hangshun only thing?

[DavidAlfa]

Not tested by myself yet, still in transit, but they seem to overlock a bit, check the elektroda thread:
https://www.elektroda.com/rtvforum/topic3946116.html

The interesting thing here is the $0.11 they cost, overclockable or not  .

[true]

I notice the HK32F030 links have all ceased to work on lcsc ?

I know, wtf? I just got done porting an XMODEM bootloader for this, and now they're gone from LCSC... the company isn't listed on LCSC anymore either...

No idea about supporting plataformio, neither I use it, I patched STM32 CubeIDE and use DIY J-Link.

I may work on platformio support after August. If somone beats me to it, great. Until then, I am using your method.

Are you able to update your DIY J-Link or do you have to click No every time you debug?

Anyways my attention is now in the Puya PY32F002A .

As with others who like to tinker and play with these, I suspect.

[DavidAlfa]

I got rid of the update message by editing the firmware, changing the string near 0x4000 where it says "Compiled... 2018", setting the year to the future.
I set 2028 and it never asked again  .

[true]

Re: the year edit, yeah I figured that out right after posting. Seems to work fine. It's not the most up to date, but not sure that matters.

I am having an issue with the SPI peripheral. I cannot operate it in master mode. In SPI1->CR1, If SPE is set high, MSTR will go low automatically. This is even without code running, purely by poking the register. I get no transfer. Any ideas? **edit** SSM and SSI flags both need to be set high. That solves the problem.

[DavidAlfa]

I had no problem with SPI, but I used the peripheral library.

[boneDragon]

why not use 0.2..0.3$ more expensive chip like GD32E230/AT32F421/N32Gxxx with faster core/clock, more flash/ram/timers etc, available from more sellers, and its pinout compatible with STM32F0xx/3xx, so you can switch to other if it is not available ? Peripherals are mostly compatible, so porting to other chip is easy

[DavidAlfa]

Because I simply wanted to try the cheapest arm mcu I found back then

[DavidAlfa]

The board arrived, still waiting for the parts from lcsc.
It's really small! Of course banana for scale 

The silk screen text is too small for the fab resolution...

[DavidAlfa]

Deeper detail:

[boneDragon]

comparative table of some mcus:

[IOsetting]

There is another variant(possibly just the same) of py32f002a, with Arduino support, will be released by Luatos. They guarantee the ram&flash size to be 4KB/32KB.

Arduino lib: https://github.com/Air-duino/Arduino-AirMCU
Tutorial: https://wiki.luatos.com/chips/air001/Air001-Arduino.html  (in Chinese, please use Google Chrome to translate it)

The PCB files of this board: https://gitee.com/openLuat/luatos-broads/tree/master/broads/Air001-Board/

[DavidAlfa]

Yes the py32F002a has 4/32KB, though not officially.

[DavidAlfa]

Did you remember to thoroughly check the netlist and schematics before ordering?
Aye!
Well... 

[bingo600]

I just ordered a few of these - TWen32F003
Initially i thought them to be RiscV, but i think the TWen32F003  is Arm Cortex.

I haven't succeded in getting any info on this MCU, not even a DS.
Anyone has it ??

/Bingo

[DavidAlfa]

First step before buying anything is finding the docs!
If no docs or bad support, fly away!
But better you make a new thread for that MCU, doesn't belong here!
I will make a new thread for the PY32F002A when I start tinkering with - so should you with the Twen32 lol.

Anyways, didn't get the CH340 pin working as DTR for BOOT0 so I disconnected it and toggled manually.
Puya ISP worked beautifully, got the leds working in no time thanks to the existing example projects.

[bingo600]

I will make a new thread for the PY32F002A when I start tinkering with - so should you with the Twen32 lol.

Roger that on the TWen32F003

May i ask why you didn't select the PY32F003 either in 6 (32K/4K) or 8 (64K/8K) - F003 is dual uart too
They even seem cheaper at LCSC.

Would you consider making a board for the F003 ...
I am "lousy" at PCB's

Puta ISP worked beautifully, gotcthe leds working in no time thanks to the existing example projects.

Do you have a link for that PUYA ISP ?
Does it run under linux ?

/Bingo

[DavidAlfa]

Would you consider making a board for the F003 ...

Actually the PY32F002 is the same. 2x SPI, 2x UART, PLL (48MHz), 4/32KB ... a great deal for 11 cents!
Otherwise, I'm not interested in the PY32F003/PY32F030, I can get a STM32 for a similar price.

Edit: PY32F002 stuff moved here:
https://www.eevblog.com/forum/microcontrollers/$0-11-py32f002a-m0-24mhz-320kb-actually-324kb-more-peripherals/

[DavidAlfa]

Can you please test the HK32F030M on 5V?

I notice the HK32F030 links have all ceased to work on lcsc ?

Yeah, I noticed too! Also other parts I bough on my last order completely evaporated.
This is f** nuts, now I can't view the datasheet anymore!
Lesson learned: Download them before ordering! 

[Sacodepatatas]

I've found an interesting spreadsheet regarding the IO mapping of the HK32F030M so i attached the files for the joy of everybody.

[ass20]

hi

 I buy HK32F030Mf6 from ali
I solder mcu on pcb board and connect only capacitor to Vcc and gnd pin. and connect jlink-ob (072) to cpu over swd (swdio and swdclk lines only)
but jlink not found cpu. jlink version 7.82f and 7.94 without addons for hk32

I mesure I=1.3mA only


Add
 I found errors

Jlink-ob (072) work fine read and write data
If you do not erase or do not write RESET option bytes to default
I write following options bytes and after than works is fine

1FFF_F800   AA 55 FF 00 FF 00 FF 00  FF 00 FF 00 FF 00 FF 00

About hardware
minimal need I place only 1 capacitor 4.7uF to Vcc and Gnd pins only

[DavidAlfa]

Connecting nRST might help.

[ass20]

I found HK_config
https://www.hsxp-hk.com/companyfile/10/
It is have Eng interface and manuals inside

HK_config use jlink for flashing and have user frendly option bites menu
 

[prosper]

The only real issues were the f*** AWU EXTI line, and the f** AWU not working right away after programming (Requiring power cycling).

One was relatively easy, I already had read similar issues with other mcus not resetting all the periphery on reset signal, so I gave it a try... humm now AWU works!
The EXTI line was a different animal, I had to try every combination, tracing the issue, but in the end I got it!

Thanks for documenting your experiences on this. I ran into similar issues configuring EXTI on this, as well as resets not resetting peripherals properly and/or peripherals not behaving as their register values seem to indicate after a reset. Adding a 'periph_DeInit(...);' before the 'periph_Init(...);' seems to help. TIM1 suffers from this - it doesn't correctly initialize PWM polarity across resets. Sometimes you get noninverting polarity, sometimes it's inverted. Seems random, or at least related to whatever mode it was in before the reset. I'd assumed it was a power supply stability thing or maybe an oscillator stability thing, because adding a delay to system startup before enabling the peripheral clocks and bringing them up seemed to help.