$0.11 PY32F002A: Cortex-M0+ MCU, actually a PY32F030! 32/4KB, 48MHz, PLL, DMA...

[DavidAlfa]

To avoid bloating my HK32F030M thread, I'll be posting the PY32F002A bits here.

Links:
Puya gitee repo: Docs, libs, software...
Puya support pack 1: Docs, libs, ISP software...
Puya support pack 2: Similar contents but newer, has english datasheets & RM.
IOSetting's repo containing py32 template and libs.
MCU-Flash-Tools. Python-based ISP bootloader tool for WCH and PY32 mcus, removing the dependency of Puya-ISP.

Tested so far:
- Bootloader. Pulling PB6 (BOOT0) high before power-on (Or resetting afterwards) enters the embedded bootloader, just like in STM32.
  Connect RX/TX to PA2/PA3, open Puya ISP, everything works.
  Thread showing PuyaISP:  https://www.elektroda.pl/rtvforum/topic3951956.html


- STM32 CubeIDE: The patch works, I was able to program & debug using JLink.
  CubeIDE Patch adding support for several devices, including PY32.
  PY32 folder with docs and CubeIDE PY32F030 sample project. Patch must be applied before attempting to open this project, otherwise CubeIDE will crash.

  Jlink doesn't support this chip yet so you must manually add it. Place IOSetting's PY32 folder following this instructions:

OS                     Location
Windows             C:\Users\<USER>\AppData\Roaming\SEGGER\JLinkDevices
Linux                  $HOME/.config/SEGGER/JLinkDevices
macOS               $HOME/Library/Application Support/SEGGER/JLinkDevices

Alternatively, you can convert a ST-Link into JLinkEDU, but it will block any attempts to use non-ST devices.
The solution is to edit the XML file and change the vendor to ST (ChipInfo Vendor="ST" ).
But if the device already exists in Jlink software, then you must change the device name, for example "_py32f002af15p6".
Then set this device name under Jlink configuration.
DO NOT do this for commercial purposes. Most people can't afford $100 programmers to just blink some leds.

So far this chip seems to contain the same die as the PY32F030x6, with the same 4/32KB. PLL, DMA, 2nd UART & SPI...
More info: https://www.elektroda.com/rtvforum/topic3946116.html

Tested so far:
 - 32KB flash
 - 4KB RAM
 - PLL (48MHz)
 - 2xSPI, 2xUSART
 - DMA

After setting RDP1, I could no longer program or erase it with J-Link, I had to use PUYA ISP, setting BOOT=1 to enter the serial bootloader and running "Clear chip".


Edit: Fix PCB:
- Missing GND trace for CH340E !!
- CH340E RTS/DTR not working as expected, removed them.
- Fix BOOT0 button, pull pin high instead low.

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

The board doesn't need to be fully populated. Actually just the LDO and few caps and you'll have a working board.
You can add the rest of functionalities depending on your needs.


I also extracted the factory bootloader located at 0x1FFF0000, just in case anyone wants to tinker with it in Ghidra/IDA.

[DavidAlfa]

The USART2 is definitely there!
I'm toggling the pin AF before transmitting, PA2 AF1=TX1, AF4=TX2.

Edit:
Confirmed the PLL is also present and works, the system boosts to 48MHz.
Overclockability beyond this point is weak, not reaching even 64MHz without crashing.
Could It be the reason it's being sold as a 24MHz part? Perhabs.
As stated in the Elektroda thread, the HSI TRIM value is not restored on system reset, so be careful (PLL has no issues here).


Edit2: Also DMA works. This chip has an amazing value for the cost!

[prosper]

i played with iosetting's environment and its examples, and can confirm that the 002 can be treated as an 030. pll, dma, flash, and sram were tested and work for me.

[DavidAlfa]

I finished adding CubeIDE support for all PY32F0xx devices.
Updated the CubeIDE patch and added a PY323F030 sample project in the main message.
IOSetting's LL libraty worked great after setting the project up.

[iMo]

Does the IDE support double precision floating point math on this device?

[brucehoult]

Does the IDE support double precision floating point math on this device?

It would be very strange if it didn't. Using the compiler's runtime library software emulation, of course. Which might eat half of your flash.

[iMo]

Yep, would be great to test it somehow, how it fits.
64kB flash would be handier, however..

PS: the + - * / sqrt would be ok for most cases (ie while messing with 6-7digits DMM values).

[iMo]

Like this test for example:

Code: [Select]

// Double precision math TEST by iMo and AI

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <math.h>

#define NUM_SAMPLES 100

double calculate_mean(double* data, int n) {
    double sum = 0.0;
    for (int i = 0; i < n; i++) {
        sum += data[i];
    }
    return sum / n;
}

double calculate_standard_deviation(double* data, int n, double mean) {
    double variance = 0.0;
    for (int i = 0; i < n; i++) {
        variance += (data[i] - mean)*(data[i] - mean);
    }
    variance /= n;
    return sqrt(variance);
}

int main() {
    // Seed the random number generator
    //srand(time(NULL));

    double random_numbers[NUM_SAMPLES];

    // The rand() function computes a new pseudo-random number in the interval 0 to RAND_MAX
    // #define RAND_MAX  0x3fffffff

    // Generate 100 random double fp numbers between 9.99999 and 10.0
    for (int i = 0; i < NUM_SAMPLES; i++) {
        random_numbers[i] = 9.99999 + ((double)rand() / RAND_MAX) * (10.0 - 9.99999);
    }

    // Calculate the mean of the 100 samples
    double mean = calculate_mean(random_numbers, NUM_SAMPLES);

    // Calculate the standard deviation of the 100 samples
    double std_deviation = calculate_standard_deviation(random_numbers, NUM_SAMPLES, mean);

    //printf("Sample Mean: %lld\n", (long long)(mean*1e15));
    //printf("Sample Standard Deviation: %lld\n", (long long)(std_deviation*1e15));

    printf("Sample Mean: %d\n", (int)(mean*1e8));
    printf("Sample Standard Deviation: %d\n", (int)(std_deviation*1e14));

    return 0;
}

Sample Mean: 999999533
Sample Standard Deviation: 293668347

//Sample Mean: 9.999999533124507
//Sample Standard Deviation: 0.000000293668347

[brucehoult]

Now you're including not only DP calculation, but also printf that supports DP FP. That's another thing again.

[iMo]

ok fixed above
PS: alternative int32 print, such we can see something printed out, what is the "test" is how it fits into the flash of these CM0 gadgets..

Code: [Select]

    printf("Sample Mean: %d\n", (int)(mean*1e8));
    printf("Sample Standard Deviation: %d\n", (int)(std_deviation*1e14));
Sample Mean: 999999533
Sample Standard Deviation: 293668347

[DavidAlfa]

It's ARM and GCC, not a strange architecture with propietary compiler, so of course it supports that.

[iMo]

And how does it fit inside? Provided you already work with the gcc and the chip - could you cut and paste the source above, build it and look at the flash mem used, plz?

[DavidAlfa]

Like this test for example

You know this is a pretty terrible example for a small MCU, where you normally would try to avoid printf etc at all costs 
But anyways, compiled with -Os. Without your code, flash usage is 508 Bytes, of which 192 are the ISR vectors.

[iMo]

I've installed new Cube and built my example for an STM32F030R8 with the HAL there -> 17.3kB flash. Lot of HAL stuff re system config and UART. You've done it with LL thus you've saved precious ~4kB ..

[DavidAlfa]

I did with LL, but using PY32 lib, not CubeMX.
Also there was no system initialization (Clock, etc), just the main() with your code.
Some HAL functions can get really heavy, I remember seeing 1KB used by the oscillator/clock initialization alone!

[iMo]

1020bytes oscRCC, pretty heavy, indeed..

[DavidAlfa]

Plus the aeabi routines, also used by that function.
If you tweak so it only handles the default speed instead all combinations, it'll get a lot smaller.
Or use LL for the clock, it might improve.

[iMo]

I've patched the latest Cube with your above patches. Now - does it allow to see the PY/HK chips in the mcu type selector? Or how do you use the patches actually?? I am happy to use them with the Cube's HAL at this stage.

[DavidAlfa]

Yes, check the new picture I added to the 1st message.
But anyways you will likely want to use the libs, check the 1st message again with the py32 folder.

[danymogh]

which programmer are you using to connect to the PY32?

I have a st link v2 which i converted to DAP link but neither KEIL nor puya programmer don't detect it.

in the vendor pack there are 2 manuals regarding this PY-LINK programmer which seems to be a modified Jlink but I found no resources or a place to buy it.

in the manual, It just selects DAP-link to connect to the MCU so I suppose any DAP link would be ok, however, it seems that's not the case.

so which clone programmers are you using to connect to it? would the Jlink OB work?

[DavidAlfa]

More important, what software are you using? The programmer is just the interface!

I'm using patched CubeIDE (But anything able to use Jlink will work).
For DIY /Learing you can convert a STLINK into JLINK, though you'll need custom JLinkDevices to fake them as ST parts.
Not hard, please use ethically.

Alternatively, if you are only programming (Not debugging), then simply use a serial converter and Puya ISP!

[danymogh]

Thanks for the tip.

I ended up finding this repo
https://github.com/RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO
and will turn one of my bluepills to CMSIS-DAP and will test it.

Is there any program that supports the Puya programmer software? where is the Py-link available ?

[DavidAlfa]

Puya ISP is the software itself. Connect the serial converter to Rx/Tx, set boot=1, that's all it takes.
I have no idea what to use for PyLink.

[danymogh]

I finally managed to get it working.

I first used a USB TTL as you described and connected to it by Puya ISP. I had to pull up Boot0 pin.
The software is a bit tricky. I had to reset the VDD after every program or chip cleared. (I'm not using DTR or RST).
Also if you attempt to readout a read-protected chip it automatically clears the chip!

Then I converted a Bluepill to a CMISIS-DAP and managed to get it to work with KEIL. the standard SWD, SWCK, VDD, GND, and Reset.

I can now use the debug features. however, It doesn't work with Puya Programmer.

Is there any way to set the option bytes with CMSIS-DAP?

[DavidAlfa]

Tricky? Couldn't be easier!

Mcu info doesn't clear the chip automatically, just shows it's protected.
Download code does... exactly that!
It will reset automatically on erasing/programming, if you permanently pull boot high, it'll enter bootloader again.
(So if you plan to do multiple operations, leave boot high all the time)
If you want it to execute the program automatically without releasing boot0, tick "Use GO command".

[danymogh]

Very strange , I have the same config but mine automatically erases the chip after attempting to read the data.

I noticed in your first post you mentioned to programed the RDP using Jlink and then had to use puya isp to reset it.

How did you set RDP using Jlink? is it possible to program optionbyes using Jlink or cmsis dap ?

[DavidAlfa]

I said I had set RDP, not that I used Jlink for that. In fact I did it with code:

Code: [Select]

FLASH_OBProgramInitTypeDef pOBInit;

LL_FLASH_OBGetConfig(&pOBInit);

if(pOBInit.RDPLevel != OB_RDP_LEVEL_1){
    pOBInit.OptionType = OPTIONBYTE_RDP;
    pOBInit.RDPLevel = OB_RDP_LEVEL_1;
    LL_FLASH_Unlock();
    LL_FLASH_OB_Unlock();
    LL_FLASH_OBProgram(&pOBInit);
    LL_FLASH_OB_Lock();
    LL_FLASH_Lock();
    LL_FLASH_OB_Launch();
}

If you want a quick program for testing, here's one.
It loops USART1 (PA2, PA3), all you send is TX'ed back using DMA (115200 baud).
Also there're 3 leds: PA0, PB0, PB1 (Meant to be a RGB led), connect them to VDD trough a resistor (The mcu pulls low to lit it).
Just like the schematics in the 1st post, as I'm using that board.

[DavidAlfa]

I tried, and it can be set while programming by modifying the linker script:

Code: [Select]

MEMORY
{
  RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = 4K
  FLASH (rx)     : ORIGIN = 0x08000000, LENGTH = 32K
  RDP (r)    : ORIGIN = 0x1FFF0E80, LENGTH = 4
}

/* Define output sections */
SECTIONS
{
  .rdp :
  {
    KEEP(*(.rdp)) /* .rdp section */
    KEEP(*(.rdp*))
  } >RDP

Then defining the value:

Code: [Select]

// RDP 0
__attribute__((section(".rdp"))) const uint32_t rdp = 0x4155beaa;

//RDP 1
__attribute__((section(".rdp"))) const uint32_t rdp = 0x41aabe55;
But be careful, setting BOOT1 will make BOOT0 unable from entering the bootloader (boot0 & boot1 high boots from ram instead).
Better simply to not touch RDP unless you really want to protect it (For production, etc).
Interestingly, after setting RDP1 this way, PUYA ISP doesn't complain for readout protection, it still reads the MCU, though it's all 0xFF.

Also, the default value stated in the RM seems wrong, it says it's 0x0155BEAA but should be 0x4155BEAA.
(The upper 16 bits are the lower 16 bits, inverted).
The 2nd byte (0xBE) byte defines the behaviour of nRST, BOOT1 (Not available as pin), BOR, IWDG, WWDG...
Read the referece manual to find out what these bits mean, section "Flash option byte".

Also, Puya ISP won't work properly if you set RDP like this, it crashes when opening the hex file.
Don't enable bin generation, it will fill the gap between the end of the flash (0x8008000) and the start of RDP(0x1FFF0E80), making a giant file of 383MB.

[prosper]

you should be able to write opt from within your application, or, attach GDB to it (with the DAP and pyocd) and write the bytes manually

(gdb) set *((unsigned int *) 0x1FFF0E80) = <value>



you could include a gdb one or two liner in your makefile.

[DavidAlfa]

So I'm having a really weird situation.

Edit:
I set everything to fit 100% to the official PY32F002A specs, leaving the code to the very minimum...
Now it only uses Systick and Timer1.

Timer1 capture triggers in any falling edge, sets "new_capture" variable when detected and stops itself.

Systick isr monitors this variable, sets a led indicating a new capture was received and restarts the capture timer.
It also toggles a second led indicating the system is working.

Systick isr has the highest priority, so no other IRQ can execute over it except HardFault.

It all works as expected, no matter the optimization level.
When I set RDP1, it will randomly freeze when toggling the input capture signal, killing everything.
I made a checkum of the entire flash before and after locking, printing it through serial, it matched.
This also happens if I set RDP using PuyaISP.
I only know it's not a HardFault, as it has a routine that quickly flashes the led.
I can trigger it by accessing unimplemented memory, but it's not being called when this strange fault happens.
I even filled all the empty NVIC entries in case it was triggering some undocumented vector... nope.

I can attach the debugger, as RDP is set I can only see the cpu registers, the PC can be read so I have a slight idea of what's going on.
The debugger halts when toggling the capture input, so clearly there's some exception happening.

...Target halted (Vector catch, PC = 0xFFFFFFFE)
Reading common registers: Read register 'r0' (4 bytes) from hardware: 0x0000000A
Read register 'r1' (4 bytes) from hardware: 0x05000000
Read register 'r2' (4 bytes) from hardware: 0x01000000
Read register 'r3' (4 bytes) from hardware: 0x01000000
Read register 'r4' (4 bytes) from hardware: 0xE70B0020
Read register 'r5' (4 bytes) from hardware: 0x01000000
Read register 'r6' (4 bytes) from hardware: 0xDC0BFF1F
Read register 'r7' (4 bytes) from hardware: 0xD80B0020
Read register 'r8' (4 bytes) from hardware: 0x24B763A1
Read register 'r9' (4 bytes) from hardware: 0x64020020
Read register 'r10' (4 bytes) from hardware: 0x1BD00CED
Read register 'r11' (4 bytes) from hardware: 0x273F3419
Read register 'r12' (4 bytes) from hardware: 0x00E0FFFF
Read register 'sp' (4 bytes) from hardware: 0xB80B0020
Read register 'lr' (4 bytes) from hardware: 0xF9FFFFFF
Read register 'pc' (4 bytes) from hardware: 0xFEFFFFFF
Read register 'xpsr' (4 bytes) from hardware: 0x03000061
WARNING: Failed to read memory @ address 0xFFFFFFFE
Read 4 bytes @ address 0x20000BD4 (Data = 0x61000000)
Reading 64 bytes @ address 0x20000BC0
WARNING: Failed to read memory @ address 0x0800080C
WARNING: Failed to read memory @ address 0x08001EFA
WARNING: Failed to read memory @ address 0x08001EFA
Read 4 bytes @ address 0xE000ED04 (Data = 0x00420003)
Read 4 bytes @ address 0xE000ED0C (Data = 0xFA050000)
Read 4 bytes @ address 0xE000ED04 (Data = 0x00420003)
Read 4 bytes @ address 0xE000ED1C (Data = 0x00000000)
Read 4 bytes @ address 0xE000ED20 (Data = 0x00000000)
Read 4 bytes @ address 0xE000ED24 (Data = 0x00000000)
Read 4 bytes @ address 0xE000ED08 (Data = 0x08000000)
Read 4 bytes @ address 0xE000E010 (Data = 0x00000004)
Read 4 bytes @ address 0xE000E014 (Data = 0x000F398E)
Read 4 bytes @ address 0xE000E018 (Data = 0x009F0E6E)
Read 4 bytes @ address 0xE000E01C (Data = 0x80000000)
Read 4 bytes @ address 0xE000E01C (Data = 0x80000000)

[danymogh]

your PC = 0xFFFFFFFE

that's an invalid address. if this happens only when RDP is set then it might have to do with flash protection options.

have you read Table 4-8 from the English reference manual?

Edit : try to apply the RDP protection from outside the code. (from PuyaISP) see if that changes anything.

[DavidAlfa]

your PC = 0xFFFFFFFE
that's an invalid address

I know!

try to apply the RDP protection from outside the code. (from PuyaISP) see if that changes anything.

I forgot to mention that. Yes, it also happens. Thats's what made me think of a real hardware issue.

It's not the flash, as I said I checksumed the entire 32K, before and after locking and the result matched.
Also I could write to the flash in the code after setting RDP.
The executed code is always the same...

I attached the binary just in case you want to try, RDP disabled.

MCU:PY32F002AF15P6TU
System LED: PB1, active low
CCP LED: PB0, active low
CCP input: PA1, falling edge, internal pullup.
Oscillator: Internal 24MHZ HSI
Leds are active-low, connected to VDD, the mcu pin pull it low when active.

Nothing else is required. Just poke the CCP input and see the CCP led doing stuff.
If RDP is enabled, it will randomly stall.

Without RDP it can run for hours. 

[DavidAlfa]

Made it so the led blinks for only 1ms when a falling edge is detected.
Led duration is not very accurate, as it can happen right after a systick IRQ, so it might remain enabled anywhere between 1 and 2ms.
Not the problem here!
100Hz CCP signal, when RDP off it runs forever.
With RDP on, it crashed after 2 seconds or so.
The system only crashes when toggling the ccp input, otherwise it will run fine.
Time for crashing is random, sometimes it happens in 100ms, others in 3 seconds.

[bingo600]

@David

ATM i just have two F002 devel boards, same mcu as you.

I can't really test, will loose my "chip"
I'm quite sure you wrote that only the puya programmer could clear the read protection.
And the puya programmer s Win-only, i'm linux only.

Hope someone else can help out.

/Bingo

[DavidAlfa]

Might it work in Wine? I tried but it's not recognizing the serial ports...

Edit: It's only happening if more than one interrupt is enabled.
Seems like some sort of stack corruption? One interrupt happens over other one, then the it restores a wrong or corrupted context?
If I disable systick it won't happen. But this will also happen if any other interrupt is running.
It can't get any simpler than this!

Code: [Select]

#include "main.h"

volatile uint8_t new_capture;

/*--------------------------------------------------*/
void system_init(void)
{
  LL_RCC_HSI_SetCalibFreq(LL_RCC_HSICALIBRATION_24MHz);
  while (LL_RCC_HSI_IsReady() != 1);

  LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOA | LL_IOP_GRP1_PERIPH_GPIOB | LL_IOP_GRP1_PERIPH_GPIOF);
  LL_APB1_GRP2_EnableClock(LL_APB1_GRP2_PERIPH_TIM1);

  WritePin(RED,1);
  WritePin(BLUE,1);
  LL_GPIO_Init(CCP_Port,  &(LL_GPIO_InitTypeDef){ CCP_Pin,  LL_GPIO_MODE_ALTERNATE, LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL, LL_GPIO_PULL_NO, CCP_AF });
  LL_GPIO_Init(RED_Port,  &(LL_GPIO_InitTypeDef){ RED_Pin,  LL_GPIO_MODE_OUTPUT,    LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL });
  LL_GPIO_Init(BLUE_Port, &(LL_GPIO_InitTypeDef){ BLUE_Pin, LL_GPIO_MODE_OUTPUT,    LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL });

  LL_TIM_Init(CCP_TIM, &(LL_TIM_InitTypeDef){ 23, LL_TIM_COUNTERDIRECTION_UP, 65535, LL_TIM_CLOCKDIVISION_DIV1, 0});                              // 1MHz clock, 65ms overflow
  LL_TIM_IC_Init(CCP_TIM, CCP_CH, &(LL_TIM_IC_InitTypeDef){ LL_TIM_IC_POLARITY_FALLING, LL_TIM_ACTIVEINPUT_DIRECTTI, LL_TIM_ICPSC_DIV1, 4 });      // Falling edge
  LL_TIM_EnableCounter(CCP_TIM);

  NVIC_SetPriority(TIM1_CC_IRQn, 1);
  NVIC_EnableIRQ(TIM1_CC_IRQn);

  SysTick_Config(24000);      // 24MHz cpu clock, 1ms period.
}

/*--------------------------------------------------*/
void capture_start(void)
{
  LL_TIM_ClearFlag_CC4(CCP_TIM);
  LL_TIM_EnableIT_CC4(CCP_TIM);
}

/*--------------------------------------------------*/
int main(void)
{
  uint32_t red=0, blue=0;

  system_init();
  capture_start();

  while(1)
  {
    /*-------------*/                 // Handle red led
    if(new_capture)
    {                                 // Turn on the red LED for some time when a capture is received.
      new_capture=0;
      red=100;                        // Load led counter
      capture_start();                // Start a new capture
    }
    else if(red && !--red)            // Decrease led counter until 0
      WritePin(RED,1);                // Led expired, turn off

    /*-------------*/                 // Handle blue led
    if (!blue  || !--blue )           // Generate small pulses in the blue led as heartbeat signal
    {
      bool b = ReadPin(BLUE);
      WritePin(BLUE,!b);
      blue = b ? 1000 : 1100000;
    }
    /*-------------*/
  }
}

/*--------------------------------------------------*/
void systick_isr(void)
{
    asm("nop");       // Do nothing
}

/*--------------------------------------------------*/
void capture_isr(void)
{
  LL_TIM_SetCounter(CCP_TIM, 0);                    // Reset timer counter
  if(LL_TIM_IsActiveFlag_CC4(CCP_TIM))              // Capture flag active
  {
    LL_TIM_IC_GetCaptureCH4(CCP_TIM);               // Capture CCP value
    LL_TIM_DisableIT_CC4(CCP_TIM);                  // Disable CC interrupt
    LL_TIM_ClearFlag_CC4(CCP_TIM);                  // Clear flag
    WritePin(RED,0);                                // Turn led on
    new_capture=1;                                  // Set flag
  }
}


[bingo600]

Seems like some sort of stack corruption? One interrupt happens over other one, then the it restores a wrong or corrupted context?

And still only when RDP is enabled ??

/Bingo

[DavidAlfa]

Yes! That's why I started this. Otherwise I would think it was my fault.

The code should not be affected in any way by RDP!
I left it with RDP off, receiving 200Hz pulses from the generator for more than an hour, no problem!
Same file, programmed setting RDP in PuyaISP - crashes in 1-2 seconds.
How is that?!

So anything planned to be sold and RDP-protected - back to stm32 LOL.
I knew something had to happen at some point

[danymogh]

That's a big problem if it really is a problem on the chip level.
AFAIK they buy or implement the cortex M0+ core as is on the chip and only add peripherals. what you described is on the core level which means the core is faulty somehow?

I think it needs a little more digging.

[DavidAlfa]

I sent a mail to Puya, I don't expect getting any solution3 but who knows.
Meanwhile this will be my own fix: 
https://a.aliexpress.com/_Eu8sh0B

[man_anyone]

Did you test the hk32f030 to see if it has the same problem? Maybe there's a common thing that all Chinese MCUs cheap out on that leads to this problem
Maybe we can get help from hangshun too if their MCU has the same problem

[PCB.Wiz]

Or other PUYA MCU, do they have the same issue?

[DavidAlfa]

The HK only had a small issue, requiring power cycling after programming. Yeah this same project is working in the HK, in fact I've sold a few.
I tried migrating to the PY32 as it's a better mcu overall while less than half the price, but didn't go as planned.

[man_anyone]

What about trying other puya MCUs? Also try other units maybe this one is defective

[DavidAlfa]

I tried 3 chips, all had the same behaviour.
So I tried moving the interrupt vector table to the SRAM as @bingo600 suggested.
The issue is gone! Working now!
Created a PR at IOSetting's repo.

However this is not optimal, anyone could dump the flash by overwriting the sram, for example placing custom code in the systick ISR or changing the vector addresses.
After that, you can place up to 4KB of code... you can do anything with so many space!

[bingo600]

 

Longshot ... but it worked out 

@David
Thank you for the PR 

/Bingo

[DavidAlfa]

Yeah but it's not ok... leaves the system poorly protected!

[bingo600]

However this is not optimal, anyone could dump the flash by overwriting the sram, for example placing custom code in the systick ISR or changing the vector addresses.
After that, you can place up to 4KB of code... you can do anything with so many space!

Can you (a debugger) still write to the ram if it's protected , or do you mean "buffer overflow" attack ??

[DavidAlfa]

Yeah, a debugger has complete access to the ram.
Systick vector is now placed at 0x2000003C:
You could halt the system, load a program into 0x20001000, made to dump the flash through the serial port, and write that address to systick vector.
When the IRQ triggers, game over!

At least I can mitigate this by disabling SWD port and setting the nRST config bit.
The reset pin function becoems completely disabled, even when shorting the reset pin before power is applied, it no longer works.
Then I have a special unlock procedure in the code that resets the RDP, this completely erases the mcu so it can be accesed again.

nBOOT1 config bit switches between bootloader mode ad system ram booting. Not sure what would be the safest!
Let me guess.. Burn the pin down!

[prosper]

I don't understand the vulnerability. If you have debug, can't you *already* modify SRAM, and then point the program counter wherever you want to execute arbitrary code?

[DavidAlfa]

I guess you could also write to VTOR with the debugger, yeah!
Well, if possible at all, nRST=OFF, BOR=ON, SWD=OFF and BOOT1=OFF should give plenty of headaches to the attackers  .

[DavidAlfa]

So these are are my locking / unlocking routines:

Code: [Select]

// Call with lock=1 to set RDP1, also disabling RESET pin and bootloader
// Call with lock=0 to disable, though if already locked it will erase everything, nothing can be done about it.
void rdp_set(bool lock)
{
  FLASH_OBProgramInitTypeDef pOBInit;
  LL_FLASH_OBGetConfig(&pOBInit);
  bool lock_state = (pOBInit.RDPLevel == OB_RDP_LEVEL_1);

  if(lock_state != lock)                                                              // current state not same as requested
  {
    pOBInit.OptionType = OPTIONBYTE_RDP | OPTIONBYTE_USER;                            // Update user and RDP bits
    pOBInit.RDPLevel = lock ? OB_RDP_LEVEL_1 : OB_RDP_LEVEL_0;                        // Set RDP mode

    if(lock)
    {
      pOBInit.USERConfig =  OB_RESET_MODE_GPIO | \                                    // Disable Reset function, enable BOR
                            OB_BOR_ENABLE | OB_BOR_LEVEL_3p1_3p2 | \                  // Enable BOR to 3.2V
                            OB_IWDG_SW | OB_WWDG_SW | \                               // Disable HW watchdog enforcement
                            OB_BOOT1_SRAM;                                            // When BOOT1=SRAM, BOOT0=1 boots from SRAM instead the bootloader
    }
    else
    {

      pOBInit.USERConfig =  OB_RESET_MODE_RESET | \                                   // Disable Reset function, enable BOR
                            OB_BOR_DISABLE | OB_BOR_LEVEL_3p1_3p2 | \                 // Disable BOR, set default level
                            OB_IWDG_SW | OB_WWDG_SW | \                               // Disable HW watchdog enforcement
                            OB_BOOT1_SYSTEM;                                          // When BOOT1=SYSTEM, BOOT0=1 boots the bootloader
    }
   
    LL_FLASH_Unlock();                                                                // Unlock Flash
    LL_FLASH_OB_Unlock();                                                             // Unlock OB
    LL_FLASH_OBProgram(&pOBInit);                                                     // Program config. Going RDP1->RDP0 instantly wipes the entire system, but still need a cycling the power to reload the RDP config.
    LL_FLASH_OB_Launch();                                                             // Force OB reload (This normally restarts the system)
    NVIC_SystemReset();                                                               // Just in case
  }
}


[DavidAlfa]

Bingo600, as you asked in PM, here's a very simple example showing how to lock and unlock RDP.
PB0 = button to GND.
PB1 = RED led ( To indicate lock)
PB3 = GREEN led (Activity and unlocked indicator)

LEDS are active low - Connect between VCC and the mcu pin through a 470R-1K resistor.


Simply flash it - RED will be steady on, GREEN blinking as "I'm alive".
Press button - GREEN will be steady on, RED off. MCU will be wiped, cycle power to update RDP security, Jlink will be able to program it again.

Just in case, I'm only setting RDP1 in this test, not disabling nRST or BOOT0, at $0.11 it's cheap but better to not brick any! (I'm using the "full" mode myself, works perfect).

[bingo600]

Thanx David 

I'll see if i can do a test in the weekend.

What pin should i apply the 9KHz signal to ??

Ahh .. This guy doesn't seem to have the timer stuff ...
Well i'll give it a shot this weekend ...

I'll have to setup Cube .... According to your instructions...
I'm (ATM) more of a "makefile guy" 

Do you use "just" CubeMX , or also CubeIDE ?
I don't even think i have CubeIDE downloaded.

/Bingo

[DavidAlfa]

I use the IDE as only that - IDE.
Provides editor, compiler and debugger all in one - that's why I patched it.
CubeMX is for ST products, I don't have interest in it, the M0+ is pretty easy to setup using low level libs,  that's what I use.

Yeah sorry I forgot! Will make it tomorrow.
For now just test that the unlocking works, it should!
It's not speed dependand, I crashed it with only few Hz, 100Hz would do it very quick.
Seems something related to the capture edge happening at precise wrong moment.

Normally this would read a IR signal with NEC protocol, the fastest pulse is 500-600us, this would crash it in the first remote button press (Doing fine now).


But as I say just anything at CCP crashed it with RDP set.
Maybe a sync bug, I don't know.
Anyways, it's fine now!

[bingo600]

Well

I'm postponing the 1GB 
CubeIDE install for now ....

I "whipped up" a makefile instead ...
Btw .. It expect the "Arm GCC bin" directory to be on the path

I also included the BIN & HEX it created ... Mine is 2.4K with  -oS

Made by : gcc-arm-none-eabi-8-2018-q4-major

Code: [Select]

  LD Build/main.elf
Memory region         Used Size  Region Size  %age Used
             RAM:         336 B         4 KB      8.20%
           FLASH:        2360 B        32 KB      7.20%
             RDP:          0 GB          4 B      0.00%
  OBJCP BIN Build/main.bin
  OBJCP HEX Build/main.hex

made by :   arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi

Code: [Select]

  LD Build/main.elf
/home/cfo/arm/arm-gcc/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: warning: Build/main.elf has a LOAD segment with RWX permissions
Memory region         Used Size  Region Size  %age Used
             RAM:         336 B         4 KB      8.20%
           FLASH:        2420 B        32 KB      7.39%
             RDP:          0 GB          4 B      0.00%
  OBJCP BIN Build/main.bin
  OBJCP HEX Build/main.hex


I would have expected 12 to produce less code than 8q4

Well ...

Made by: arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi

Code: [Select]

  LD Build/main.elf
Memory region         Used Size  Region Size  %age Used
             RAM:         336 B         4 KB      8.20%
           FLASH:        2408 B        32 KB      7.35%
             RDP:          0 GB          4 B      0.00%
  OBJCP BIN Build/main.bin
  OBJCP HEX Build/main.hex


Made by: gcc-arm-none-eabi-10-2020-q4-major

Code: [Select]

  LD Build/main.elf
Memory region         Used Size  Region Size  %age Used
             RAM:         336 B         4 KB      8.20%
           FLASH:        2336 B        32 KB      7.13%
             RDP:          0 GB          4 B      0.00%
  OBJCP BIN Build/main.bin
  OBJCP HEX Build/main.hex


Made by: gcc-arm-none-eabi-9-2019-q4-major

Code: [Select]

  LD Build/main.elf
Memory region         Used Size  Region Size  %age Used
             RAM:         336 B         4 KB      8.20%
           FLASH:        2344 B        32 KB      7.15%
             RDP:          0 GB          4 B      0.00%
  OBJCP BIN Build/main.bin
  OBJCP HEX Build/main.hex



/Bingo

[DavidAlfa]

Ahh 1GB.. it's 2023 not 1999! 
Yeah yu don't really need the IDE for anything, but you'll have to write the makefile then, I prefer it to be done automatically

[bingo600]

Ahh 1GB.. it's 2023 not 1999! 
Yeah yu don't really need the IDE for anything, but you'll have to write the makefile then, I prefer it to be done automatically

I even think CubeIDE can export a Makefile or

Btw: I'm quite sure the STM Doc said i needed 15G disk.
I might install it anyways ... Later ...

[DavidAlfa]

So here's the CCP test.
I attached two versions of the binary, one placing irq vectors in flash, other placing them in sram (Which should never fail).

Usage is pretty simple:
- Any falling edge at CCP pin pulses the green led for 1-2ms (Not precise as CCP input it's not synced with systick).
- If there's no CCP activity for >1 second, the green led starts pulsing at 1Hz pulse to show it's alive.
- Pressing the button will toggle RDP, blinking the red led if setting RDP1 or the green led for RDP0.
   - It'll keep blinking until you release the button + 1 second.
   - Doing RDP1->RDP0 wipes the system, needs power cycling to update the RDP security.
- The red led turns ON if RDP1 is set.

With FLASH vectors and RDP1, at some point you'll notice the system completely dies when toggling the CCP input.

For your PY32F003 chips: Use the same pin names (PA1, PA5, PB0, PB1), not the pin numbers!

[bingo600]

Thanx David

Will solder a PY32F003F18P6TU  on a breakout board today.
And might solder a PY32F002AW15S6TU on a board too (SOP-16 should be "easy")

Just for fun i added some arm-gcc compile results of the RDP program to the post above.
I am now using the arm-gcc 10 , as the default.  What version do yo use ??


This is what gcc-arm-none-eabi-10-2020-q4-major results in with the CCP program

Code: [Select]

  LD Build/main.elf
Memory region         Used Size  Region Size  %age Used
             RAM:         208 B         4 KB      5.08%
           FLASH:        2764 B      32640 B      8.47%
        SETTINGS:          0 GB        128 B      0.00%
  OBJCP BIN Build/main.bin
  OBJCP HEX Build/main.hex

/Bingo

[DavidAlfa]

ST's GCC version is a bit more optimized, I always had slighly lower usage with it.
The good part is you can call it externally just like any other gcc compiler.

[bingo600]

Oh ...

I have modified both examples RDP + CCP to use PA7 for BTN , and PB0 for Red / PB1 for Green.
My PY32F002AW15S6TU (SOP16) doesn't have PA5, and if you'd not commected out the "lock code" my SOP16 MCU would have been locked forever.

RDP

Code: [Select]

//Buttons
#define BTN_Port        GPIOA
  #define BTN_Pin       LL_GPIO_PIN_7

// LEDs
#define RED_Port        GPIOB
  #define RED_Pin       LL_GPIO_PIN_0
#define GREEN_Port      GPIOB
  #define GREEN_Pin     LL_GPIO_PIN_1
CCP

Code: [Select]

// CCP pin
#define   CCP_Port      GPIOA
  #define CCP_Pin       LL_GPIO_PIN_1
  #define CCP_AF        LL_GPIO_AF13_TIM1
  #define CCP_TIM       TIM1
  #define CCP_CH        LL_TIM_CHANNEL_CH4

// Buttons
#define BTN_Port        GPIOA
  #define BTN_Pin       LL_GPIO_PIN_7

// LEDs
#define RED_Port        GPIOB
  #define RED_Pin       LL_GPIO_PIN_0
#define GREEN_Port      GPIOB
  #define GREEN_Pin     LL_GPIO_PIN_1

// SWD interface
#define   SWC_Port      GPIOA
  #define SWC_Pin       LL_GPIO_PIN_14
#define   SWD_Port      GPIOA
  #define SWD_Pin       LL_GPIO_PIN_13

/Bingo

[bingo600]

I just tried the RDP on a PY32F002AW15S6TU (SOP-16)
Changed leds to active high.

It given an error during programming (pyOCD - DAP)

Code: [Select]

$ make flash
pyocd erase -t py32f030x6 --chip --config ./Misc/pyocd.yaml
0000872 I Erasing chip... [eraser]
0001113 I Chip erase complete [eraser]
pyocd load ./Build/main.hex -t py32f030x6 --config ./Misc/pyocd.yaml
0000874 I Loading /home/cfo/1-Arm/py32f0/git/David/PY32F030_test-cfo/Build/main.hex [load_cmd]
[==================================================] 100%
0002048 I Erased 4096 bytes (1 sector), programmed 2432 bytes (19 pages), skipped 0 bytes (0 pages) at 2.03 kB/s [loader]
0002058 E Error during board uninit: [session]

But i suppose it's ok  unint prob involve Reset , that has just been deactivated ....
Hmm RDP just sets RDP (Flas lock) ...

My "Dual led" toggles between RED & Orange (Orange = Red + Green)

When i GND PA7 , LED gets Green

Ohh ... And i have to Power reset to get swd to work again
Well ... I didn't have DAP reset connected , so the programmer couldn't reset it.

Connected DAP Reset to MCU

Code: [Select]

$ make flash
pyocd erase -t py32f030x6 --chip --config ./Misc/pyocd.yaml
0000806 I Erasing chip... [eraser]
0001051 I Chip erase complete [eraser]
pyocd load ./Build/main.hex -t py32f030x6 --config ./Misc/pyocd.yaml
0000824 I Loading /home/cfo/1-Arm/py32f0/git/David/PY32F030_test-cfo/Build/main.hex [load_cmd]
[==================================================] 100%
0001969 I Erased 4096 bytes (1 sector), programmed 2432 bytes (19 pages), skipped 0 bytes (0 pages) at 2.09 kB/s [loader]
0001975 E Error during board uninit: [session]
0001977 E Probe error during disconnect: [session]
Now 2 errors during programming

Still can't program (after PA7 Clear of RDP)

Code: [Select]

$ make flash
pyocd erase -t py32f002ax5 --chip --config ./Misc/pyocd.yaml
0000843 I Erasing chip... [eraser]
0001076 C target was not halted as expected after calling flash algorithm routine (IPSR=3) [__main__]

POR Reset works.


/Bingo

[bingo600]

I just tried the CCP on a PY32F002AW15S6TU (SOP-16)
Wo. any external pulse , it blinks briefly green (continuously).


That one behaves a bit strange , when PA7 is GND'ed


When i GND PA7 it blinks RED Continuously.
When i remove PA7 (GND) , it lights mostly RED , short pulses of green (i think)

I can't erase ....

If i connect PA7 again , it blinks green , when i remove PA7 , it lights steady green.
I can erase program chip.
Seems like it needs to times PA7 to GND
Yepp ... 2 x PA7 GND works (permanent Green) , and unlocks.
I can erase/reflash.


Program CCP - POR Reset (No external pulse)  (flow)
Green constantly blinks briefly.
PA7 GND , Red blinks , then becomes "almost steady" , short green blinks alco i think
Another PA7 GND , it blinks Green , and then steady Green.

After POR i can reflash.

Edit: Remember i have nothing connected to CCP pin .... Maybe it sees some noise (the brief green pulses)

/Bingo

[bingo600]

Now to whip up a 9KHz signal ..... Using my other py32F002 (TSSOP20) board.

I'll have to do a bit of DS studying ....

[DavidAlfa]

100Hz is enough! Or a simple push button, it'll crash really easily.

It's not behaving strangely, that's how it's supposed to work.

Activate the button (PA7), sets rdp1, reboots and turns the red led on.
Now you can't erase as it seems the device pack programming algorithm is bugged.
This didn't happen in the HKL32F030M, I clearly got a warning about it, advicing to erase the device.

Activate the button again and rdp1 is cleared, wiping the system and enabling the green led.

Same about the green led behaviour.
Have you read anything where I posted the test?

About PyOCD, I can't help. I tried using it but cmsis pack didn't work nor it was found anywhere, though it was clearly installed.


Attached same fw with button in PA7, both flash and sram vectors versions.

[DavidAlfa]

Gotta love chinese stuff.
I disassembled the FLM in ghidra, look at the blank checking function! 
- Is it blank?
- Looks at the sky while puffing on a cigar - Sure bro!

[bingo600]

I did do a "quick read" of your description of the CCP test program.
But apparently not close enough.

What i described was my experience , in no way any critisism.

Re: poOCD ... You need to put the pyocd yaml in the "main directory" , or use the --pack to point at the pack
The pack is in IOsettings Misc dir , so is the yaml file

Use 'pyocd list --targets' to see available targets.

Code: [Select]

pyocd list --targets --pack Misc/Puya.PY32F0xx_DFP.1.1.3.pack | grep -i py32
  py32f002ax5               Puya                     PY32F002Ax5                  PY32F0 Series, PY32F002     pack     
  py32f002x5                Puya                     PY32F002x5                   PY32F0 Series, PY32F002     pack     
  py32f003x4                Puya                     PY32F003x4                   PY32F0 Series, PY32F003     pack     
  py32f003x6                Puya                     PY32F003x6                   PY32F0 Series, PY32F003     pack     
  py32f003x8                Puya                     PY32F003x8                   PY32F0 Series, PY32F003     pack     
  py32f030x3                Puya                     PY32F030x3                   PY32F0 Series, PY32F030     pack     
  py32f030x4                Puya                     PY32F030x4                   PY32F0 Series, PY32F030     pack     
  py32f030x6                Puya                     PY32F030x6                   PY32F0 Series, PY32F030     pack     
  py32f030x7                Puya                     PY32F030x7                   PY32F0 Series, PY32F030     pack     
  py32f030x8                Puya                     PY32F030x8                   PY32F0 Series, PY32F030     pack     
  py32f072xb                Puya                     PY32F072xB                   PY32F0 Series, PY32F072     pack   

Still working on modifying your CCP program from input capture to output compare w. pin toggle - 9KHz  - Thats my learning task for now .... As mentioned i'm quite green with ARM ie. STM/PY.

I have never used AF pins before , and have quite some issue figuring out why you did select : LL_GPIO_AF_13
And not ie. LL_GPIO_AF_1.

Is the AF just a "Pin rerouting Matrix" , where you could have chosen any that has tim1 in the name ??
#define LL_GPIO_AF2_TIM1          LL_GPIO_AF_2   /*!< TIM1 Alternate Function mapping */

I don't understand the logic , and the PY RM has a Matric that doesn't help (me) much.

Re: Black check
I suppose FLM = Flash loader module.
Is that in the chip or some of the bin (elf) used for Jlink or ?

/Bingo

[DavidAlfa]

The AF pins are better described in the Datasheet.
You have a simple table showing how each AF source connects the physical pins to the different peripherals.


AF13 connects PA1 to TIM1_CH4.
AF1 would connect it to USART1_CTS!

LL_GPIO_AF13  and LL_GPIO_AF_13_TIM1 is the same thing, it's just a way for you to easily see wat are you interfacing to.
Does LL_GPIO_AF2 say anything to you? Not to me! I'd need to open the datasheet and look it out.
LL_GPIO_AF_13_TIM1 makes it a bit easier. I would even have used LL_GPIO_AF_13_TIM1_CH4.

[bingo600]

Thanx for the hint with the AF in the DS.
Btw do you exclusively look at the F030 documentation for the F002 ?

Re DAPLINK
I use an Air32F103 with both the (top/bottom) 5 Pins soldered at the end.   ... Think you have some of them
Use V1 hexfile ... V2 doesn't work
https://www.eevblog.com/forum/microcontrollers/air105-air32f103-new-chinese-arm-chips/msg5014411/#msg5014411

**** DON'T use the "silkscreened swd/swclk" , that you use to program the board... Won't work

Pinout as a DAPLink
PB13: SWCLK
PB14: SWDIO
PB0: RESET
PA2: TX
PA3: RX

/Bingo

[DavidAlfa]

Yeah I normally use the 030 docs. The 002 and 003 docs have the same thing, just cutting down some features.
I do check the "official" specs in case something doesn't work, like in this RDP problem, I removed all non officlal 002A features to make sure it wasn't my fault for using them, but surprise, no change!

[bingo600]

I got something kludged together to generate ~9KHz pulses on PA1
Used your CCP as base

Code: [Select]

/*--------------------------------------------------*/
void system_init(void)
{
  LL_RCC_HSI_SetCalibFreq(LL_RCC_HSICALIBRATION_24MHz);
  while (LL_RCC_HSI_IsReady() != 1);

  LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOA | LL_IOP_GRP1_PERIPH_GPIOB | LL_IOP_GRP1_PERIPH_GPIOF);
  LL_APB1_GRP2_EnableClock(LL_APB1_GRP2_PERIPH_TIM1);

  // LL_GPIO_Init(SWC_Port,   &(LL_GPIO_InitTypeDef){ SWC_Pin,  LL_GPIO_MODE_ANALOG });         // Disable SWD interface access
  // LL_GPIO_Init( SWD_Port,  &(LL_GPIO_InitTypeDef){ SWD_Pin,  LL_GPIO_MODE_ANALOG });

  LL_GPIO_Init(CCP_Port,   &(LL_GPIO_InitTypeDef){ CCP_Pin,  LL_GPIO_MODE_ALTERNATE, LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL, LL_GPIO_PULL_NO, CCP_AF });
  LL_GPIO_Init(RED_Port,   &(LL_GPIO_InitTypeDef){ RED_Pin, LL_GPIO_MODE_OUTPUT, LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL, LL_GPIO_PULL_NO });
  LL_GPIO_Init(GREEN_Port, &(LL_GPIO_InitTypeDef){ GREEN_Pin, LL_GPIO_MODE_OUTPUT, LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL, LL_GPIO_PULL_NO });
  LL_GPIO_Init(BTN_Port,   &(LL_GPIO_InitTypeDef){ BTN_Pin, LL_GPIO_MODE_INPUT, 0, 0, LL_GPIO_PULL_UP });


//https://community.st.com/t5/stm32-mcu-products/setting-the-timer-tim1-in-stm32f407/td-p/395256

  //LL_TIM_Init(CCP_TIM, &(LL_TIM_InitTypeDef){ 23, LL_TIM_COUNTERDIRECTION_UP, 65535, LL_TIM_CLOCKDIVISION_DIV1, 0});                              // 1MHz clock, 65ms overflow
  LL_TIM_Init(CCP_TIM, &(LL_TIM_InitTypeDef){ 11, LL_TIM_COUNTERDIRECTION_UP, 111, LL_TIM_CLOCKDIVISION_DIV1, 0});                              // 1MHz clock, 65ms overflow
  //LL_TIM_IC_Init(CCP_TIM, CCP_CH, &(LL_TIM_IC_InitTypeDef){ LL_TIM_IC_POLARITY_FALLING, LL_TIM_ACTIVEINPUT_DIRECTTI, LL_TIM_ICPSC_DIV1, 4 });      // Falling edge
  LL_TIM_OC_Init(CCP_TIM, CCP_CH, &(LL_TIM_OC_InitTypeDef){ LL_TIM_OCMODE_TOGGLE, LL_TIM_OCSTATE_ENABLE, LL_TIM_OCSTATE_ENABLE, 111,
                                                            LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCIDLESTATE_LOW, LL_TIM_OCIDLESTATE_LOW });      // Falling edge

  // Generates 8.97 KHz pulses

  LL_TIM_EnableCounter(CCP_TIM);
  LL_TIM_CC_EnableChannel(CCP_TIM, CCP_CH);
  LL_TIM_EnableAllOutputs(CCP_TIM);

  NVIC_SetPriority(TIM1_CC_IRQn, 1);
  //NVIC_EnableIRQ(TIM1_CC_IRQn);

  SysTick_Config(24000);      // 24MHz cpu clock, 1ms period.
}


But it seems like it's the below LL_TIM_Init that controls the Pulse duration

24M/12/111 ~18KHz ==> 9KHz Toggled

Code: [Select]

  LL_TIM_Init(CCP_TIM, &(LL_TIM_InitTypeDef){ 11, LL_TIM_COUNTERDIRECTION_UP, 111, LL_TIM_CLOCKDIVISION_DIV1, 0});                              // 1MHz clock, 65ms overflow

Whar does the 111 in this one (LL_TIM_OC_Init) do then ?

Code: [Select]

LL_TIM_OC_Init(CCP_TIM, CCP_CH, &(LL_TIM_OC_InitTypeDef){ LL_TIM_OCMODE_TOGGLE, LL_TIM_OCSTATE_ENABLE, LL_TIM_OCSTATE_ENABLE, 111,
                                                            LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCIDLESTATE_LOW, LL_TIM_OCIDLESTATE_LOW });      // Falling edge

I would have expected that one :

Code: [Select]

  uint32_t CompareValue;  /*!< Specifies the Compare value to be loaded into the Capture Compare Register.
                               This parameter can be a number between Min_Data=0x0000 and Max_Data=0xFFFF.
To control the "compare" ...


Will try tomorrow, with the 9KHz from my F002 dev board as pulse source.

Ps:
Thank you for your examples & guidance

/Bingo

[DavidAlfa]

What are you taking about? CCP doesn't generate pulses, it captures edges and triggers an interrupt.
You're using in your own way (OCP) for no reason, beyond the scope of this issue.
Please don't do that. If we're talking about apples don't come saying you got oranges
OCP is triggered internally, won't cause any issue. The issue with CCP seems caused by external, unsynced signal.

That's not what I wrote! First 11 is the prescaler,  timer freq. is 24MHz/(prescaler+1). The second is the overflow value, so the timer resets at  timer freq / (overflow+1).

Code: [Select]

  LL_TIM_Init(CCP_TIM, &(LL_TIM_InitTypeDef){ 11, LL_TIM_COUNTERDIRECTION_UP, 111, LL_TIM_CLOCKDIVISION_DIV1, 0});                              // 1MHz clock, 65ms overflow


In that example you made: 24MHz/(11+1) = 2MHz clock, timer overflows at 2MHz/(111+1) = 17.857KHz.

Whar does the 111 in this one (LL_TIM_OC_Init) do then ?

Code: [Select]

LL_TIM_OC_Init(CCP_TIM, CCP_CH, &(LL_TIM_OC_InitTypeDef){ LL_TIM_OCMODE_TOGGLE, LL_TIM_OCSTATE_ENABLE, LL_TIM_OCSTATE_ENABLE, 111,
                                                            LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCIDLESTATE_LOW, LL_TIM_OCIDLESTATE_LOW });      // Falling edge


It's the CompareValue:

typedef struct
{
  uint32_t OCMode;        /*!< Specifies the output mode.
                               This parameter can be a value of @ref TIM_LL_EC_OCMODE.

                               This feature can be modified afterwards using unitary function @ref LL_TIM_OC_SetMode().*/

  uint32_t OCState;       /*!< Specifies the TIM Output Compare state.
                               This parameter can be a value of @ref TIM_LL_EC_OCSTATE.

                               This feature can be modified afterwards using unitary functions @ref LL_TIM_CC_EnableChannel() or @ref LL_TIM_CC_DisableChannel().*/

  uint32_t OCNState;      /*!< Specifies the TIM complementary Output Compare state.
                               This parameter can be a value of @ref TIM_LL_EC_OCSTATE.

                               This feature can be modified afterwards using unitary functions @ref LL_TIM_CC_EnableChannel() or @ref LL_TIM_CC_DisableChannel().*/

  uint32_t CompareValue;  /*!< Specifies the Compare value to be loaded into the Capture Compare Register.
                               This parameter can be a number between Min_Data=0x0000 and Max_Data=0xFFFF.

                               This feature can be modified afterwards using unitary function LL_TIM_OC_SetCompareCHx (x=1..6).*/

  uint32_t OCPolarity;    /*!< Specifies the output polarity.
                               This parameter can be a value of @ref TIM_LL_EC_OCPOLARITY.

                               This feature can be modified afterwards using unitary function @ref LL_TIM_OC_SetPolarity().*/

  uint32_t OCNPolarity;   /*!< Specifies the complementary output polarity.
                               This parameter can be a value of @ref TIM_LL_EC_OCPOLARITY.

                               This feature can be modified afterwards using unitary function @ref LL_TIM_OC_SetPolarity().*/


  uint32_t OCIdleState;   /*!< Specifies the TIM Output Compare pin state during Idle state.
                               This parameter can be a value of @ref TIM_LL_EC_OCIDLESTATE.

                               This feature can be modified afterwards using unitary function @ref LL_TIM_OC_SetIdleState().*/

  uint32_t OCNIdleState;  /*!< Specifies the TIM Output Compare pin state during Idle state.
                               This parameter can be a value of @ref TIM_LL_EC_OCIDLESTATE.

                               This feature can be modified afterwards using unitary function @ref LL_TIM_OC_SetIdleState().*/
} LL_TIM_OC_InitTypeDef;

What are you tring to do? Why the fixation of generating 9KHz for no reason?

100Hz is enough! Or a simple push button, it'll crash really easily.

[bingo600]

I'm talking about my need for generate pulses for the capture port on the  PY32 running your CCP program.
So i modified your CCP program a bit to do OCP instead of ICP, for the PY32 i use as pulse generator.

I'm not going to modify your CCP program on the DUT, just use it as base for a pulse generator for pulsing the DUT.

[DavidAlfa]

Just use a simple push button LOL, I will repeat again, no need for any KHz signal.
Connect a button, press it few times, it will crash after few presses if RDP is set.

[bingo600]

I'm not sure where i got the 9KHz from   
But as i'm also using this as a PY32/STM + pyOCD/DAP-Programmer learningproject, i wanted to try OCP as pulse source.

I'll modify the pulse source to 200Hz

[DavidAlfa]

This will easily generate the signal you're asking for in PA1:

Code: [Select]

#define PERIOD_US   10000      // 10ms PWM signal (100Hz). Will work with any value between 2 and 65535
int main(void)
{
  LL_RCC_HSI_Enable(); 
  LL_RCC_HSI_SetCalibFreq(LL_RCC_HSICALIBRATION_24MHz);
  while (LL_RCC_HSI_IsReady() != 1); 
  LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOA | LL_IOP_GRP1_PERIPH_GPIOB | LL_IOP_GRP1_PERIPH_GPIOF);
  LL_APB1_GRP2_EnableClock( LL_APB1_GRP2_PERIPH_TIM1);
  LL_GPIO_Init(GPIOA, &(LL_GPIO_InitTypeDef){ LL_GPIO_PIN_1, LL_GPIO_MODE_ALTERNATE, LL_GPIO_SPEED_FREQ_VERY_HIGH, LL_GPIO_OUTPUT_PUSHPULL, LL_GPIO_PULL_NO, LL_GPIO_AF13_TIM1 });
  LL_TIM_Init(TIM1, &(LL_TIM_InitTypeDef){ 23, LL_TIM_COUNTERDIRECTION_UP, PERIOD_US-1, LL_TIM_CLOCKDIVISION_DIV1, 0});                           // 1MHz input clock 
  LL_TIM_OC_Init(TIM1, LL_TIM_CHANNEL_CH4, &(LL_TIM_OC_InitTypeDef){  LL_TIM_OCMODE_PWM1, LL_TIM_OCSTATE_ENABLE, LL_TIM_OCSTATE_DISABLE, 0,
                                                                      LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCPOLARITY_HIGH, LL_TIM_OCIDLESTATE_LOW,  LL_TIM_OCIDLESTATE_LOW });
  LL_TIM_OC_SetCompareCH4(TIM1, PERIOD_US/2);
  LL_TIM_EnableCounter(TIM1);
  LL_TIM_EnableAllOutputs(TIM1);

  while (1)
  {
  }
}


[bingo600]

This will easily generate the signal you're asking for in PA1:

Thanx David

I just checkked w. a scope , and yep ... 100Hz 50% duty.
One question though ...
Why : LL_TIM_OCMODE_PWM1 , and not LL_TIM_OCMODE_TOGGLE ?

I'm now going to read your description of the CCP program again , and do the tests on the F002 (SOP-16) , and later on the F003.
Should i recompile for the F003 using your CCP sources , or just use your PA7 binary for both ??

/Bingo

[bingo600]

Testing my own compile of the CCP (No source touched , besides setting PA7 as button pin)

That didn't take long of the F002 SOP-16, w. the 100Hz pulses.

1: Turn on DUT w 100Hz pulses active
    LED is constantly green (pulses received)

2: GND PA7 to enable RDP , RED blinks
    Then LED is constantly orange (Red + Green) ... For a few seconds , and then turns Red.
    Maybe 2..3 sec.

I tried again after a POR , maybe 3..4 sec this time
And a 3'rd POR , this time it lasted 10+ seconds.

Had to remove the 100Hz pulses, in order to reliably GND PA7 for RDP unlock


Now testing with your build :  symlinked it to main.bin -> PY32F030_CCP_test_VECT_FLASH_PA7.bin    , to use the "make flash"
Behaves the same as above .....

Trying the VECT_SRAM now w 100Hz pulses
Looking good
After 7 minutes , the led is still "Orange" (Red + Green)

So the PY32F002AW15S6TU (SOP-16)  has the same "quirk" as the PY32F002AF15P6TU (SSOP-20)

Now on to the PY32F003F18P6TU (SSOP-20)

/Bingo

[bingo600]

Now testing w. the : PY32F003F18P6TU

Still building for a F030 , and the pyOCD (DAP) device is still : PYOCD_DEVICE   ?= py32f002ax5    ... Wonder if i should change that to a py32f003x8  - Does the 64K x8 use different flash pages ?

I'll have to use my own build of the CCP program , as the F003 is rather "skimpy" on PortB pins , and doesn't have PB0/PB1 for the leds.
I have chosen to use PA2 (Red) / PA3 (Green) , and still use PA1 for Capture & PA7 for "Button"
Just ran a simple "blinky" on the F003 w PA2/PA3 working as expected.

Hmmm ....
Loaded my CCP (Only led pins changed)  - I expect it to be VECT_FLASH per default , as i haven't uncommented

Code: [Select]

/************************* Miscellaneous Configuration ************************/
/*!< Uncomment the following line if you need to relocate your vector Table in
     Internal SRAM. */
//#define VECT_TAB_SRAM
#define VECT_TAB_OFFSET  0x00 /*!< Vector Table base offset field.
                                   This value must be a multiple of 0x100. */

1: Programmed & started w. 100Hz connected to PA1
    Led was constant green

2: Connected PA7 to GND
    RED blinking + the permanently RED

3: Did a POR of the F003 - 100Hz still connected
    LED Constaly "Orange" after 10+ minutes.

Seems like it's "Hardfaulting" when RDP is set , but after a POR it seems to run wo any issues.
Nope ... Now it doesn't react to PA7 , and LED still "Orange after" 100KHz signal is removed.

Had to connect PA7 to GND before POR , in order to get it to not "hardfault" immediately , now i could reset the RDP by toggling PA7

Will build SRAM version & test

SRAM vers build  (from linker map)

Code: [Select]


.ram_vector     0x0000000020000000       0xc0
 *(.ram_vector)
 .ram_vector    0x0000000020000000       0xc0 ./Build/Driver/CMSIS/Device/PY32F0xx/Source/system_py32f0xx.o


Seems like SRAM works ...


Modified hardfault , to turn green off

Code: [Select]

/**
  * @brief This function handles Hard fault interrupt.
  */
void HardFault_Handler(void)
{
  WritePin(GREEN,0);                                                                // Set led OFF
  while (1)
  {
    for(volatile uint32_t i=0;i<50000;i++);
    TogglePin(RED);
  }
}
And tried FLASH Vectors again ...
Took very short time before led was RED.


Trying SRAM again w RDP.
Seems to work fine , i'll let it run for 10+ minutes

After 17minutes , still going strong , and responding to PA7.

So the F003 has the same issue as the F002

And the workaround is the same ... To move Vectors to SRAM

/Bingo

[bingo600]

@David

Btw:
Did you see that SDK protection stuff in F002 RM , or F030 RM (pg. 37)
It mentions something about Read protection with RDP = 0

I'm not sure i understand it fully right now ...
But it seems like one can protect the memory in 2K pages

/Bingo

[DavidAlfa]

Just as I thought, thanks for testing!
Why pwm instead ocp? Because I already had some code made that way!
The final result would be almost the same, just toggling the output on each overflow instead at the middle.
But PWM adds more flexibility, allowing variable duty cycle.

I updated the fix at IOsetting's repo.
Should be a pretty solid patch now.

Yeah I read the SDK thing. It's disabled by default:

Code: [Select]

Production value: 0xFF0000FF

28:24     Complemented SDK_END[4:0]
20:16     Complemented SDK_STRT[4:0]

12:8      SDK_END[4:0]  SDK area end address, each corresponding STEP is 2 kbytes
4:0       SDK_STRT[4:0] SDK area start address, each corresponding STEP is 2 kbytes


For SDK area option, SDKR_STRT [4:0] = 0x00, SDKR_END [4:0] = 0x1F, all Flash memory is set as SDK

But the default values (0x00FF) will do: SDKR_END = 0x00, SDKR_STRT = 0x1F
Thus SDK protection is disabled:

When SDK _STRT[4:0] is greater than SDK_END[4:0], SDK protection is invalid

[bingo600]

I updated the fix at IOsetting's repo.
Should be a pretty solid patch now.

Thnx 
Even tough i liked the vectors in flash as default ... When not using RDP
Well i can just define the : FORBID_VECT_TAB_MIGRATION  - If no RDP is needed

Yeah I read the SDK thing. It's disabled by default:

I was "brainstorming internally" 
If it was possible to protect the code via SDK bits , and then not needing the RDP.
But i could easily have misunderstood something here ... It just seemed that Debugger reads would be disabled on a SDK protected page , even if RDP was 0

/Bingo

[DavidAlfa]

Even tough i liked the vectors in flash as default ... When not using RDP

Yeah but the code has no way of knowing if you're setting RDP or not.
So I think using SRAM vectors by default is better, otherwise anyone setting RDP may get a nasty surprise, squeezing his brain thinking it's a code problem.
... Until many hours later, he might find this issue  .
Uses 192 bytes, 6% of system RAM, not terrible, and remember you have +1KB for free so it would actually be 4.7%.
Setting flash vectors back is plain easy by adding that flag in the makefile or in system_py32f0xx.c.

I was "brainstorming internally" 

Something like this? Subtitles : "How does this SDK thing work?" in polite Danish .

[bingo600]

A bit more calm, than the YT guy ..
Sport coaches & Chef's apparently think they get "Better performance" if they yell ...

Btw: Just cloned your repos, to get the Vector stuff

/Bingo

[DavidAlfa]

It's merged now, so I'll be deleting mine!

[yjmwxwx]

Battery Internal Resistance Tester  PY32F002AF15P6TU

48MHZ，DMA，PLL

https://hackaday.io/project/192563-py32f002a-mcu-battery-internal-resistance-tester



common-positive digital tube (electronics)

[yjmwxwx]

I'm using JLINK OB.

Copy Devices to the JLINK installation directory and copy the contents of py32.xml to JLinkDevices.xml.

[true]

First, I currently have PY32F002A programming and debugging successfully with a CMSIS-DAP debugger in VSCode with PlatformIO. This is without any custom platform, and no framework - basically a bare metal project. It uses pyOCD but the dependency is managed by PlatformIO. It's pretty much just load and go. No hacks are needed.

The only problem I am having right now is the peripheral register window not working correctly while debugging. Basically, neither reading nor writing values works. I can use pyOCD to read peripheral registers manually and that works, but the peripheral pane just isn't working. Don't know if it's a new platformio bug or not - someone else has a similar issue with an STM32 part and the issue is very recent.

Second, PUYA released PY32F002B parts. They have slightly different specifications vs 002A, such as 24K flash. The chinese version of the website has a newer datasheet/code download than the english site with 002B code, but no datasheets or reference manual. The datasheet is available on LCSC but is Chinese-only. I would imagine these are actually less capable / smaller die parts. Who knows if the 002A parts will dry up?

[DavidAlfa]

Are you modifying these registers halting the core first, right ?

[bingo600]

Don't know if it's a new platformio bug or not

I'm out .....
I won't touch platformIO .. Even with a 10 feet pole.

I really don't like the concept

/Bingo

[DavidAlfa]

Neither I. Really, try CubeiDE + devices patch and Jlink.

[true]

Of course the core is stopped when checking peripherals in the peripheral pane. There is a specific error message, but I did not expect support for that here so did not post it. As I said, I can manually read peripheral registers just fine, or write to them using the debug console. It's just the peripheral pane that's busted. Again I am not asking for help here, just that I have that problem to solve before I release stuff for it. Once it's working I'll post a link to a bare minimum viable platformio PY32F project.

To continue on the pio tangent, I don't like how much platformio forces some things for platforms (just one example: can't specify a config for pyocd in nxplpc platform) and limits expansion of unsupported or parts without becoming a developer for them, making patches, or doing a bunch of hacky shit with fairly middling and incomplete documentation. But for most of the many supported platforms, it just works. What's wrong with the concept of "just open a project and everything is installed local to platformio as needed and just works, on windows or linux and possibly mac?" While I use many vendor IDEs, for some platforms they just don't exist (ahem... this one), are vendor packages for proprietary ones, or suck. I ported STM8L15x + fixed SDCC to PlatformIO and it's by far the best experience I have had programming and debugging for that platform. For supported target platforms, it basically just works, and gives you options (vs vendor IDEs where if you don't like what they provide, you'll usually have to hack shit). For unsupported ARM cores, it's pretty easy to hack in bare metal support with existing structures. To each their own. Not really sure what the point of your comment was, expressing your hate based on ignorance because you don't like the "concept;" this is just another option. If you don't that I got it to work, you can ignore it.

But try getting people hacking on firmware who don't have a bunch of experience. The less friction, the better. This is a goal of many of my devices. I'd rather just tell them for a PY32 device to "install vscode, install platformio extension, open project and build, and it works" and have that be only ~300MB total download at a convention than "try a bunch of hacky shit with some vendor IDE that is a 1GB download behind an account login." (ok, ideally it'd be even smaller download, but that's hard to do and have people still be comfortable while also making sure the codebase remains maintainable)

The other options here are a stolen (or real, but look at the post history) debugger and a version-specific hacked IDE. Which I have also used and it works well. Or a proprietary IDE using vendor packs.

Neither I. Really, try CubeiDE + devices patch and Jlink.

That doesn't solve my core problem. And besides, I already have used this (for HK32 anyway) and have spoken with you about it.

Back on topic:
Re PY32F specifically, I have two products, one using 002A-TSSOP20 and another 003-SOP16 that I'll be hacking on code for over the next few weeks. The peripheral set reminds me a lot of other Chinese domestic MCUs, and it was near effortless to get it going, so I imagine this will work just fine. I do like that the pinout for debugging makes way more sense than the HK32, lol.

[DavidAlfa]

Doesn't solve your core problem? I can write to any core/peripheral register just fine there...

[true]

Doesn't solve your core problem?

Correct. Peripheral pane not working right now is not my core problem. Something else is, which I also described. Getting a development environment working with this MCU that is both smaller and doesn't involve modifying a vendor IDE or modifying anything really solves my problem better. I can program and debug just fine this way, and for an end user / programmer getting the source, does not require any special instructions or modified software. I can work on the periph pane issue later. Was not asking for help for it. I only mentioned that that's the only thing that isn't working right now otherwise I'd post details and for some reason it got taken as a shit solution or something.

I can write to any core/peripheral register just fine there...

What is "there?" Using PY32 on pio+pyOCD? Or do you mean with STM32CubeIDE? I already know it works on the latter and implied as such. If you mean the former, please describe how / post your platformio.ini?

I really don't know how "everything works except peripheral pane not working" got taken as "everything you do is shit, your choice is shit, and it must be refuted." This isn't a competition. Why the hate? I don't understand it. I only described that I have this working another way. Instead of "cool" or not saying anything, there's just hate and pushback. Why hate over it? Can things only be done your way here?

[DavidAlfa]

 

[true]

Exactly. huh?

I'll talk elsewhere about my progress with this.

[DavidAlfa]

So did you went back to earth from whatever you took yesterday?

Competition? Hate?, "everything you do is shit"?
I simply said: I use THIS, and it works for me. That's all.

I'm NOT using Plattformio (Neither I like it, I find it messy, that's a personal preference), so I CAN'T help with that.

Now, where did anyone said you were a f** piece of sh** or X method was better?

[DavidAlfa]

It was a *** mess to set it up, but I got it working in Eclipse.

1 - Install Eclipse for C/C++ Embedded.

2 - Install python 3 from windows store.

3 - Install pyocd with pip3 install pyocd

4 - Download xPack gcc, extract it somewhere, ex. c:\xpack\xpack-arm-none-eabi-gcc-10.3.1-2.3.

5 - Download xPack build tools, extract t it somewhere, ex. c:\xpack\xpack-windows-build-tools-4.4.1-1.

6 - Eclipse->Window->Preferences->MCU->Global Arm Toolchains Paths->Default toolchain: xPack GNU Arm Embedded GCC
     Toolchain folder: C:\xpack\xpack-arm-none-eabi-gcc-10.3.1-2.3\bin.
     Global Build Tools Path: C:\xpack\xpack-windows-build-tools-4.4.1-1\bin.

7 - Eclipse->Help->Marketplace, install EmbSysRegView plugin, close the IDE.

8 - Place Puya.PY32F0xx_DFP.1.1.0.pack in C:\Users\user_name\AppData\Roaming\CMSIS-Packs.

9 - Temporary rename the file from .pack to .zip, extract the SVD files somewhere, then rename it to .pack again.

10 - Go to C:\Users\user_name\.p2\pool\plugins\org.eclipse.cdt.embsysregview.data_0.2.6.r191\data\SVD(CMSIS)
     Create the folder "Puya". Place the SVD files file inside it, change the extension to xml.

9 - Open Eclipse->Window->Preferences->C/C++->Debug->Embsys Register View-> Architecture:SVD, Vendor:Puya, Chip: py32f030xx (The svd name).

10 - Eclipse->New->C/C++ Project->C Managed build->Empty project, Arm Cross GCC->Should use the toolchain be set earlier->Finish

11 - Right click on project->C/C++ Build-> External Builder
     Behaviour-> Enable parallel build
     Settings->Target Processor-> cortexm0-plus.
     Settings->Optimization->Other optimization flags:
      -Wl,--cref -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
     (Apply this to both Debug and Release profiles). This saves a lot of space, it's what CubeIDE uses.

12 - Eclipse->Window->Preferences->MCU->Global pyOCD Path
     Executable: pyocd.exe
     Folder:
C:\Users\user_name\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.xxx\LocalCache\local-packages\Python3xx\Scripts
       
13 - Click on the Debug button->Debug configurations->Create New GDB PyOCD -> Debugger tab
       Click override target: py32f030x6
       Other options: --pack=C:\Users\user_name\AppData\Roaming\CMSIS-Packs\Puya.PY32F0xx_DFP.1.1.0.pack

Linker script is set in Project properties->C/C++ Build->Settings->GNU Arm Cross Linker->General
It's common to have a startup file in asm, Eclipse only takes assembler files with .S extension, must be uppercase!

Debugging and programmign works, but EmbSys won't show the register data by default, you must first enable each by double-clicking on the reg name, it'll become green, now you can write and read to it.

Attached a simple project.

[DavidAlfa]

And forget unlocking RDP with pyOCD either.
I've tried  with J-Link, ST-Link and DAP-LINK, they all do the same:

>pyocd erase -s 0x8000000 -t py32f002ax5 --pack="Puya.PY32F0xx_DFP.1.1.0.pack"
0000897 I Erasing sector 0x08000000 (4096 bytes) [eraser]
0010914 C flash erase sector timed out [__main__]

>pyocd erase -c -t py32f002ax5 --pack="Puya.PY32F0xx_DFP.1.1.0.pack"
0000747 I Erasing chip... [eraser]
(Stays forever)

>pyocd erase --mass -t py32f002ax5 --pack="Puya.PY32F0xx_DFP.1.1.0.pack"
0000749 I Mass erasing device... [eraser]
(Stays forever)

[man_anyone]

I really don't know how "everything works except peripheral pane not working" got taken as "everything you do is shit, your choice is shit, and it must be refuted." This isn't a competition. Why the hate? I don't understand it. I only described that I have this working another way. Instead of "cool" or not saying anything, there's just hate and pushback. Why hate over it? Can things only be done your way here?

I appreciate what you're doing, I really do
I've never wanted to use the vendor IDEs and you can see that I've asked David Alfa about the possibility of adding support for this MCU to PlatformIO in a previous post, so I'm really glad that you're adding support for it
But you need to calm down man, like really
They just said they don't know how to help, they didn't say that PlatformIO is objectively bad or anything, they were just expressing their opinion

I'll talk elsewhere about my progress with this.

I'm really interested, so I would be glad if you told me where you're going

Also thanks David for going out of your comfort zone to help us here

[DavidAlfa]

And the puya programmer s Win-only, i'm linux only.

Edited the first post.
There's a new tool, MCU-Flash-Tools, python-based, which can program PY32 using the embedded bootloader, just like Puya ISP, so you can now use it under linux.

[Bikkel]

Do you think it is possible to jump from your user code to this bootloader and start using the onboard bootloader without going through the sequence were you have to power up with the boot pin pulled high ?

[DavidAlfa]

Should be posssible. Based on gbm's answer here:
https://community.st.com/t5/stm32-mcus/how-to-jump-to-system-bootloader-from-application-code-on-stm32/ta-p/49424

I got it working with this code:

Code: [Select]

void JumpToBootloader(void)
{
  typedef struct {
      uint32_t Initial_SP;
      void (*Reset_Handler)(void);
  }boot_vectable_t;

  boot_vectable_t * BOOTVTAB =  (boot_vectable_t *) 0x1FFF0000;             // PY32 system bootloader base address;

  __disable_irq();                                                          // Disable all interrupts

  if(LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_HSISYS)        // If not using HSI clock source, set default HSI 8M clock.
  {
    LL_RCC_HSI_Enable();
    while(LL_RCC_HSI_IsReady() != 1);
    LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_HSISYS);
    while(LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_HSISYS);
    LL_RCC_SetAHBPrescaler(LL_RCC_SYSCLK_DIV_1);
    LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_1);
    LL_RCC_PLL_Disable();                                                   // Disable PLL
  }

  RCC->AHBENR   = 0x300;                                                    // Disable all peripherals except FLASH and SRAM
  RCC->APBENR1  = 0;
  RCC->APBENR2  = 0;

  RCC->IOPRSTR  = 0xFFFFFFFF;                                               // Reset all ports
  RCC->AHBRSTR  = 0xFFFFFFFF;                                               // Reset all peripherals
  RCC->APBRSTR1 = 0xFFFFFFFF;
  RCC->APBRSTR2 = 0xFFFFFFFF;
  RCC->IOPRSTR  = 0;                                                        // Release resets
  RCC->AHBRSTR  = 0;
  RCC->APBRSTR1 = 0;
  RCC->APBRSTR2 = 0;

  SysTick->CTRL = 0;                                                        // Disable Systick timer

  NVIC->ICER[0]=0xFFFFFFFF;                                                 // Clear Interrupt Enable & Interrupt Pending Registers
  NVIC->ICPR[0]=0xFFFFFFFF;

  __enable_irq();                                                           // Re-enable all interrupts

  __set_MSP(BOOTVTAB->Initial_SP);                                          // Set the MSP
  BOOTVTAB->Reset_Handler();                                                // Jump to bootloader
}


It probably can be optimized by removing unnecessary code, but it's a small function anyways (Uses 168 Bytes of flash).
All the LL calls are basically reg read/write/modify macros or very small inline functions.


Puya ISP finds the mcu in the instant I push the button:

Code: [Select]

int main(void)
{
  system_init();
  while (1)
  {
    led_blink();
    if(!ReadPin(BUTTON))
      JumpToBootloader();
  }
}


Code: [Select]

Send 0x7F...
Receive 0x79
Send 0x7F...
Receive 0x1F
Version:1.0
PID：0x0440
Read UID 128Bytes at 0x1FFF0E00.
00: 31 34 50 41 03 32 36 38 2A 64 E7 00 78 93 05 56
10: FF FF 30 01 BA 78 BA 65 FF FF FF 9A FF FF FF 0A
20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40: E8 10 00 00 E8 30 00 00 0A 51 00 00 E9 72 00 00
50: E2 92 00 00 B7 03 00 00 69 04 00 00 FF FF FF FF
60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FLASH：32 KB, SRAM：4 KB
OPTR: 0xB0AA SDKR: 0x001F WRPR: 0xFFFF


[true]

I'm really interested, so I would be glad if you told me where you're going

What I wrote is that I got it working. A progress report. For some reason "this one thing isn't working" is the only thing that was understood, and perhaps taken both as begging for help and an opportunity to hate on an IDE / platform. I never asked for help nor did I want help. The response was just "your choice sucks" and "use what was made before, it works." Has nothing to do with the progress report.

Really I was more interested in discussing the PY32F002B and if anyone did anything with it yet...

Since you're interested, if you don't mind waiting, I'll post the platformio conf file once I get done with a convention early November. This way I can make sure the config is repeatable and not specific to my setup. Shouldn't require doing any hacky stuff - just make a new project, use the config and PUYA .pack file. If you want it sooner let me know.

[IOsetting]

I just noticed that Puya has created their account on Gitee
https://gitee.com/puya-semiconductor
and released quite a lot tools and software
https://gitee.com/puya-semiconductor/tools-and-software

A good sign that they are making their software things public and officially supporting GCC

[DavidAlfa]

Including notes for the bootloader protocol 

[DavidAlfa]

Long story short, I noticed setting RDP1 disables nRST!
My fault, I was clearly disabling it in the config bits when setting RDP!
Had two weeks, 11h/day thanks to stupid sales/management people, was time for a planned order and they didn't had bought the parts yet, so then it was again our mission to save their as$es.
I had already given it all and struggled with this simple task  .

[Pixie dust]

I checked out the ADC onboard the PY32F003. The converter is quite accurate (jitter of 1 count only). However there is one flaw: If a pin is configured in input mode (not analog) and the voltage of such pin goes beyond the rails (either on the ground side or VDD side) the ADC results of other (analog) pins are messed up. And this while the VDD stays perfectly constant. So the ADC does not strictly convert in the range 0...VDD.

In designs were the onboard protection diodes are used to clamp an input  pin this can be a problem.

[DavidAlfa]

Yeah this is a pretty common issue in plenty of mcus.
Relying on the pin clamping diodes is always a bad idea when using analog peripherals and must be thoroughly tested.
Of course the adc works in the 0...VDD range, the problem comes from the clamping diodes, clamping to VDD+0.6V, those extra 0.6V are causing the behaviour.

If the current consumption is low, even 10K could cause VDD to rise slightly.
You can also play with the pulldown resistors, so they make a voltage divider.
I recall they were about 40-50K, so if interfacing 5V, a 22-33K input resistor will do it.

[IOsetting]

A newly reported bug:
When IWDG is enabled, if RTC or LPTIM interrupt is triggered(to feed the dog) at the same time when MCU is entering stop mode, there is a possibility that the dog feeding fails and then MCU will reset.
(Source: https://www.cnblogs.com/liwen01/p/17850148.html)

In PY32F002B, using option byte IWDG_STOP may avoid this bug. when IWDG_STOP is set, watchdog stops counting in stop mode.

[antst]

I'm really interested, so I would be glad if you told me where you're going

What I wrote is that I got it working. A progress report. For some reason "this one thing isn't working" is the only thing that was understood, and perhaps taken both as begging for help and an opportunity to hate on an IDE / platform. I never asked for help nor did I want help. The response was just "your choice sucks" and "use what was made before, it works." Has nothing to do with the progress report.

Really I was more interested in discussing the PY32F002B and if anyone did anything with it yet...

Since you're interested, if you don't mind waiting, I'll post the platformio conf file once I get done with a convention early November. This way I can make sure the config is repeatable and not specific to my setup. Shouldn't require doing any hacky stuff - just make a new project, use the config and PUYA .pack file. If you want it sooner let me know.

Kindly reminding!
I just got dev boards and going to start hacking around it. Would be nice to avoid some work with setting up platformi

[bingo600]

Seems line Puya has gotten their "Device packs" in the "Official" DAP repos.

Install with:

pyocd pack update      - It will "barf a bit" but complete

pyocd pack install PY32

pyocd pack find PY32

Code: [Select]


  Part          Vendor   Pack                Version   Installed 
------------------------------------------------------------------
  PY32F002Ax5   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F002Bx5   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F003x4    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F003x6    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F003x7    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F003x8    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F030x4    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F030x6    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F030x7    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F030x8    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F031x4    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F031x6    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F031x7    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F031x8    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040Cx6   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040Cx8   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040Cx9   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040CxB   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040x6    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040x8    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040x9    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F040xB    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071Cx6   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071Cx8   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071Cx9   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071CxB   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071x6    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071x8    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071x9    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F071xB    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072Cx6   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072Cx8   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072Cx9   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072CxB   Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072x6    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072x8    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072x9    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F072xB    Puya     Puya.PY32F0xx_DFP   1.2.0     True       
  PY32F303x8    Puya     Puya.PY32F3xx_DFP   1.0.0     True       
  PY32F303xB    Puya     Puya.PY32F3xx_DFP   1.0.0     True       
  PY32F303xC    Puya     Puya.PY32F3xx_DFP   1.0.0     True       
  PY32F403xB    Puya     Puya.PY32F4xx_DFP   1.0.0     True       
  PY32F403xC    Puya     Puya.PY32F4xx_DFP   1.0.0     True       
  PY32F403xD    Puya     Puya.PY32F4xx_DFP   1.0.0     True       
  PY32L020x5    Puya     Puya.PY32L0xx_DFP   1.0.0     True       
  PY32M010x5    Puya     Puya.PY32Mxxx_DFP   1.0.0     True       
  PY32M030x8    Puya     Puya.PY32Mxxx_DFP   1.0.0     True       
  PY32M070xB    Puya     Puya.PY32Mxxx_DFP   1.0.0     True       


1.2.0 Pack is here
https://www.puyasemi.com/uploadfiles/Puya.PY32F0xx_DFP.1.2.0.pack

/Bingo

[bingo600]

It was a *** mess to set it up, but I got it working in Eclipse.

@David

I decided to "Fine tune" my PY32 ... And install an IDE to do debugging.

I tried the Cube IDE w. Jlink - I have a Chinese Jlink-OB.
Works a few times (Run to breakpoint) ... But after setting a breakpoint, and "resuming" a few times GDB/Segger/IDE crashes , saying it has run out of breakpoints.
I don't think my OB has Flash BP's licensed.
But i only have the BP at main , and the "other BP" active ...


I then installed Eclipse Embedded (w. Embsys) , and is using my AirF103 DAP-Link probe.
I'm having quite some debug issues here ...
PyOCD is  flashing "fine" (text show in red) ... Well it says flashing 3200 bytes , and the bin fills 3417 bytes 

The breakpoints seem to work , but the MCU isn't blinking the led ....
Crazy enough BP's work, and show the "loop" variable.

If i "just" press "Run" - the led isn't blinking too.

If i move the project to "makefile" , and still use dap-link to program
The led is blinking 

I'm in "deep do..do" here ...

Any hints would be much appreciated.

PC is x64 Mint 21.02

Attached Eclipse Project.

/Bingo

[DavidAlfa]

My experience with pyOCD wasn't pretty good... it was a PITA to set up the CMSIS packs, Eclipse and all that, but I remember it working.
After making the Eclipse guide few posts back (Did it for a 100% legal alternative), I never used it again.
I'm running STLINK converted into JLink-OB with no problem else than the daily annoying warning.

You can only set 2 or 3 breakpoints, if you add more you'll have to delete or disable others.
Plus ensure to remove "Halt at main" in the debug launch options, as it will use another breakpoint.
I have no problem whatsoever with breakpoints, just remember they're finite!


BTW, these puyas have started to get more expensive, 2-4 cents more in small quantities!

[bingo600]

I got Eclipse to compile & flash

I seem to have an issue with the clock init

Code: [Select]

#if 0
  BSP_RCC_HSI_PLL48MConfig();
  SysTick_Config(480000);
#else
  LL_RCC_HSI_SetCalibFreq(LL_RCC_HSICALIBRATION_24MHz);
  while (LL_RCC_HSI_IsReady() != 1);
  SysTick_Config(24000);      // 24MHz cpu clock, 1ms period.
#endif

If i set it at 48M ,  it runs super slow
If i use the 24M , it runs as expected ...

Hmmm .....

Isn't there a zero to much in that 48M systick ?

[DavidAlfa]

Yep, 480.000 will make a 10ms tick period (100Hz), 10 times slower.
Change to 48.000, fixed!

[bingo600]

I'm running STLINK converted into JLink-OB with no problem else than the daily annoying warning.

Interesting ....
Is it "just" connect a China "USB-Stick" lookalike ST-Link , and then "convert" it ...
And it isn't locked to "Just ST MCU's" ?

Any hints ... ?

Ohh ... I suppose t has to be a F103 ST-link or ??
Some of the clones uses a F101 i think ...

You can only set 2 or 3 breakpoints, if you add more you'll have to delete or disable others.
Plus ensure to remove "Halt at main" in the debug launch options, as it will use another breakpoint.
I have no problem whatsoever with breakpoints, just remember they're finite!

That's the strange thing ...
I have "The main breakpoint"  , and ONE other breakpoint.
I just press ""Run" , and it breaks at the LED togle
I press Run gain ... It works
After 4..6 "Run's"  it crashes with "No more breakponts"
But i never set any more ....

I'll try to remove the break at main

BTW, these puyas have started to get more expensive, 2-4 cents more in small quantities!

That's quite a lot , when you think about they were 11cent

It got 100 of each ... F003 & F002a15 in 20-ssop , and F002a15 in 16tsop


I just got Eclipse debug to behave .....
I had to give it a SVD file , in order to see the periph. registers

[DavidAlfa]

Is it "just" connect a China "USB-Stick" lookalike ST-Link , and then "convert" it ...

It's a stlink v2 clone, but the full one (White plastic housing), then reflashed to OB.

And it isn't locked to "Just ST MCU's" ?

"Yes", but read 1st post.

Ohh ... I suppose t has to be a F103 ST-link or ?? Some of the clones uses a F101 i think ...

AFAIK it only needs to be a CB (128K) part, but genuine stm32, not apm32, etc.

But i never set any more ....

Edit: I can set up to 4 breakpoints just fine!
More than that and I get the window asking to buy a license for unlimited flash breakpoints.

If you have a spare stm32f103 BluePill send me a PM, I have a binary you can try out.

[bingo600]

Only 2 breakpoints then!
Keep in mind that step-out action needs a free breakpoint. Single step, run, halt...don't.

I suppose that's what bites me ....

Yeah the best is to remove startup breakpoint. Put it at main if you want, but that way you can disable it later on.
Keep an eye at the breakpoints window!

Edit: I can set up to 4 breakpoints just fine!
More than that and I get the window asking to buy a license for unlimited flash breakpoints.

Neat  ....
I suppose the "Unlimited flash BP" is the "Dongle" reprogramming the flash , and inserts BP's there

I haven't tried more than 2 BP's (Main + an extra)
But i suppose i don't need the BP at main ...

If that frees up a BP . that i can use for a "Line", and then have the other for stepping. That would be fine for me.

But right now Eclipse + pyocd seems to behave quite ok ...

/Bingo

Ps: Thanx for the assistance 
Pps: Did you see the picts i inserted above ...

[DavidAlfa]

I see you anwered to my previous message before editing, please re-read.
Yeah I saw your picture...

I had to give it a SVD file , in order to see the periph. registers

Did you follow all the steps here?
Though I used an external pack file, as it wasn't included in pyOCD back then.

Maybe the breakpoint issue is a DAP or PyOCD thing? I'm not using that...
Try Jlink just in case?

[bingo600]

I see you anwered to my previous message before editing, please re-read.
Yeah I saw your picture...

I had to give it a SVD file , in order to see the periph. registers

Did you follow all the steps here?
Though I used an external pack file, as it wasn't included in pyOCD back then.

Maybe the breakpoint issue is a DAP or PyOCD thing? I'm not using that...
Try Jlink just in case?

I did follow your "Guide quite a lot" ... It helped great.
But remember i'm on linux, there could be differences ....

The BP issue i have was with CubeIDE + JlinkOB

So far ...
It seems like Eclipse + pyOCD + DAP-debugger runs quite nice ....


Btw: I tried to upgrade 1.13 CubeIDE "online" to 1.14 ... It broke .... PROB DON'T do that ...

I ended up deleting 1.13 , and reinstall
And DL + Install 1.14 instead of upgrade They can coexist , in different dir's ...   (Had to do the Java mod etc ... Again) , but you described it nicely 

I'm glad i got my 2TB NVME


Edit:
I think i just "killed" a PY002 tsop-16 ...
During my "fight" with Eclipse , i loaded the "RDP test program" you made.
And the CLI-DAP flasher - Gave an error and Couldn't verify ...
But the program isn't running either (no led blink) , so i can't disable RDP.

Maybe it's time to try that "linux" puya-programmer ....
Is it via seria interface l, that you "remove the RDP" on windows ??

Well it was 11cent ... The tsop to DIP adapter was more expensive   

/Bingo

[DavidAlfa]

The BP issue i have was with CubeIDE + JlinkOB

I never tested this. Only Jlink in CubeIDE.

Btw: I tried to upgrade 1.13 CubeIDE "online" to 1.14 ... It broke .... PROB DON'T do that ...

CubeIDE always broke for me when updating. I just delete everything and install from zero.

Keep in mind you'll have to manually patch that new IDE version (Just follow the included instructions).
Pasting the zip contents will likely break something, as the included plugins will be newer.
I kept 1.2.1 because of the stupid login thing. It's not just annoying, also screwed up my STM32 soldering FW automated building script.
So feeeck it

[bingo600]

Seems like my PY32F002AW15S (TSOP-16) is "gone" 
Somehow it went bannanas during programming of Davids RDP-Test program.
Now there's no led blink or .....

Well i looked at the new PuyaISP python program, to unprotect the device.
In order to activate the serial bootloader you need to pull Boot0 "high" ....
Well    on a TSOP-16 there's no PF4/Boot0 pin 

Wonder how they will utilize serial bootloader on that one wo. a Boot0 pin ?

Big loss 11c 
The TSOP to DIP adapter was more ...

Lesson learned ... Use a TSSOP-20 for playing around with RDP.

But then again ... A bit strange the < 20 pin , doesn't seem to be able to use the serial boot loader

/Bingo

[DavidAlfa]

But my test allowed RDP to be erased in software by pressing a button ?

Bingo600, as you asked in PM, here's a very simple example showing how to lock and unlock RDP.
PB0 = button to GND.
PB1 = RED led ( To indicate lock)
PB3 = GREEN led (Activity and unlocked indicator)

LEDS are active low - Connect between VCC and the mcu pin through a 470R-1K resistor.


Simply flash it - RED will be steady on, GREEN blinking as "I'm alive".
Press button - GREEN will be steady on, RED off. MCU will be wiped, cycle power to update RDP security, Jlink will be able to program it again.

Just in case, I'm only setting RDP1 in this test, not disabling nRST or BOOT0, at $0.11 it's cheap but better to not brick any! (I'm using the "full" mode myself, works perfect).

Wonder how they will utilize serial bootloader on that one wo. a Boot0 pin ?

I don't think you can.
BTW why the SO-16 package? The TSSOP20 is cheaper, has more pins while being ~30% smaller, and it's not hard to solder either!
In fact, it's the only package with BOOT0...

[bingo600]

But my test allowed RDP to be erased in software by pressing a button ?

Bingo600, as you asked in PM, here's a very simple example showing how to lock and unlock RDP.
PB0 = button to GND.
PB1 = RED led ( To indicate lock)
PB3 = GREEN led (Activity and unlocked indicator)

LEDS are active low - Connect between VCC and the mcu pin through a 470R-1K resistor.


Simply flash it - RED will be steady on, GREEN blinking as "I'm alive".
Press button - GREEN will be steady on, RED off. MCU will be wiped, cycle power to update RDP security, Jlink will be able to program it again.

Just in case, I'm only setting RDP1 in this test, not disabling nRST or BOOT0, at $0.11 it's cheap but better to not brick any! (I'm using the "full" mode myself, works perfect).

Wonder how they will utilize serial bootloader on that one wo. a Boot0 pin ?

I don't think you can.
BTW why the SO-16 package? The TSSOP20 is cheaper, has more pins while being ~30% smaller, and it's not hard to solder either!
In fact, it's the only package with BOOT0...

Well i have both ....
But also wanted one that was easy solderable, for a friend ....

From now on , i'll use the TSSOP-20 for playing around.

/Bingo

[DavidAlfa]

Still, why can't it be erased by the button? Did you modify it?
Anyways, I can't think on a worse example to play with, make a mistake and it'll be gone!
Just play with a led like the rest of the world

[bingo600]

Still, why can't it be erased by the button? Did you modify it?

Yupp - The SO16 needed other pins

Anyways, I can't think on a worse example to play with, make a mistake and it'll be gone!
Just play with a led like the rest of the world

 


But     - I misred the "Pin1 - dot" on the package , when jumpering the "Button pin"  & leds
Magic ... Leds blinking - Program running & It's revived from the dead   

I'mo now  11c richer ... And think i'll just play w leds   

/Bingo

[DavidAlfa]

You can now tell the wife you'll have food for Christmas!

[eliocor]

because the PY32F002A micro is the same as a PY32F030, except for the pinout, I have prepared a small document (extracted from the datasheets) which can be of some help when you are planning to use the 002A using all the "enhancements" of the 030.
I hope it can be of some use...

[Pixie dust]

During a test on a PY32F003 current was fed via the onboard protection diodes into the bulk capacitors placed on the output of a 5V regulator powering a py32F003. As more current was pushed in than drawn by the processor the voltage started to rise to about 8V. I thought this was the end of that microcontroller but to my surprise nothing broke and the processor still runs fine. I thought this is quite remarkable and makes me think that these PYFxxx controllers have quite robust IO pins. 

[pappkopp]

For the 8 pin (SOP8) PY32F002AL15S6TU, how would i flash this device? using J-link, USART RX/TX and PA14 ?
This model does not have a boot0 mode, only reset/nrst button?

[DavidAlfa]

Jlink, dap...

[pappkopp]

I'm trying to connect to the 8 pin (SOP8) PY32F002AL15S6TU via PuyaISP, but i cant really get it working, how should i enter the bootloader? I have tried pulling pin 6 (PA2/PF2-NRST) both high and low while power-cycling the MCU, but PuyaISP wont connect,

Is pulling NRST high the correct method to enter the bootloader? This package does not have a dedicated BOOT0 pin,

I have the option to try J-Link, does Puya have some tool to upload or read the mcu info via this? I have tried PuyaProgrammer but it can't find the USB device to use for SWD, For the J-link i'm using a nucleo board i have converted to J-link, but i belive Puya has its own programmer but it should be compatible ?

[DavidAlfa]

You already asked ths and were answered:

Jlink, dap...

No bootloader possible without Boot0, you need a programmer or buy a different package which has Boot0.
Read the thread, that matter has already been talked.

[IOsetting]

I have the option to try J-Link, does Puya have some tool to upload or read the mcu info via this? I have tried PuyaProgrammer but it can't find the USB device to use for SWD, For the J-link i'm using a nucleo board i have converted to J-link, but i belive Puya has its own programmer but it should be compatible ?

J-Link has its own software, which can be downloaded from https://www.segger.com/downloads/jlink/

[John Celo]

I'm reading this thread and trying to piece together on how to programm the SOP8/SOP16 versions of the PY32F002 (those don't have the boot0 pin available)

I don't have any dedicated programming device at the moment, and up to this point I have only programmed dev-boards that can be flashed via USB port (like arduino nano with it's onboard CH340 usb-to-serial chip and similar)

Which programming device should I get to program SOP8/SOP16 versions of those chips?
I've seen JLink mentioned, and on the first glance those cost 1000 euro or more.

For example, STM32 chips seem to have cheap ST-Link V2 programmers available on ali and else where.
Similarly, WCH CH32V003 chips have cheap WCH-LinkE on ali.

Are there any affordable beginner options to program SOP8/SOP16 versions of these chips?

[prosper]

you might already have parts on hand to build a daplink.

see https://github.com/IOsetting/py32f0-template/issues/6 for a discussion on probes. most DAP probes work, if only at 3.3V

[bingo600]

Are there any affordable beginner options to program SOP8/SOP16 versions of these chips?

A Jlink-OB or a Dap-Link from Ali will do ....
They're like $5 .. $8

1:
I've used this daplink
https://www.aliexpress.com/item/1005005303809188.html

2:
And this Jlink-OB
https://www.aliexpress.com/item/1005003620592002.html

3:
And this diy daplink
https://www.aliexpress.com/item/1005004635091721.html
https://www.eevblog.com/forum/microcontrollers/$0-11-py32f002a-m0-24mhz-320kb-actually-324kb-more-peripherals/msg5029996/#msg5029996

I'd prob get : One of #1 , and one of #2

[prosper]

this also works (same AIR32 as previous poster, just a smaller form factor):

https://www.aliexpress.com/item/1005005966658428.html

[DavidAlfa]

Puya has modded OpenOCD adding support por their chips:

https://gitee.com/puya-semiconductor/tools-and-software/blob/master/PY32_GCC/openocd-0.12.0.zip

Example cfg file for this DAP:

Code: [Select]

source [find interface/cmsis-dap.cfg]
source [find target/py32f030.cfg]
cmsis_dap_backend hid
transport select "swd"
set CLOCK_FREQ 1000
reset_config none
set CONNECT_UNDER_RESET 0
set CORE_RESET 0
Unfortunately CubeIDE complains about non genuine device. Haven't looked over it.

[prosper]

I saw that. Unfortunately, it's windows-only and doesn't provide the source, so it's not useful for me.


probe-rs does support the py32, though, so that's my go-to OCD

[John Celo]

Thank you for advice!

Sop8 version has following pins:
1. VCC
2. PA4/PA10
3. PA3
4. PA14-SWC/PB3
5. PA13-SWD
6. PA2/PF2-NRST
7. PA1
8. GND

The pins that have to be connected when programming are (5) SWC (6) SWD and (1) VCC (2) GND, correct?

Can SWC/SWD pins be shared and reused for different purposes?

And if the pins can be reused/shared, how does the device know that is being flashed instead of being used as in normal operation?

Is there some sort of special startup sequence?

[prosper]

I generally reserve SWC and SWD for debugging only, and don't re-assign them. It's easy enough to use a TSSOP-20 or something with more pins if IO is that tight.


If you do want to re-assign them, it'd be wise to implement a boot delay in your code before doing so, so that you have a moment when you can flash it on bootup before the SWD interface becomes unavailable to you. Otherwise, you'd essentially get a one-time-programmable device (which is not necessarily a problem if you're a manufacturer, but is less than ideal for a hobbyist)


Also be aware that in some cases, the 'multiplexing' is just the way the die is bonded - i.e. they just short together the points to the same pin. So you might have trouble if you try to drive PA14 high and PB3 low at the same time. Not sure if this is the case with the py32 or not, you'd need to carefully examine the datasheet (or experiment) and make your own inferences.

[DavidAlfa]

If you reasign swd pins, then you must also connect nRST to enter programming mode, otherwise it'll be impossible.

[DavidAlfa]

I was able to run puya OpenOCD under CubeIDE.

- Replace bin/dlls in plugins\com.st.stm32cube.ide.mcu.externaltools.openocd.win32_xxx\tools\bin.
- Add script files to plugins\com.st.stm32cube.ide.mcu.debug.openocd_xxx\resources\openocd\st_scripts

But the IDE had other genuine checks I missed out in the previous patch, so it didn't work.

I analyzed com.st.stm32cube.ide.mcu.debug.launch_xxx.jar and found a better aproach to entirely bypasss the checks.
Now it works great either with Jlink or openocd+stlink.

Updated the 1.12.1 patch, also added the patching guide so anyone can do it for any IDE version.

[John Celo]

It's all very confusing, for example PY32F002BW15S sop16 B version of the chip doesn't even seem to have NRST pin. (or is it a bug in the datasheet?)
How does writing to the flash memory of the device gets started/initiated when connected just to VCC/GND/SWC/SWD pins?

From what I could understand from reading the reference manual is:
1. Once powered on device resets pin functions to their default state
2. Since the SOP14/16 devices don't have a BOOT0 pin, CPU fetches top-of-stack value from 0x0000 00000
and starts executing code from 0x0000 0004 from the main flash memory (20kbytes)
3. Now in code, functions of GPIO pins will be set via Alternate Function Registers called GPIOx_AFRH and GPIOx_AFRL and accessed via peripheral registers (those are memory mapped in linear address space (32bit, 4gb))

For PF2-NRST pin specifically, their function is set through so called "Option bytes"
Option bytes (128bytes, one page of flash memory) are stored in flash memory.

Is that correct?

[IOsetting]

It's all very confusing, for example PY32F002BW15S sop16 B version of the chip doesn't even seem to have NRST pin. (or is it a bug in the datasheet?)

PIN13 is NRST, multiplexed with PC0, PA7
EN datasheet v0.3 is not the latest, please refer to the pin map in CN datasheet v0.9, page 17

How does writing to the flash memory of the device gets started/initiated when connected just to VCC/GND/SWC/SWD pins?

SWD transfer doesn't need a reset

[trimarco232]

Hi , there is something maybe new at aliexpress : TW32F003  https://fr.aliexpress.com/item/1005006207267714.html
it is showed as a CH32V003 equivalent , but it is ARM , so rather a new PY32 ?
some thoughts ?

[bingo600]

Hi , there is something maybe new at aliexpress : TW32F003  https://fr.aliexpress.com/item/1005006207267714.html
it is showed as a CH32V003 equivalent , but it is ARM , so rather a new PY32 ?
some thoughts ?

Don't ....

I think i have 3 of these , but : Absolutely no DOC is to be found ....

/Bingo

[prosper]

looks like it's a 'tianwen51' product, possibly the same as the mm32f003? https://www.micros.com.pl/mediaserver/UIMM32f003tw_0001.pdf

Some stuff comes up on a web search, like http://www.haohaodada.com/new/Arduino_example.php?href=TW32F003


...can probably say that it's *not* a py32, at least. I'd avoid it until/unless a datasheet and code examples from the vendor (as well as toolchain support) is provided

[DavidAlfa]

16K Flash, 2K SRAM, definitely not PY, just cheap low spec chinese CM0+ MCU not worth any mentioning.

[trimarco232]

they say 64 and 8kb
but agree with you , as 32 and 4kb are enough

[DavidAlfa]

I don't think it has 64K by any means, other twen32 listings show 16/2K
I guess it's a very opportune "mistake".

[IOsetting]

Hi , there is something maybe new at aliexpress : TW32F003  https://fr.aliexpress.com/item/1005006207267714.html
it is showed as a CH32V003 equivalent , but it is ARM , so rather a new PY32 ?
some thoughts ?

I'm not sure if it's a PY32 OEM or not, as I can't find its datasheet anywhere.
The company seems to be a training agency, so this chip is definitely rebranded from some other known chips. If you have the board with you, you can try to program it using PyISP or JLink, if this works, then it might be a PY32.

[trimarco232]

pinout of the board is the same as PY32
I have ordered few , we will see (I also hope arduino for PY32 will work)

[bingo600]

pinout of the board is the same as PY32
I have ordered few , we will see (I also hope arduino for PY32 will work)

I can't remember 100% , but i have a feeling that there's an issue with the way the board led is connected , if when programming that twen
Be aware if you have issues.

[IOsetting]

Well, I managed to get the datasheet from their Taobao customer service. It looks quite similar to PY32F030.

[DavidAlfa]

That one does indeed look the same as the py32f002, 20/3K...
Anyways, were's the deal? Probably won't be any cheaper than puya?

Try reading the DBG_MCU ID register.

Ask the seller for the reference manual, not just the datasheet, which is pretty useless alone.

[trimarco232]

I was looking for a PY32 on a smart little board , and didn't find something similar from Puya ...

[DavidAlfa]

https://www.aliexpress.com/item/1005005698577482.html

You can replace it with the cheaper PY32F002B, which has a compatible pinout (The PY32F002A is not compatible).

[Sacodepatatas]

...
Puya support pack 1: Docs, libs, ISP software...
Puya support pack 2: Similar contents but newer, has english datasheets & RM...

These two links are broken 😔.

[DavidAlfa]

Yeah, Puya changed the website, it's much better now.
Everything is in the product page:

https://www.puyasemi.com/mcu_weichuliqi.html

[John Celo]

Are there any affordable beginner options to program SOP8/SOP16 versions of these chips?

2:
And this Jlink-OB
https://www.aliexpress.com/item/1005003620592002.html

So this JLink-OB thing has arrived in the mail.

It shows missing drivers in the device manager.
Where do I get drivers for it?
How do I use it? Any documentation or anything?

The baidu link doesn't work (the one I received has FMD mcu on it).

[bingo600]

Are there any affordable beginner options to program SOP8/SOP16 versions of these chips?

2:
And this Jlink-OB
https://www.aliexpress.com/item/1005003620592002.html

So this JLink-OB thing has arrived in the mail.

It shows missing drivers in the device manager.
Where do I get drivers for it?
How do I use it? Any documentation or anything?

The baidu link doesn't work (the one I received has FMD mcu on it).

I suppose you're talking Windows here
I'm on linux , so not much experience with win.

I would expect you can find something on segger.com (Jlink manuf)

[John Celo]

Got blink sketch to work, used WeActStudio DAP-Link. (for a py32 chip without a boot pin)

Used Keil uVision v5 IDE (it has support packages for various devices, including py32). Keil is german subsidy of ARM that makes software tools, including IDEs. For some reason couldn't get it to flash from uVision though.

So used pyOCD to flash the .hex file instead. pyOCD is python API and command line tools for flashing/erasing/debugging ARM Cortex microcontrollers.
Ideally would like to flash/debug right from the uVision, but will figure that out another day...

For beginner this stuff's pretty tough, so much ambigious, confusing terminology where most sources never bother to explain any of it... plus, you aren't even sure initially if dap-link is not defective, if my solder job wasn't sloppy and if the blinksketch itself is correct(you have to enable perhiphery clock or it wont work!)

[John Celo]

I'm getting this exact error when trying to flash it via uVision5 and a DAPLink.

Code: [Select]

Erase Failed!
Cannot access Memory (@ 0xe000edf0, Read, Acc Size: 4 Byte)
Error: Flash Download failed  -  "Cortex-M0+"
All the settings in uVision5 are exactly like in their manual! This is sop8 version of PY32F002! (PY32F002AL15S6TU)

It flashes perfectly via:

Code: [Select]

pyocd flash -t PY32F002Ax5 Project.hexBut doesn't in uVision!

I've no idea what i'm doing wrong. I would like to debug the device within uVision, so I'd love to get this to work!

I've seen a post of somebody with the exact same problem on a chinese forum (with no answer how to solve it).

[John Celo]

I'm getting this exact error when trying to flash it via uVision5 and a DAPLink.

Code: [Select]

Erase Failed!
Cannot access Memory (@ 0xe000edf0, Read, Acc Size: 4 Byte)
Error: Flash Download failed  -  "Cortex-M0+"
All the settings in uVision5 are exactly like in their manual! This is sop8 version of PY32F002! (PY32F002AL15S6TU)

It flashes perfectly via:

Code: [Select]

pyocd flash -t PY32F002Ax5 Project.hexBut doesn't in uVision!

I've no idea what i'm doing wrong. I would like to debug the device within uVision, so I'd love to get this to work!

I've seen a post of somebody with the exact same problem on a chinese forum (with no answer how to solve it).

Great news! Flashing and debugging works in uVision5 with J-Link OB clone thingie! (not sure why it doesn't work with daplink)!

(for beginners out there: J-Link OB thing also works nicely for stm32 arm chips in uVision, so this is definitely handy tool to have!
Keil uVision seems to be particularly popular in China and lots of chinese chips come with uVision project files/examples!)

[prosper]

that doesn't surprise me. in my experience, the py32 is really picky about which probes it'll work with. some flash ok but are unstable for debugging, some work ok with pyocd, but not probers or vice versa... its a mixed bag.

[Sacodepatatas]

Has anybody noticed any funcional difference between the PY32F002BF15P and the PY32L020F15P apart from the specified max speed? I would like to know if these two chips are both interchangeable.

[DavidAlfa]

I guess you'll have to buy a few and find yourself!

[Sacodepatatas]

I guess you'll have to buy a few and find yourself!

I guess so, and i purchased several PY32F002BF from LCSC, that i expect receiving next week. But the PY32L020F seems to be unbtainable from outside China.

The most I can do is treating the F002BF as it was the L020F and see what happens.

[IOsetting]

Has anybody noticed any funcional difference between the PY32F002BF15P and the PY32L020F15P apart from the specified max speed? I would like to know if these two chips are both interchangeable.

What I know about PY32L020 is that it has an extra "deep stop" mode while PY32F002B only has "stop" mode.
If you don't need the low power feature, they are the same.
BTW, PY32F002BF15P can also run in 48MHz, add a "#define RCC_HSI48M_SUPPORT" in CMSIS/Device/PY32F0xx/Include/py32f002bx5.h will enable it.

[DavidAlfa]

Are you sure the "Super Deep sleep" isn't also included with the 030?
If so, then it likely to also be present in the 002.

[IOsetting]

No, 002a/003/030 has no "Super Deep Sleep".
002b/L020 is a different core (the option bytes are different from those of 002a/003/030).
I doubt 002b also supports "Super Deep Sleep" but I didn't test it.

[John_doe]

Hi, another newbie/amateur here, hopefully you still have some patience for one of those 
I'd like some help writing to the flash of the PY32F002AL15S6TU (That is, the SOP-8 package).
After reading this thread and finding out that only the TSSOP-20 package supports ISP, I tried first with my PY32F002AF15P6TU (TSSOP-20) using Arduino as my IDE and writing to the PY32F002AF15P6TU directly from Arduino using a USB->TTL adapter with BOOT0 pulled high and everything worked well on the first try (yes, I was also surprised ) - Got some LEDs blinking and some buzzers beeping and was happy.

But now I want to return to my original goal of flashing the SOP-8 version. The thing is, I haven't touched a traditional IDE since collage (more than 3 decades ago) and I really don't want to start installing and then messing with CubeIDE, Keil, Eclipse, Python stuff, or any other heavy software that requires fiddling with definitions, settings and configuration files. Is there a simple solution like a standalone software such as PuyaISP in the the sense of just running an EXE (I'm on Windows) and writing? Or better yet, writing directly from the Arduino IDE ?

I'll emphasize that I DON'T need debugging at all, just programming the flash with the hex file that I get from the Arduino IDE.


Another thing is the hardware (programmer). I just bought the DAPLINK and J-Link OB that you guys recommended from AliExpress:
https://www.aliexpress.com/item/1005003620126365.html
https://www.aliexpress.com/item/1005005179354439.html

But it'll take about a month for them to arrive and I don't want to wait. I'd like to ask your expert help with how I can use what I have now, which is:
1. One ST-Link v2 clone. specifically this one:
https://www.aliexpress.com/item/33045347900.html
I looked 'under the hood' and it has a APM32F103CBT6 MCU, if it matters.

2. A WCH-LinkE, specifically this one:
https://www.aliexpress.com/item/1005005269690018.html

3. Many Arduino compatible STM32F103 boards (bluepills, blackpills, redpills, Etc.) as well as other Arduino dev boards (ESP32, RP2040, ATMEGA 328p, Etc.)

4. Many USB->TTL converters of all kinds.

So, any ideas? What programmer (if any) I need in order to write this firmware to a bluepill / blackpill? Will my ST-Link v2 clone work?
https://github.com/RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO

[bingo600]

So, any ideas? What programmer (if any) I need in order to write this firmware to a bluepill / blackpill? Will my ST-Link v2 clone work?
https://github.com/RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO

Your ST_link should be able to program a "Bluepill" with the above firmware.

I'd suggest you program the "remap hex" from here : https://github.com/RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO/tree/master/build
Then the picts on the above site seem to match your new cmsis-dap bluepill board.


Unless you're a Linux user.
I can't help with "how to do it" ...


This post might come in handy, when needing the PY devicepacks for pyocd
https://www.eevblog.com/forum/microcontrollers/$0-11-py32f002a-m0-24mhz-320kb-actually-324kb-more-peripherals/msg5213643/#msg5213643


/Bingo

[Sacodepatatas]

Has anybody noticed any funcional difference between the PY32F002BF15P and the PY32L020F15P apart from the specified max speed? I would like to know if these two chips are both interchangeable.

What I know about PY32L020 is that it has an extra "deep stop" mode while PY32F002B only has "stop" mode.
If you don't need the low power feature, they are the same.
BTW, PY32F002BF15P can also run in 48MHz, add a "#define RCC_HSI48M_SUPPORT" in CMSIS/Device/PY32F0xx/Include/py32f002bx5.h will enable it.

Very informative. Thank you so much.

[John Celo]

Hi, another newbie/amateur here, hopefully you still have some patience for one of those 
I'd like some help writing to the flash of the PY32F002AL15S6TU (That is, the SOP-8 package).
After reading this thread and finding out that only the TSSOP-20 package supports ISP, I tried first with my PY32F002AF15P6TU (TSSOP-20) using Arduino as my IDE and writing to the PY32F002AF15P6TU directly from Arduino using a USB->TTL adapter with BOOT0 pulled high and everything worked well on the first try (yes, I was also surprised ) - Got some LEDs blinking and some buzzers beeping and was happy.

But now I want to return to my original goal of flashing the SOP-8 version. The thing is, I haven't touched a traditional IDE since collage (more than 3 decades ago) and I really don't want to start installing and then messing with CubeIDE, Keil, Eclipse, Python stuff, or any other heavy software that requires fiddling with definitions, settings and configuration files. Is there a simple solution like a standalone software such as PuyaISP in the the sense of just running an EXE (I'm on Windows) and writing? Or better yet, writing directly from the Arduino IDE ?

I'm an absolutest newbie/amateur, and I did get SOP-8 flashing, used J-Link OB (with keil uvision) and CMSIS/DAP-link (via pyOCD which is a command line flasher, it's not hard to use at all!).

That being said, SOP-8 is pain in the ass to work with, you functionally have 3 pins left (VCC/GND/SWC/SWD/NRST) if you don't remap SWC/SWD/NRST - and I dont think it's worth bothering with that. SOP-16 is just a better fit for a beginner, since you can hook up uart and have some extra printfs diagnostics messages ON TOP of debugger. I also use uart to send commands from my computer to the chip.

Frankly, if you want Arduino as an IDE, I'd suggest to stick with tssop-20 package, it takes as much space as SOP-8 anyway and costs the same.

I did go the absolute opposite route - I do want a debugger and prefer an IDE, so I use keil uVision (but might move to another IDE).
This sop16 chip is my first step outside of Arduino environment.

So far I've got multiple ADCs working in continuous mode, uart and i2c is also working (although i2c is a bit finicky) using provided high-level HAL (as far as I can tell it's similar to hal used by stm32), I do intend to move to lower level HAL as I find them easier to reason about with reference sheet in hand.

These chips are kind of slow, so if you sample multiple ADCs at total sample rate of 400kHz, and it runs at 24mHz, you only get ~60 cycles
to work for every sample! If you have some external timing sensitive signals that trigger an interrupt, those can easily take 16 cycles or more if you account for storing/restoring registers state, etc! (I have to time this!)

I've yet to try the "hidden" PY32F002A features like DMA and clocking it to 48mhz (is this hard to do?).

[John_doe]

Your ST_link should be able to program a "Bluepill" with the above firmware.

I'd suggest you program the "remap hex" from here : https://github.com/RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO/tree/master/build
Then the picts on the above site seem to match your new cmsis-dap bluepill board.

Thanks Bingo, I was able to write the "remap" firmware to the blue pill with 'STM32 ST-LINK utility'.
I also had success writing to the SOP-8 chip with OpenOCD. I will write a summery of what I did in a new message.

I'm an absolutest newbie/amateur, and I did get SOP-8 flashing, used J-Link OB (with keil uvision) and CMSIS/DAP-link (via pyOCD which is a command line flasher, it's not hard to use at all!).

Thank you, but I already managed to write to the chip with OpenOCD, and a good thing I did, because I HATE Python with a vengeance! 

That being said, SOP-8 is pain in the ass to work with, you functionally have 3 pins left (VCC/GND/SWC/SWD/NRST) if you don't remap SWC/SWD/NRST - and I dont think it's worth bothering with that. SOP-16 is just a better fit for a beginner, since you can hook up uart and have some extra printfs diagnostics messages ON TOP of debugger. I also use uart to send commands from my computer to the chip.

Wait, only 3 pins? Does that mean that if I use the SWC/SWD pins in my Arduino sketch, I won't be able to write to the chip again 

I've yet to try the "hidden" PY32F002A features like DMA and clocking it to 48mhz (is this hard to do?).

No idea, but I would also like to know how to do that. Maybe you just select PY32F030 as your target chip when writing?

[John Celo]

That being said, SOP-8 is pain in the ass to work with, you functionally have 3 pins left (VCC/GND/SWC/SWD/NRST) if you don't remap SWC/SWD/NRST - and I dont think it's worth bothering with that. SOP-16 is just a better fit for a beginner, since you can hook up uart and have some extra printfs diagnostics messages ON TOP of debugger. I also use uart to send commands from my computer to the chip.

Wait, only 3 pins? Does that mean that if I use the SWC/SWD pins in my Arduino sketch, I won't be able to write to the chip again 

The chip is gone if you reassign both SWC/SWD and NRST.
If you have SWC/SWD reassigned, but NRST is still available, you can still flash the chip if you pull NRST low (which forces the SWC/SWD pins to get reassigned to defaults).

What I mean by saying "3 pins" is - that during development, you will probably want to have SWC/SWD connected all the time as you iterate and work on your design & code.

If you reassign SWC/SWD you'll have to have some way to share those programming wires with whatever peripherals you want there and have some way to connect/reconnect those - not to interfere with flashing, as well as have to hold NRST while programming.

It just seems like a hassle for no real benefit? Price is the same, and package is roughly the same size as tssop20.

I bought a few py32 sop8 chips myself, and retrospectively that was a mistake, with so few pins there's not much I can use them for.

[John_doe]

I'm writing a summery of what I did to program these PY32F002A chips. Maybe it'll help some other n00b to save some time:

1. I installed PY32Duino for the Arduino IDE. I just followed the instructions here (used Google to translate the site to English):
https://arduino.py32.org/

2. Wrote a simple test sketch and compiled it. To upload it to the TSSOP-20 version, I just connected a USB to TTL module (costs less than $1 on AliExpress) and uploaded from the Arduino GUI. Instructions on how to connect the module to the chip can be found here:
https://github.com/wagiminator/MCU-Flash-Tools?tab=readme-ov-file#puyaisp

3. To write to the chip packages that do not have a BOOT0 pin, a programmer was needed, I didn't have a suitable one, such as these that were recommended in this thread:
https://www.aliexpress.com/item/1005003620126365.html
https://www.aliexpress.com/item/1005005179354439.html
So I used an ST-Link v2 clone to write this firmware to an STM32F103 "Blue Pill":
https://github.com/RadioOperator/STM32F103C8T6_CMSIS-DAP_SWO/blob/master/build/F103-DAP-SWO-CDC-BLUEPILL-SWD_REMAP.hex
To do that I used STM32 ST-LINK utility from this link:
https://www.st.com/en/development-tools/stsw-link004.html
I had to hold the reset button while pressing Target>Connect . Connections from ST-Link to blue pill are 3.3v->3.3V ; GND ->GND ; SWCLK->SWCLK ; SWDIO->SWDIO.

4. After I had a working CMSIS-DAP, I took the compiled Arduino hex file (if you don't know where to find it, google it) and used OpenOCD. To do that I downloaded the OpenOCD package that already includes the PY32 support files from the PUYA gitee:
https://gitee.com/puya-semiconductor/tools-and-software/blob/master/PY32_GCC/openocd-0.12.0.zip
(Thanks IOsetting and DavidAlfa for the link)
I had to modify the "openocd_run.bat" file to include the ".\bin" folder:

Code: [Select]

.\bin\openocd.exe -s ./scripts -f ./scripts/interface/cmsis-dap.cfg -f ./scripts/target/py32f002x.cfg
5. Had to enable Telnet for my Windows 10 (google it if you don't know how) from the control panel.

6. To connect the blue pill CMSIS-DAP to the IC, I connected the USB of it to my PC and from the blue pill to the PY32F002A the connections are: 3.3V->VCC ; GND->GND ;  SWCLK->SWC ; SWDIO->SWD. For the SOP-8 Package, the pins are 1 ; 8 ; 4 ; 5, respectively.

7. To use OpenOCD, I ran the batch file and in a new command prompt window I entered:

Code: [Select]

telnet localhost 4444And then the following commands:

Code: [Select]

reset halt
flash write_image erase c:/myfolder/myfile.hexNotice the forward slash in the path to hex file. The command will fail if a Backslash is used.

[prosper]

Thanks for the write up. I was excited about openocd for the PY32.... but there's (still) no source and no linux version. Ah well.

Also may be worth noting: beyond openocd and pyocd, there's also probe-rs which supports the py32. Probe-rs has similar capabilities to openocd and pyocd, but has a much nicer CLI than openocd (more like pyocd). It's also pretty quick (not being python). The only real downside that I've found is that its GDB stub is pretty limited (you can't 'load,' for example), so its not as good as a debug server. [though it does have a vscode extension which supports the microsoft DAP protocol directly, if vscode is your thang]

[John_doe]

The chip is gone if you reassign both SWC/SWD and NRST.
If you have SWC/SWD reassigned, but NRST is still available, you can still flash the chip if you pull NRST low (which forces the SWC/SWD pins to get reassigned to defaults).

Thanks for the useful tip! I tried it, that is, pinMode() for both the SWD and SWC pins and indeed couldn't connect to the chip anymore. Holding NRST low (and releasing it after the command "reset halt") worked like a charm!

Thanks for the write up. I was excited about openocd for the PY32.... but there's (still) no source and no linux version. Ah well.

Wait, so the PY32 support of openOCD is built into the executable? I didn't know that... I thought that if you download the official Linux version and add the *.cfg files to it from the gitee archive it'll work.

Also may be worth noting: beyond openocd and pyocd, there's also probe-rs which supports the py32.

Thanks, right now I got myself busy with something else but when I'll return to the PY32F002A project I'll be sure to try probe-rs.