HK32F030M - Chinese ARM for 15 cents

So I bought it just to see what it was. Have you looked to see if they have something similarly ridiculously cheap with CAN? I recently looked but I see that all F103 clones have a similar price, around 80p/pc.
As for these HK32, does the manufacturer have any biblos for this or do you have to carve from scratch yourself? By the way, with such prices, it's not surprising that they don't make it with production.
I wonder if it is normally built or like all those Chinese STM32 clones, digital chip and serial flash memory. I don't know if you know this site [url=]https://zeptobars.com/[/url] , the wheel there, probably for a few dollars, pulls the systems out of the housing and takes photos, moreover, of good quality. I plan to send him some Chinese ARMs sometime to see what's inside.

victoriii wrote:

Have you looked to see if they have something similarly ridiculously cheap with CAN?

I do not reckon.

victoriii wrote:

does the manufacturer have any biblos for this or do you have to carve from scratch yourself?

I only found "hk32f030m.h" and startup.
The process is so simple that there is no problem with writing your own drivers.

From the HK website you can download the DFP file with Keila support. I opened this DFP under Linux and there is a lot more in there. There are startups, header files, etc. Unfortunately, there are no drivers or examples, but I think I'm asking too much for the price.

SO8 version. They finally arrived. The local post office was in quarantine.

//======================

By the way, I found something like this:

Probably 30 cents :D

//======================
Update regarding HK32F030MJ4M6-SO8N.
There is an error in the PDF (the latest one is currently 1.0.12 and a few older ones), pins 6 and 7 are swapped.
NRST... is pin 6.

Some interesting facts:
GPIO description in RefMan is wrong - copied from STM32.
Significant differences:
GPIO ports are logically 8-bit. The default operating mode of the port lines is ANALOG (3), except for PD5, PB5 (SWDIO, SWCLK - AF ie 2) and PA0 (NRST) - IN ie 1, with appropriate pullup/down for these three lines.
Note: programming the SWD function will of course make reprogramming/debugging very difficult.
NRST is also PA0 in the TSSOP20 package (documentation says that only in smaller ones) - you can disable the NRST function by software.
After minor cosmetics of pdsc files, Keil creates a complete project for HK32F030M, which can be programmed and debugged with J-Link. Hardware RESET is not needed to establish the SWD connection, unless we program the SWD leg function. If we program it, the hardware NRST does not help much, but it is J-Link's fault, which has something wrong with the software. Tweezers helped on the 10th attempt, so the bone was saved.

Flash has 128B pages, not 1KiB. After deletion, Flash has a value of 0, not FF (according to the manufacturer, even more interesting, because it is random).

And finally, a bonus: RAM is 4 KiB, not 2 as stated in the documentation. :)

That's all the discoveries for now. I ran both timers in PWM mode.

The VCAP leg remains a mystery - not a word in the documentation. maybe it's about a phantom, just to ensure pin compatibility with STM8 - it doesn't look like the output of the internal core voltage stabilizer. After switching the PD7 to the output mode, the PD7 state is displayed on this leg, so it's probably just PD7 without any other function.

Are you sure you are writing about HK32F030M in TSSOP20 and not HK32F0301M?
I can't turn off NRST and set PA0. There is no PD7 on VCAP. RAM is actually 4kB.
Hmmm, another party? I have ordered a few new ones and they will come in a few days, so I'll test it again.

Can you share the binary waving PA0 and PD7?
Can you write down the entire scalar marking?



Initially, I thought that the RAM is 2kB due to the required programming settings, but a simple test shows that under 0x20000800...0x20000FFF there is a different ram than 0x20000000...0x200007FF.
Is it fully operational? I do not know.

I tried to disable NRST with:

Quote:

RCC->APB1ENR |= RCC_APB1ENR_IOMUXEN;
GPIOMUX->NRST_PIN_KEY = 0x5AE1;
GPIOMUX->NRST_PA0_SEL = 1;

It works in SO8, in TSSOP20 it doesn't.

The photos are not very beautiful to me, but I read from the HK32F030MF4P6 housing, and below the series, probably 07S36170 (these S3 are uncertain, the rest at 95%).
A voltmeter applied between ground and VCAP shows about 0.7 V. It shows the same between Vdd and VCAP, so I conclude that the VCAP is hanging. After setting PD7 as the output, I have state changes on VCAP - voltage 0 and Vdd alternately..
After programming the NRST, the system does not respond to a short-circuit of the NRST to ground. After programming PA0 as an output, it changes state. I am attaching the program source and .hex.
Now I'm going for the HK32F030MJ4M6.

[syntax=c]#include "hk32f030m.h"
#include "stm32yyyy.h"
#include "stm32util.h"

#define HCLK_FREQ 32000000u
#define LED_FREQ 400
#define LED_STEPS 250
#define LED_DIM 1

#define PWM_TIM TIM1
#define LED_DUTY PWM_TIM->CCR4
// AF3 - TIM1, AF4 - TIM2
// PC4 - pin 7 (6?) -> TIM1CH
// pin 1 - PD4 TIM1CH4, TIM2CH1
#define LED_PORT GPIOD
#define LED_BIT 4
#define LED_MASK (1u AHBENR |= RCC_AHBENR_GPIOAEN | RCC_AHBENR_GPIOBEN
| RCC_AHBENR_GPIOCEN | RCC_AHBENR_GPIODEN;

RCC->APB2ENR = RCC_APB2ENR_TIM1EN;
RCC->APB1ENR = RCC_APB1ENR_TIM2EN | RCC_APB1ENR_IOMUXEN;

PWM_TIM->PSC = HCLK_FREQ / LED_FREQ / LED_STEPS - 1;
PWM_TIM->ARR = LED_STEPS - 1;
PWM_TIM->CCMR1 = TIM_CCMR1_OC1M_PWM1 | TIM_CCMR1_OC1PE | TIM_CCMR1_OC2M_PWM1 | TIM_CCMR1_OC2PE;
PWM_TIM->CCMR2 = TIM_CCMR2_OC3M_PWM1 | TIM_CCMR2_OC3PE | TIM_CCMR2_OC4M_PWM1 | TIM_CCMR2_OC4PE;
PWM_TIM->CCER = TIM_CCER_CC1E | TIM_CCER_CC2E | TIM_CCER_CC3E | TIM_CCER_CC4E;
PWM_TIM->BDTR = TIM_BDTR_MOE;
PWM_TIM->CR1 = TIM_CR1_CEN;

LED_PORT->AFR[0] |= BF4(LED_BIT, 3);
LED_PORT->MODER &= BF2A(LED_BIT, GPIO_MODER_AF);

SysTick_Config(HCLK_FREQ / 1000);

for (;
__WFI();
}

void SysTick_Handler(void);
void SysTick_Handler(void)
{
static uint8_t led_target = LED_DIM;
static uint16_t tdiv;
if (++tdiv == 1000)
{
tdiv = 0;
//LED_PORT->BSRR = LED_MASK ODR & LED_MASK);
// toggle PD7
GPIOD->BSRR = (1u

Thanks.
Hmmmmm, PD7 works I don't know how I tested it before.
Reset still does not turn off.

HK32F040MJ4P6? Google is silent about it.
Where did you snatch it from? do you have a pdf?

------------------------------------------------

Aaaaaaa, now I know why PD7 "didn't work".
I recently replaced the fuse in the voltmeter

B. easy - two typos in one string were enough - I've already corrected it.
From January 1, HK32F030M became more expensive. I ordered less than 20 cents in December and they have arrived. The MJ4 is nicer and cheaper than the STM32G030J6, because you can use the RESET leg for other purposes. You still need to practice this supposed EEPROM - it will also be useful in the project.

I thought you knew some secret Chinese handshake after which the seller pulls the goods from under the counter :D

BlueDraco wrote:

From January 1, HK32F030M became more expensive.

Almost *2
I bought them at the beginning when they appeared, in December only after 10 I bought them to see if they changed anything.

I also ordered the "HC32L110". M0+, 1.8V...5.5V, 1uA RTC sleep, the rest is similar.

They should reach me by Monday.

======== update 1 ========

They arrived, I'm going to solder and check the reset.





======== update 2 ========

I checked the new batch of TSSOP20.
Reset can be disabled. You can't in the old one.

It remains to be checked whether pins 6 and 7 in SO8 are still swapped.

Same as mine. I didn't order the L110, but I'm keeping an eye on it. 16 legs and 5 volts are sometimes useful. I dream of a Cortex in MSOP8 or MSOP10.

BlueDraco wrote:

I dream of a Cortex in MSOP8 or MSOP10.

I searched, I searched. I found only OTP, besides, it can't be bought (I don't want to play in taobao).
I'd prefer SO8 too.

In MJ Reset/PA0 is on leg 7, which is the same as in the current datasheet. The code I posted above, after a slight modification - remapping PD4 to leg 1, works exactly as on MF - PD7 and PA0 change state.
EEPROM works with common sense. As in Flash - the value deleted is 0. An attempt to erase page 0xC000000 (ie EEPROM) erases page 0x8000000 (Flash), but there is no mention of erasing the EEPROM page in the documentation.

By the way - for the first time I have encountered a situation where the manufacturer changes the essential features of the system after the start of production, without changing the name of the system by a single character.

BlueDraco wrote:

By the way - for the first time I have encountered a situation where the manufacturer changes the essential features of the system after the start of production, without changing the name of the system by a single character.

I haven't tested the newer SO8 yet, but they all have the same: DEV_ID: 0x0003, REV_ID: 0x1000


=========== update 01/21/2021 ===========

I tested the new SO8.
Reset on pin 7. In the old one on pin 6.

Recently, when testing something on the breadboard, I inadvertently connected the HK32F030M to the 5V power supply. I only noticed it after an hour.
Nothing was heating up, there was no magic smoke, so I decided to test the maximum supply voltage.



I wrote a simple softkey for flashing LEDs.
Only after exceeding 7V the system began to work incorrectly.
I tormented him like this for an hour at 7V. But nothing burned, nothing got hot.

I was testing an older version of SO8. I don't know how others.

In the current situation, your articles about exotic MCUs will probably gain popularity

piotr_go wrote:

Only after exceeding 7V the system began to work incorrectly.

And did you feed the pins (as inputs) 7V or GND at that time?

The pins according to the specification are "VDD+4.0V". I don't think there would be a problem. I did not try.

I wonder about the power consumption. uC with an LED less than 1mA? can that be true?

Measurement error +- x digit.
Checked with better meter: 4,73 mA at 3,3V.
3,35mA when LEDs disconnected.

New chip revision: 3,06mA when LEDs disconnected.

ok, thanks!
but that is very good, too.

The Problem with Reset switch to GPIO is a date-of-production problem?
If so, is there a Production Nr. on the Packaging?

Sam.Aux wrote:

The Problem with Reset switch to GPIO is a date-of-production problem?

Yes, but only for TSSOP20 (OTS19501).
Older SO8 (OTS23501) have switched pins 6 and 7.

=======================

One more update.

New chip revision (OTS37166) 2,75mA when set to 32MHz and do nothing:

Thank you for this detailed answer.
I think this is a rare and worthy information.

I'm just trying to get around HC32F110C4 in Keil. Libraries and sample code for peripherals are available, so it looks very promising - so far it has compiled. I do not know yet if it is possible to bite programming and debugging via J-link or STLink v2 directly from Keila, because on Keila's pages they only write about their ULINK devices

Zbig63 wrote:

I'm just trying to get around the HC32F110C4

F110 or L110?

Of course the HC32L110. From the momentum after 32 I wrote F, because I'm mainly in STMs

I ordered a few as they were, but didn't have time to take care of them.

Successfully launched. And I immediately found the incompatibility of the startup file with the Keila libraries . It doesn't bode well for the future, but maybe it won't be that bad.

Another curiosity, PUYA PY32F003L24D in DFN8:

3x2mm, 7 IO, 24MHz, 16kB flash, 2kB ram, DMA... 1.7v...5.5v
Not soldered yet. I ordered a PCB with DIP adapters.

Hi!

I've been playing with this chips for several months.

It was a rough start but I eventually found everything for it.
This chip seems to be a slower version of the HK32F0301M, running at 32MHz instead of 48MHz, but has the same memory.
The registers from.the 0301M exist and can be used, you can enter standby mode (less than 1uA), also SAWU (Standby timer) works. This is not AWU, but a different timer.

Note that standby mode is a different mode than stop or sleep states, everything is off, the CPU can wake from the sawu timer or an external signal, but will behave like a reset, nothing is kept except two 16-bit backup registers.

The flash has no prefetch or cache, but it's 32-bit wide, so it loads two thumb instructions at a time.
It will execute both instructions without any delay, then wait the specified wait states.
So, for 1 flash wait state, the CPU wastes 1/3 cycles, (execute 2, wait 1) and with 2 wait states it will waste 50% (execute 2, wait 2).

I've also hacked cubeIDE to use other MCUs, I can compile, program and debug this MCU just fine!
Note that Stink can't be used, it makes it own genuine checks, so Jlink must be used.
A DIY Jlink using a BluePill works great!

By tweaking the HSICAL register, I've sucesfully overclocked them to 96MHz with 1 flash wait states, or 48MHz with 0 wait states.

For more stuff check my thread at eevblog!

https://www.eevblog.com/forum/microcontrollers/$0-25-hk32f030m-(cortex-m0-32mhz-16kb-2kb

Now I'll try the Puya PY32F002/3/30 series

Regards!