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

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