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

[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