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

[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.