STM32 without STM Libraries

[newbie666]

Hello,

I've got one of those stm32l152c discovery boards and I'm looking for a sane way of programming it. Ideally I'd like to use arm-none-eabi toolchain.

Are you aware of any examples on how to program those devices in a "bare bones" way? I've tried using CubeMX to generate makefile based projects but it includes lots of libraries I'll never use.

If not, can you help me to understand what I need exactly to create a bare bones template?
* I know I need a linker file (I can get that from CubeMX generated template)
* I need to initialize the clock (also done in CubeMX generated project but depends on many files so I guess I don't want to use it)
* I need to initialize interrupt table (what would be the simplest way to do it?)
* anything else I should have? I've seen other examples containing a header file with definitions of all the uC registers which seems like a great idea but I can't find one single file that would do that for my chip in those CubeMX projects.

Thanks for help,
Michal

[kapacuk]

Have you looked at libopencm3?

[T.]

You also need to configure the GPIO, timer, UART, ...
It is a big step from cubeMX to bare bone. Why do you want bare bones?

With some changes you get smaller libs.
Cube MX option: Copy only the necessary library files.
Cube MX option: LL libraries instead of HAL
Don't define/use USE_FULL_LL_DRIVER, but this requires come changes.

[newbie666]

libopencm3 seems like a great suggestion! I've found a following tutorial explaining the process quite well:

https://rhye.org/post/stm32-with-opencm3-0-compiling-and-uploading/

[rhb]

If your goal is ARM embedded controllers, take a look at Mecrisp-Stellaris.

http://mecrisp.sourceforge.net/

Forth is a very different model from C.  The great beauty of it is you can interactively test your code before you commit it to memory.  C is close to the hardware, but forth is closer.

One of the first major applications for forth was controlling the railroad car mounted dishes at Kitt Peak Observatory almost 50 years ago.

Chuck Moore devised forth to simplify writing code to control weird hardware.  Matthias Koch has done a brilliant job implementing Mecrisp..

[technix]

Or if you want to go even more bare bones, I have a few Github repositories holding the bare minimum device headers and latest CMSIS headers which they depend on. If you use that there will be no actual library available and everything must be done by direct access to registers using your own code and through readings of the manual. This can be the most laborious route for your purpose, but it will result in the smallest code size.

[mark03]

If you use that there will be no actual library available and everything must be done by direct access to registers using your own code and through readings of the manual. This can be the most laborious route for your purpose, but it will result in the smallest code size.

 
This is how I do most of my work, and it's a lot less work than people seem to think.  The best part is I only need ONE document open (the reference manual), and I can code straight from that, because the register and bit field names in the CMSIS headers follow the reference manual exactly, with very few exceptions.  When I am forced to use a library I am constantly hunting around for the right constants and function names; this wastes a lot of time and is no fun at all.  Obviously, writing your own drivers is more work in some sense, but if you stick with a family like STM32 you very quickly get to the point where you are just copy/pasting from previous projects with small modifications.

[newbie666]

coming from smaller chips that's my favorite way of programming as well.

@technix can you link your github repo? I can't find a link on your website.

[rhb]

If you use that there will be no actual library available and everything must be done by direct access to registers using your own code and through readings of the manual. This can be the most laborious route for your purpose, but it will result in the smallest code size.

 
This is how I do most of my work, and it's a lot less work than people seem to think.  The best part is I only need ONE document open (the reference manual), and I can code straight from that, because the register and bit field names in the CMSIS headers follow the reference manual exactly, with very few exceptions.  When I am forced to use a library I am constantly hunting around for the right constants and function names; this wastes a lot of time and is no fun at all.  Obviously, writing your own drivers is more work in some sense, but if you stick with a family like STM32 you very quickly get to the point where you are just copy/pasting from previous projects with small modifications.

If that's the way you like to work you *really* should look at Mecrisp-Stellaris

http://mecrisp.sourceforge.net/

Matthias Koch has done a brilliant job in the implementation,  The great beauty of forth is the language is the operating system and the editor.  All you need is a dumb terminal window on a PC and a USB-serial adaptor with 3.3 V Tx & Rx lines.

There are over 30 ARM based boards it runs on, so it's almost certain you have a board that has a prebuilt image. The following list is *just* the STM32 based ARM ports.

STM L053 Discovery    STM32L053C8T6
STM Nucleo L152RE    STM32L152RE
STM Nucleo F207ZG    STM32F207ZG
STM Nucleo F303K8    STM32F303K8
STM Nucleo 401RE    STM32F401RE
STM Nucleo 411RE    STM32F411RET6
STM F0 Discovery    STM32F051R8
STM VL Discovery    STM32F100RB
Shenzhen LC Technology board    STM32F103C8T6 (aka the blue pill)
STM F3 Discovery    STM32F303VCT6
STM F4 Discovery    STM32F407VGT6
STM F429 Discovery    STM32F429ZIT6
Very small TSSOP20 packaged    STM32F030F4
STM L152 Discovery    STM32L152RBT6
STM L476 Discovery    STM32L476VG
STM F746 Discovery    STM32F746NG

Terry Porter has been building a very nice documentation site for Mecrisp.

http://hightechdoc.net/mecrisp-stellaris/_build/html/index.html

Forth is a very different mind set from assembly or C.  But once you understand the philosophy and how the outer interpreter works it's very intuitive.  If you're an HP calculator fan you'll feel right at home as it is RPN.

FWIW the STM32F030F4 has 16 KB of flash and 4 KB of SRAM.  That's about the size of the machine Chuck Moore developed forth on, except it's a much faster clock rate.

[mark03]

This is how I do most of my work, and it's a lot less work than people seem to think.  The best part is I only need ONE document open (the reference manual), and I can code straight from that, because the register and bit field names in the CMSIS headers follow the reference manual exactly, with very few exceptions.  When I am forced to use a library I am constantly hunting around for the right constants and function names; this wastes a lot of time and is no fun at all.  Obviously, writing your own drivers is more work in some sense, but if you stick with a family like STM32 you very quickly get to the point where you are just copy/pasting from previous projects with small modifications.

If that's the way you like to work you *really* should look at Mecrisp-Stellaris

I'm a big fan of RPN on my calculators, so I am "pre-biased" to appreciate this, but...  the thing I am missing when I browse those links is a concise argument for "why Forth?" apart from "it's cool and fun!"  I see that it is very memory-efficient, but I usually worry more about clock cycles than memory in my MCU projects these days.  Is the development time and ultimate code performance comparable between a seasoned Forth guru and a C/C++ expert, for applications like DSP and real-time control?  I'd be more interested in some case studies on real programming projects, than examples of blinky in 20 bytes.  E.g. my current project (an electrostatic field mill) involves managing a bunch of ping-pong buffer pairs and DMA streams, with just enough time to de-rotate IQ data coming in at ~ 3 MSPS, downsample, and re-modulate onto an optical link with error-correction coding. 

[rhb]

Forth is intended for embedded control applications.  The Riyahd airport baggage system being one of the more well known applications.  The project was failing after expending a huge amount of time and money.  Forth, Inc rescued it.

The railroad car mounted radio telescope dishes at Kitt Peak were the first major application.  However, IIRC the Peachtree software was written in forth.  This link is a pretty good overview of the language:

https://users.ece.cmu.edu/~koopman/stack_computers/sec3_3.html

The place forth shines is when you're dealing with bare hardware with exotic peripherals such a variable baseline radio telescope.

I spent my career in reflection seismic processing.  For DSP work I tend to lean to a mixture of C & FORTRAN.  Because FORTRAN does not allow pointer aliasing a good compiler can generate faster code.  So the main program and everything except the pure numerical stuff will be C with tight encapsulation and scoping.

If you have to handle large multidimensional arrays FORTRAN notation is much easier to understand.  I've written C to access 3D arrays.  It's not pretty.  And the hard part of numerical work is getting the indexing correct.

I never made the transition to F9x for two reasons.  I could never find a book written for someone who had written parsers with lex and yacc and knew BNF notation and there simply wasn't anything I couldn't do with a mixture of C & F77.  I inherited a line oriented user defined format parser written in F77.  Because of the source of the data it was essential to use FORTRAN for the reads.  I wrote a FORTRAN routine which called a C routine which built a table of pointers to the FORTRAN internal reads and pointers to the structure fields where the results of the read were to be stored.  Once the table was initialized it simply executed the sequence of FORTRAN function calls until it hit a null function pointer and returned.  This produced a 6x speed up.  When you're reading 10-50 million lines of ASCII text that is a huge improvement.

That project was a port of 500K lines of VAX FORTRAN to Unix, so we had to replace all the VMS runtime library calls with code that called the standard C library.  You *really, really* don't want to pass strings between the two languages if you can possibly avoid it.  And you don't want to do any I/O in F77.  Just pure numerical work.

It is almost impossible to match a first class compiler with hand written assembly. In the late 90's there was a Japanese programmer whose hand coded square root was faster than the DEC Alpha compiler version.  He spent some time at UT Austin as a visiting scholar before returning to Japan. Sadly I can't find out his first name, but he created quite a stir in HPC, hence the invitation to Austin.  For reference, a 533 MHz  Alpha 164LX was 4-5 times faster than an x86 machine at the same clock rate.

[rstofer]

Forth is excellent for top down design and bottom up coding. First we define the primitives, then we use them.

Decades ago, I was doing a lot of work with emerging hard disks and SCSI controllers.  I visited one of the controller manufacturers and look over their test setup.  It was written in Forth!

Why?  Well, first you define the SCSI ports, then you write code to send a message, then code to receive a message and then you move up to reading/writing a sector then you read/write an arbitrary number of sectors.  Eventually you reach the level where you read/write multiple sectors to random addresses and verify.

Each level is built on primitives defined at a lower level.  It was elegant!  If a new test idea came about, it was trivial to build it on top of the code that was already known to work.

I know exactly nothing about Forth but I did program my HP48GX calculator in a language that looks a  lot like Forth.  Always building on previous levels of code.

[rhb]

That's a very good description of where forth really is much better than the alternatives.  You're taking small steps and and every step is a progression built on tested code.

The best part is you can test it interactively before you compile it and move to the next word.

[cncjerry]

Save yourself some time and aggravation and use Eclipse/AC6 version from openstm32.org coupled with cubemx.  Both have been getting better over time. It is kept reasonably up to date with chips and firmware.

Jerry

[technix]

coming from smaller chips that's my favorite way of programming as well.

@technix can you link your github repo? I can't find a link on your website.

CMSIS common headers: https://github.com/SushiBits/cmsis
Device-specific files and linker scripts: https://github.com/SushiBits/platform-stm32f0 for STM32F0 and similar for other series.
My repositories follows the UNIX folder structure though, not the ARM Keil one most other libraries use. I use stock Eclipse CDT + GNU MCU Eclipse plugin as my IDE, which largely follows UNIX folder structure.

I am also a contributor in this repository: https://github.com/dmitrystu/libusb_stm32. This is a minimalistic USB library, which is also otherwise dependency free.

[richardman]

The problem with "I will just use the I/O registers and use the MCU reference manual" is that in fact the peripherals for different ST series can be different. Even the most basic of GPIO can have one single 32-bit register for both clear and set ops, or 2 16-bit registers, and it gets worse from there. Yea, it's not a big deal to know which one is which, but you end up with very specific MCU code.

There are better options. Libopencm3 is one, our JumpStart API is another. The key is to have higher level of functional API, not just wrappers for I/O registers.

[technix]

The problem with "I will just use the I/O registers and use the MCU reference manual" is that in fact the peripherals for different ST series can be different. Even the most basic of GPIO can have one single 32-bit register for both clear and set ops, or 2 16-bit registers, and it gets worse from there. Yea, it's not a big deal to know which one is which, but you end up with very specific MCU code.

There are better options. Libopencm3 is one, our JumpStart API is another. The key is to have higher level of functional API, not just wrappers for I/O registers.

There are cases where you just cannot afford the library bloat and have to use the most minimalist option possible.

Also if you have existing drivers for other vendors or even other microcontroller series, you can try porting them over too. My POSIX-compatible UART driver was ported from an AVR UART driver.

[chickenHeadKnob]

I would like to stay on topic but change the question slightly; If you are going with a minimal or bare metal approach is there an efficient way to utilize cubemx output, to leverage the pin planning and clock tree set up features and leave the bloat behind? I am looking to see what others are doing beyond the tedious manually going through the generated code. My current way is only good for a  a one time pass when setting up a project, and I keep thinking there must be a better way.

[technix]

I would like to stay on topic but change the question slightly; If you are going with a minimal or bare metal approach is there an efficient way to utilize cubemx output, to leverage the pin planning and clock tree set up features and leave the bloat behind? I am looking to see what others are doing beyond the tedious manually going through the generated code. My current way is only good for a  a one time pass when setting up a project, and I keep thinking there must be a better way.

For me I just screen cap CubeMX and maybe save the project file (without the code) as part of project documentation. That way I get some reference material when typing in the configuration.

[richardman]

CubeMX will definitely not be "minimal code", because even if you ask it to generate LL (low level) and not HAL code, it still do things like (sorry, just making up some names, I forgot their real names):

  make_port_into_altfunction(...);

and the code would be this hideous mess of

  if (io_pin > 15)
     modify_these_bits();
  else
     modify_other_bits();

When if you are optimizing for the smallest code, you would just write:

   // well, I know I am looking at port X pin Y
  portX->some_field &= ~some_bitmasks;
  portX->some_field |= some_bits;

Those two instructions will for sure much shorter than anything LL/HAL/CubeMX can do.

In theory, if the functions are static inline code, AND PROPERLY WRITTEN, the compiler could do a decent job of matching hand written code. The key here is properly written.

[semir-t]

I think whatever API you use, at some point you will get restricted. This is why I use Reference manual and write my own drives for peripherals that I need. This way I have all the control, and I know what my program is doing.

I had opportunity to work with Arduino, and personally I think when you are starting with MCU programming you thing:  "This is cool" but later on when you start working on serious stuff you find out that libraries that are available can't do what you need (it can be speed, memory etc.). And also, you don't have idea how they work or what peripherals they use. For example, in Arduino you have ready library for servo control, but most of beginners don't know that when you start using this library, your Timer1 is taken.

So I started with bare-metal programing for AVR and when you learn how to do this stuff on one MCU then it easy to transfer to another. Currently, I am working also on STM32 and I didn't have any problems when migrating to this MCU.

I think this is way to go if you want to really know your stuff. Also, If you love Linux, Makefiles and VIM there is no IDE that could give you what these 3 do.

[emece67]

.

[techman-001]

I wrote a CMSIS-SVD parser for Gnu AS some time ago so I didn't have to keep referring to the datasheet. I love datasheets as much as any electronics addict but as even the smallest STM32F chips have over 400 registers, the novelty soon wears off ;-)

http://hightechdoc.net/mecrisp-stellaris/_build/html/svd2gas.html?highlight=assembly

It should work on any STM32F which you have a SVD for.

Cheers,
Terry

[techman-001]

Thanks for mentioning my Doc site. I'm a copious note keeper and the site was initially my private Mecrisp-Stellaris notes and code. They were already in py.sphinx form so rsync'ing to a cloud server was easy.

Cheers,
Terry

[techman-001]

I can't answer one of your questions because it appears only a seasoned Forth guru or a C/C++ expert would be qualified ;-)

I'm neither a seasoned Forth guru or a C/C++ expert, just a electronics technician and I believe that there is a mountain of Forth in real world applications, it's just that we never get to see most of them because the devices are all proprietary.

Forth was on the Philae lander recently, it's always been big in spacecraft mainly because so few MCU's are radiation hardened.

My Doc site http://hightechdoc.net/mecrisp-stellaris/_build/html/index.html does list every conceivable 'Blinky' from blocking loops, multitasking ,interrupt and assembly ones but they're designed to be grokked by someone who has never seen Forth before.

Luckily you don't need to go far to find complex Open Source Forth applications.

How about a 'tethered Forth' that implements, jtag, and a optimizing cross compiler hosted on a Ti Tiva Connected Launchpad connected to a target MSP430 ?

The source code is here: https://sourceforge.net/projects/mecrisp/files/mecrisp-across-0.6-experimental.tar.gz

And how to use it is here: http://hightechdoc.net/mecrisp-across/_build/html/intro.html

[techman-001]

That's a very good description of where forth really is much better than the alternatives.  You're taking small steps and and every step is a progression built on tested code.

The best part is you can test it interactively before you compile it and move to the next word.

Well said!

It's interesting how all Forth programs start off looking like Assembly Language and end up as a specialized language for the problem they solve.

For a (simple example) washing machine controller the Forth program may look like this :

power-on doorclosed? water-fill agitate-10-minutes drain doorclosed? water-fill spin-1-minute drain

Forth and Lisp are the only two programming languages that can 'reprogram themselves'.

[techman-001]

So I started with bare-metal programing for AVR and when you learn how to do this stuff on one MCU then it easy to transfer to another. Currently, I am working also on STM32 and I didn't have any problems when migrating to this MCU.

I think this is way to go if you want to really know your stuff. Also, If you love Linux, Makefiles and VIM there is no IDE that could give you what these 3 do.

For the last 20 years I have felt the same way, then my system of Forth, FreeBSD, Makefiles, Gvim and GnuScreen turned into a IDE all by themselves ;-)

[westfw]

It's not just that the STM library code is bloated, it's that the API strategy that they have chosen can not help but cause bloat.  I think I prefer something like Arduino, with its trivial base (that can nevertheless be optimized, if necessary), good orthogonality (one feature doesn't depend so much on other libraries), and easy extensability.(I can see how a silicon vendor would not be very satisfied with a system that didn't show off, or at least allow, the full breadth of the features they have implemented, though.)

[Karel]

My two cents.

Last year I learned myself to program the STM32 (topic here: https://www.eevblog.com/forum/microcontrollers/pic32mx-vs-stm32l4-my-first-impression/.

I use (almost) the "bare metal" method. I use the CMSIS library (which are in this case just a bunch of header files) and the MCU manual.

To setup a new project, I use STM Workbench: http://www.openstm32.org/System%2BWorkbench%2Bfor%2BSTM32

In the project settings I tell the IDE not to use the HAL.

To make it easier to setup the clocks and the pinmuxing, I use CubeMX, but only to guide me when writing the code.
I never let CubeMX generate the code.

It took me about a month to "master" the STM32 and write all the necessary libs/drivers for SPI, UART, I2C, and to understand
how to use DMA, the ADC, etc. I used the Nucleo-L452RE board for my exercises.

All the software tools come for "free" and the devkit and the programmer are ridiculously cheap.
I payed with my time though. But, at least for this brand/family, it's a one time effort.

[pkplex]

Just want to say thanks for bringing up forth. I was searching for ideas on a sane and bloat free C/C++ framework/environment/whatever to for stm32, and stumbled apon your comment on Saturday evening. Spent Sunday playing around with forth on an F0 discovery, and now I cannot understand how it is not more popular. Its brilliant.

[techman-001]

Just want to say thanks for bringing up forth. I was searching for ideas on a sane and bloat free C/C++ framework/environment/whatever to for stm32, and stumbled apon your comment on Saturday evening. Spent Sunday playing around with forth on an F0 discovery, and now I cannot understand how it is not more popular. Its brilliant.

Fantastic, and the F0 Disco is a really great intro to Cortex-M0.

Forth only appeals to certain mindsets I think, but to those 42 people .... Forth rules! 

I've just put together a new LMT01 temperature sensor binary image for Blue Pills and similar STM32F103 boards. It uses the USB interface for power and a virtual serial port, has a few handy subroutines (Words) and most of the Peripheral Registers are memory mapped ready to be read or written in real time.

I hope one can get a feel for Forth and Forth development with this image. If you try it, please let me know?

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

I'm creating exactly the same project as below for the F0 Disco right now and it should be up in a day or so.
I'll post the details here, on my Utube channel, and my Doc site.

The standalone image requires nothing else to run. Details and image at the url below.

https://mecrisp-stellaris-folkdoc.sourceforge.io/project-stm32f103-lmt01.html#stm32f103-lmt01

The image runs on a STM32F103 MCU with 64 KB of flash like so:

Code: [Select]

free (bytes)
FLASH.. TOTAL REPORTED: 131072 USED: 107932 FREE: 23140
RAM.... TOTAL PRESET: 20000 USED: 1596 FREE: 18404
It also has the MCU Signature reader:

Code: [Select]

stm32id
Die xy coords: 107741012
Wafer Number: 72
Lot_num ascii encoded  [23:0]: 0x00555285  | U R .
Lot_num ascii encoded [55:24]: 0x87237267  | . # r g
There is a accurate ms.delay using the Systick

Code: [Select]

1000 ms.delay     --> gives a 1 second blocking delay
Some Registers in real time:

Code: [Select]

rcc_cfgr.
RCC_CFGR () $001D840A
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1 0 0 0 0 1 0 0 0 0 0 0 1 0 1 0

gpioa_odr.
GPIOA_ODR (read-write) $0000A000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
Finally the temperature of a single LMT01 sensor

Code: [Select]

t
26,8 C   ok.

[voltsandjolts]

MicroPython is also worthy of mention here.
I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

[techman-001]

MicroPython is also worthy of mention here.
I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

Micro Python is interesting but has a couple of major disadvantages to Forth.

1. My just released self contained bootable Binary Image which contains the USB, temperature reading code, other utilities, thousands of register print words and so on, is only 60KB in size. Micropython needs at least 256KB of flash just for Micropython, which means it can't run on Cortex-M0 chips limited to a maximum of 64KB Flash. By comparison Mecrisp-Stellaris only needs 20KB of flash for itself.

2. In the embedded world microseconds can be vital, so a language with a garbage collector such as Python will have timeslots where the MCU is busy garbage collecting, and people have found this to be a issue in some case.

3. Anything as pretty as Python must have a evil soul 

[GeorgeOfTheJungle]

I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

Python is much nicer and higher level, and has no semicolons :-) , but the niceties come at a price. Python, Lua or JS require a serious µC to run at reasonable speeds. That is, if you need the speed. Maybe not. Maybe yes. I'm mixing C++ and Forth in my esp32s, because doing so there's some things that now I can reprogram on the fly and don't require anymore a whole recompilation+reflash. It's not a fast as C but good enough, and doesn't eat too much memory. Techman-01 is the culprit. And the hp65 I had when I was a child.

[techman-001]

I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

Python is much nicer and higher level, and has no semicolons :-) , but the niceties come at a price. Python, Lua or JS require a serious µC to run at reasonable speeds. That is, if you need the speed. Maybe not. Maybe yes. I'm mixing C++ and Forth in my esp32s, because doing so there's some things that now I can reprogram on the fly and don't require anymore a whole recompilation+reflash. It's not a fast as C but good enough, and doesn't eat too much memory. Techman-01 is the culprit. And the hp65 I had when I was a child.

You had a hp65 !!!

I could only afford a ti-SR-52. No wonder I didn't start using Forth until 2014!

Your esp32s stuff sounds pretty clever so I'm having a hard time visualizing you swinging thru the trees eating a banana 

What Forth are you running on the esp32, could it be Mitch Bradley's CForth ?

[voltsandjolts]

Micro Python is interesting but has a couple of major disadvantages to Forth.

1. ... Micropython needs at least 256KB of flash just for Micropython...

2. ... a garbage collector ..... to be a issue in some case.

3. Anything as pretty as Python must have a evil soul 

[1] I wouldn't regard 256KB FLASH requirement as a major disadvantage, although it is a trade off. But 256KB M0 micros can be purchased for a couple of bucks.

[2] Ahh, Forth has no dynamic allocation, that's nice. The Python GC is non-deterministic but can be switched off when running short bits of time critical stuff. Of course, if your whole app is time critical (within a few ms) then yes, GC could be a show stopper.

[3] Hah, by that logic, I have a heart of gold!

[techman-001]

Micro Python is interesting but has a couple of major disadvantages to Forth.

1. ... Micropython needs at least 256KB of flash just for Micropython...

2. ... a garbage collector ..... to be a issue in some case.

3. Anything as pretty as Python must have a evil soul 

[1] I wouldn't regard 256KB FLASH requirement as a major disadvantage, although it is a trade off. But 256KB M0 micros can be purchased for a couple of bucks.

[2] Ahh, Forth has no dynamic allocation, that's nice. The Python GC is non-deterministic but can be switched off when running short bits of time critical stuff. Of course, if your whole app is time critical (within a few ms) then yes, GC could be a show stopper.

[3] Hah, by that logic, I have a heart of gold!

It's a  major disadvantage only compared to Forth. I'm sure most Micropython users probably want the Ghz Cortex-M's for speed anyway ?

I forgot to add, while Assembly and C are about 3 times faster than Forth, Forth is about 30 faster than Python in my tests.

[exe]

I used ChibiOS, and found it the most intuitive so far.

[voltsandjolts]

It's a  major disadvantage only compared to Forth. I'm sure most Micropython users probably want the Ghz Cortex-M's for speed anyway ?

Standard PyBoard v1.1 is STM32F405, so approx 1MB/192KByte/168MHz and MicroPython runs well on that.

I forgot to add, while Assembly and C are about 3 times faster than Forth, Forth is about 30 faster than Python in my tests.

MicroPython has options for writing critical sections in assembly, or using the 'Viper' native code emitter, or writing Python or C modules which can be included at compile time. Pre-allocation and re-use of buffers helps reduce dynamic allocation and associated GC costs. So, in applications that have some crictical sections and are more relaxed elsewhere it works very well. Probably my favorite feature of MicroPython is that it makes a great 'glue' language that makes for 'speedy development', if not a 'speedy runtime'.

[westfw]

Forth is about 30 faster than Python in my tests.

Is that all?  That's a pretty impressive Python implementation!

[1] I wouldn't regard 256KB FLASH requirement as a major disadvantage
[2] Ahh, Forth has no dynamic allocation, that's nice.

To me it seems very odd to see those mentioned consecutively.  Or maybe it's an age thing:  to me, dynamic memory allocation seems like one of the first things that ought to show up as you get to "more powerful" processors (but garbage collections: not so much.)

I suspect that the big difference is that your successor will still be able to read your python code a year after you've left the company, while with Forth you might have a problem with your own code after a 2-week vacation :-)

[voltsandjolts]

[2] Ahh, Forth has no dynamic allocation, that's nice.

Agree with westfw; just to clarify my statement, while dynamic allocation is useful it does come with a GC cost, which may be a lot or nothing depending on how your code is written.
I just meant that in a hard realtime system, not having dynamic allocation could be better because unpredictable GC execution time is one less thing to worry about.

[jhpadjustable]

Does sbrk qualify as dynamic memory allocation? How about the malloc layer on top of it? Neither of those GC but they are most certainly performed on demand of the program at runtime, and not statically at link time. Is the term being misused in this thread or am I just that old?

[voltsandjolts]

We are discussing bare metal here, not embedded OS.

[MT]

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

Why would M3 suck compared to M0?

[techman-001]

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

Why would M3 suck compared to M0?

The STM32F103 is a OLD chip based on the Cortex-M3 first announced in 2004. In fact it is the first generation of Cortex M3 chips from ST Micro (Introduced in 2011) and they have a lot of known issues. A much better choice for new projects are either STM32F0, F0+ series or STM32F4 series. The prices are about the same for comparable parts.

STM32F103 Issues
CAN Bus * Shares memory with the usb hardware, which means that usb and canbus cannot be enabled at THE SAME TIME
Serial Comms * NO AUTOBAUD
USB * Shares memory with the canbus hardware, which means that usb and can cannot be enabled at THE SAME TIME.
USB *  must use a CRYSTAL unlike later stm32 chips which use only a internal RC clock for USB
Digital to Analogue Converter *  DOESN’T have one
GPIO I/O port registers *  Have to be accessed as 32-bit words, half-word or byte accesses are NOT allowed.
GPIO I/O port registers * Very CONFUSING to configure with CRL and CRH in comparison to Cortex-M0
I2C *  There are SIX pages of ERRATA for the I2C peripheral
DFU *  NO DFU bootloader (for flashing via USB)

[iMo]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

[techman-001]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

There isn't really a Forth  'community', rather thousands of Forth users doing their own thing with their own Forth and their own disparate hardware from 6502's to ARM cpu's.

But ... because Forth probably runs on more hardware than any other OS, most code isn't compatible.

Libraries ... do you mean piles of definitions and functions/methods stacked together ? ;-)

We have plenty of those.
Here is one of mine, it's freely available to anyone. Of course they'd need to use it on a STM32Fxx and modify the code for a different clock speed.

https://mecrisp-stellaris-folkdoc.sourceforge.io/systick-library.html#systick-library

[SiliconWizard]

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

Why would M3 suck compared to M0?

The STM32F103 is a OLD chip based on the Cortex-M3 first announced in 2004. In fact it is the first generation of Cortex M3 chips from ST Micro (Introduced in 2011) and they have a lot of known issues. A much better choice for new projects are either STM32F0, F0+ series or STM32F4

Oh, yeah. This is not because it's a Cortex-M3 per se though, so probably why MT asked that!
And yes, I agree the STM32F103, although very popular for some reason (a bit like the old Atmega's), is a poor choice these days. There's now myriads of better MCUs from STM. Don't neglect the L4 series also, for those aiming for lower power stuff.

It's almost like the F103 is becoming like a slow disease that's gotten contagious. It's growing everywhere, is still being cloned all over the place, dev boards for it are also growing like fungus. Please let the old chap die its own death! 

[westfw]

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

Actually, I find it quite the opposite.
Cortex-M0 doesn't support the 32bit "Thumb-2" instructions, which means that many of your traditional ARM instructions are completely missing (divide), or have severe limitations (no "AND/OR/EOR" with immediate values, LDR/STR indexed-with-offset limited to offsets <32, more.)  It's a PITA to program in assembly language, and the code produced by even good compilers is frequently big, slow, and ugly (compared to the CM3.)


Note that this is completely different than "the new ST M0 chips have less F-ed up peripherals than the ancient 32f103", which has nothing to do with CM0 cs CM3 CPUs.


Now, it does seem that CM3 has largely lost vendor interest in favor of CM4 (and CM0); I don't quite understand why that's the case - I suspect it has more to do with hardware licensing and implementation details than CPU architectural issues.  (Doesn't the M0 have a flat-rate license fee, rather than a royalty-based scheme?)

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

I suppose I would believe that the main reason that Forth tends to be looked on a more "write only" than C/C++ is that there's a large community of C/C++ programmers who have done a pretty good job of establishing acceptable and unacceptable "styles" of C/C++ programming.  And Forth is more of an "everyone is on their own" situation.
But that's still means that Forth has a problem :-(

(Assembly language has a similar problem.  Back when I worked on assembly language code for a living, the target system had well-established standards in terms of macro definitions (including complex data structures), calling conventions, formatting, name selection, and so on.  Code written in that community was pretty understandable and portable between maintainers.  Nowadays, in our modern "why would you want to program in assembly?" age, it's more of a free-for-all :-( )

[techman-001]

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

Actually, I find it quite the opposite.
Cortex-M0 doesn't support the 32bit "Thumb-2" instructions, which means that many of your traditional ARM instructions are completely missing (divide), or have severe limitations (no "AND/OR/EOR" with immediate values, LDR/STR indexed-with-offset limited to offsets <32, more.)  It's a PITA to program in assembly language, and the code produced by even good compilers is frequently big, slow, and ugly (compared to the CM3.)

Note that this is completely different than "the new ST M0 chips have less F-ed up peripherals than the ancient 32f103", which has nothing to do with CM0 cs CM3 CPUs.

Now, it does seem that CM3 has largely lost vendor interest in favor of CM4 (and CM0); I don't quite understand why that's the case - I suspect it has more to do with hardware licensing and implementation details than CPU architectural issues.  (Doesn't the M0 have a flat-rate license fee, rather than a royalty-based scheme?)

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

I suppose I would believe that the main reason that Forth tends to be looked on a more "write only" than C/C++ is that there's a large community of C/C++ programmers who have done a pretty good job of establishing acceptable and unacceptable "styles" of C/C++ programming.  And Forth is more of an "everyone is on their own" situation.
But that's still means that Forth has a problem :-(

(Assembly language has a similar problem.  Back when I worked on assembly language code for a living, the target system had well-established standards in terms of macro definitions (including complex data structures), calling conventions, formatting, name selection, and so on.  Code written in that community was pretty understandable and portable between maintainers.  Nowadays, in our modern "why would you want to program in assembly?" age, it's more of a free-for-all :-( )

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

I didn't write that. I wrote this, which is all about the peripherals.
Quote from: techman-001 on November 11, 2019, 07:09:01 am "If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0."

As a Forther, I have no problem with Assembly. Write it how you like.

[techman-001]

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

Actually, I find it quite the opposite.
Cortex-M0 doesn't support the 32bit "Thumb-2" instructions, which means that many of your traditional ARM instructions are completely missing (divide), or have severe limitations (no "AND/OR/EOR" with immediate values, LDR/STR indexed-with-offset limited to offsets <32, more.)  It's a PITA to program in assembly language, and the code produced by even good compilers is frequently big, slow, and ugly (compared to the CM3.)

Now, it does seem that CM3 has largely lost vendor interest in favor of CM4 (and CM0); I don't quite understand why that's the case - I suspect it has more to do with hardware licensing and implementation details than CPU architectural issues.  (Doesn't the M0 have a flat-rate license fee, rather than a royalty-based scheme?)

I'm quite fond of the M0 and as you have observed I'm not the only one. The wide range of easy to configure peripheral mix, speed and low cost are perfect for me, I love the hardware side of it.

I'm not particularly fond of the Cortex-M0 ISA as my first love was Motorola 6800 assembly, and what can compare to ones first love ?

Whilst it does have some limitations which are not in any way "severe" to me, none of them are a problem for Forth, which easily works around them in a quite transparent way.

For example:

Code: [Select]

registerliteral, ( x Register - - )
Generate shortest possible sequence to get x into given low Register.
On M0: A movs-lsls-adds… sequence
M3/M4: movs / movs-mvns / movw / movw-movt
Thumb 16 bit code does save about 2/3 the Flash space compared to 32 bit ARM code, according to ARM, who also state that internally, the same 32 bit instructions are still run. The code space saving is the reason Thumb exists from my reading of the docs.

I have been coding for both the STM32F051 and the STM32F103 lately and I'll take the F051 over the F103 any day.

Note: I'll still happily take a M3 over anything AVR or older.

[iMo]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

There isn't really a Forth  'community', rather thousands of Forth users doing their own thing with their own Forth and their own disparate hardware from 6502's to ARM cpu's.
But ... because Forth probably runs on more hardware than any other OS, most code isn't compatible.
Libraries ... do you mean piles of definitions and functions/methods stacked together ? ;-)
We have plenty of those.
Here is one of mine, it's freely available to anyone. Of course they'd need to use it on a STM32Fxx and modify the code for a different clock speed.
https://mecrisp-stellaris-folkdoc.sourceforge.io/systick-library.html#systick-library

I think you have described the problem perfectly!
Usually the STM32Fxx is just a small piece of your "solution", you may have a dozen of other external chips and subsystems connected, doing something useful.

[techman-001]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

There isn't really a Forth  'community', rather thousands of Forth users doing their own thing with their own Forth and their own disparate hardware from 6502's to ARM cpu's.
But ... because Forth probably runs on more hardware than any other OS, most code isn't compatible.
Libraries ... do you mean piles of definitions and functions/methods stacked together ? ;-)
We have plenty of those.
Here is one of mine, it's freely available to anyone. Of course they'd need to use it on a STM32Fxx and modify the code for a different clock speed.
https://mecrisp-stellaris-folkdoc.sourceforge.io/systick-library.html#systick-library

I think you have described the problem perfectly!
Usually the STM32Fxx is just a small piece of your "solution", you may have a dozen of other external chips and subsystems connected, doing something useful.

I should hope so, it would be a waste of a perfectly good Forth otherwise. This is exactly what people have been doing since digital electronics first appeared.

[exe]

And yes, I agree the STM32F103, although very popular for some reason (a bit like the old Atmega's), is a poor choice these days. There's now myriads of better MCUs from STM. Don't neglect the L4 series also, for those aiming for lower power stuff.

I buy STM32F103 for aliexpress and they cost very cheap. I think I bought a development board less than 3euro delivered. (although I don't know if they are genuine or not, but so far worked in my projects)

Of course there are better MCUs, but are they in the same price range ($0.8 or even less)? Of course if it's for production it's unlikely someone will buy from aliexpress, buy for home use why not?

[techman-001]

And yes, I agree the STM32F103, although very popular for some reason (a bit like the old Atmega's), is a poor choice these days. There's now myriads of better MCUs from STM. Don't neglect the L4 series also, for those aiming for lower power stuff.

I buy STM32F103 for aliexpress and they cost very cheap. I think I bought a development board less than 3euro delivered. (although I don't know if they are genuine or not, but so far worked in my projects)

Of course there are better MCUs, but are they in the same price range ($0.8 or even less)? Of course if it's for production it's unlikely someone will buy from aliexpress, buy for home use why not?

They are far cheaper than new units from American factory resellers, so even if they're genuine, they're not new. I think they are e-waste recycles, and that's cool too but only if the reseller advertises it.

In any event, I think that the STM32F103 sales from China have been astronomical and perhaps they're running low on stock now, hence the 'rise of the clones' ;-)

No experienced and certified company would EVER touch these chips for production because they break every rule of QA, starting with traceability.

[exe]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

[techman-001]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

Based on my feedback from https://mecrisp-stellaris-folkdoc.sourceforge.io/f1-usb.html#stm32f1-usb, there are a few odd MCU's in Blue Pills.

[iMo]

The "original STM32F103" on BluePill board works fine and I never had any problem with it. BP is a cheapo board, people buy 10+ pieces for their hobby designs. All people I know report 128kB flash so a good buy.

There are GD32F103 and CS32F103 clones. Those are Chinese chips, not related to STM, afaik.

The GD32 are flash-less, using external flash put inside its package. There were some tests with GD32 done in past and the chips basically work, it could be there are some minor differences related to settings of the clocks, etc. The GD32 are faster than the STM32 due to missing on-chip flash. Also do not expect 128kB of flash with GD/CS.

I would not be bashing those "odd" chips, however. We have to master them simply, when interested in cheapo solutions, that is all

[chickenHeadKnob]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

Compare your Lcsc stm32f103C to Lcsc stm32f302C8  $1.69 single $1.25 qty(10)
This is a cortex m4 with 64K Rom,16K RAM and USB and better peripherals all round.

Count me in the camp that doesn't get why hobbista's are fixated with the F103 or cortex M0 mcu's or even more limited things like those PADUAK
That said, ST's large processor portfolio and weird pricing complicates selection and you need to invest a lot of time to familiarize.

[exe]

Count me in the camp that doesn't get why hobbista's are fixated with the F103 or cortex M0

Another point is software support, e.g., arduino, embed.org, chibios, etc (unless one wants to use cubemx). Things getting better over time, but still.

[techman-001]

I dunno where they get them in such quantities and what's inside, but it would be interesting to know. I'd expect it to be GD32F103 (or rejects of). But the thing is, it works, and they are well supported in software, and bugs already known.

Interesting thing, compare prices for, say STM32F103C8T6, on mouser and lcsc. It's 5.6euro+VAT (that is $6) vs $1.7. Nuff said.

Compare your Lcsc stm32f103C to Lcsc stm32f302C8  $1.69 single $1.25 qty(10)
This is a cortex m4 with 64K Rom,16K RAM and USB and better peripherals all round.

Count me in the camp that doesn't get why hobbista's are fixated with the F103 or cortex M0 mcu's or even more limited things like those PADUAK
That said, ST's large processor portfolio and weird pricing complicates selection and you need to invest a lot of time to familiarize.

I can answer why I like STM32F051's. I bought 480 of them in 2014 from Avenet for $0.56 each. They are bonafide STM chips in UFN32 with 64KB Flash and 8KB ram, they have 33 peripherals and clock at 48Mhz. I've run one for over a year at 96 MHz just to see if it was going to die and I'm still using it right now.

I use Forth, so 64KB flash is massive for what I do, which is small embedded controllers. I don't do IoT or USB etc.

This mcu is pretty much at the bottom of the pecking order of STM32 offerings but is still a universe away from old devices like AVR's and 16 bit PIC's.

A STM32F302 would be total overkill for me as I barely use the full capability of the STM32F051.

[chickenHeadKnob]

I can answer why I like STM32F051's. I bought 480 of them in 2014 from Avenet for $0.56 each. They are bonafide STM chips in UFN32 with 64KB Flash and 8KB ram, they have 33 peripherals and clock at 48Mhz. I've run one for over a year at 96 MHz just to see if it was going to die and I'm still using it right now.

I use Forth, so 64KB flash is massive for what I do, which is small embedded controllers. I don't do IoT or USB etc.

This mcu is pretty much at the bottom of the pecking order of STM32 offerings but is still a universe away from old devices like AVR's and 16 bit PIC's.

A STM32F302 would be total overkill for me as I barely use the full capability of the STM32F051.

Well if you are buying 480 mcu's at a crack I would put you beyond the hobby class of people.  I once worked for cheapskate boss that forced me to squeeze the most out of a M6805, I for sure wouldn't do that for fun on my own time. For small time hobby people it can make the most sense to standardize on a processor that will conceivably do everything  they might want to and thus simplify programming and also reduce their lab inventory of parts without worrying about optimizing other criteria like price.

[JohnnyBerg]

You could have a look on my Github repo, it allows you to code, flash and debug devices like an Arduino, without using the Arduino IDE.
The repo uses Visual Studio Code as a IDE. It is not based on existing solutions like PlatformIO.

[mac.6]

Cortex-M0+ are a bit so-so, they have great power figure due to the low die size, some very nice debug capabilities (ETM trace buffer) but are crippled in debug by their 2 hw breakpoints only.

Bare metal programming is still a thing with these little MCU, just be sure to not reinvent the wheel or at least reinvent only once!
What you should really focus on is the development environment, be able to setup your own build/debug system out of vendor related IDE/tools is a nice thing to have, be it based on makefile/cmake/whatever. Also know to split your code between generic code and porting layers is a big plus, nothing worse that code that mix hardcoded hw and generic code.

[MT]

I have been coding for both the STM32F051 and the STM32F103 lately and I'll take the F051 over the F103 any day.
Note: I'll still happily take a M3 over anything AVR or older.

Okileydokely, so you luve F0 before F3 but "how" do you luve M0+ over M0 and M3?
For example the G071 beats the crap of a F051 for meager cents in pricing.

Like 30 years ago i once tried to try FORTH on a 68HC11 but it was so backwardish, inverse, upsidedown, right to left so i didnt understand anything ending coding the 68HC11 in assembler instead.

[techman-001]

I have been coding for both the STM32F051 and the STM32F103 lately and I'll take the F051 over the F103 any day.
Note: I'll still happily take a M3 over anything AVR or older.

Okileydokely, so you luve F0 before F3 but "how" do you luve M0+ over M0 and M3?
For example the G071 beats the crap of a F051 for meager cents in pricing.

Like 30 years ago i once tried to try FORTH on a 68HC11 but it was so backwardish, inverse, upsidedown, right to left so i didnt understand anything ending coding the 68HC11 in assembler instead.

I bought 480 stm32F051's in 2014 for $0.56 each. UFN32, 64KB flash, 8kB ram. It's a lifetimes supply of luve!

For what I do, the M0 is TONS more than need. I also have a L073 which is more complex, mainly in the low power area, I'm still playing with it.

Right now I'm using Forth on a GD32VF103 RISC-V  "longan-nano" board. There is more to life than STM32F103's.

Code: [Select]

free (bytes)
FLASH.. TOTAL REPORTED: 131072 USED: 83308 FREE: 47764
RAM.... TOTAL PRESET: 32767 USED: 13675 FREE: 19092

Code: [Select]

id
UNIQUE_ID[31:0]  0x3641294D | 6 A ) M
UNIQUE_ID[63:32] 0x00123736 | . . 7 6
UNIQUE_ID[95:64] 0xFFFFFFFF | . . . .

Code: [Select]

gpioa.
GPIOA_CTL0 (read-write) $44444444
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0


GPIOA_CTL1 (read-write) $444444A4
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 1 0 1 0 0 1 0 0


GPIOA_ISTAT (read-only) $0000A4FF
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 1 1 1 1 1 1


GPIOA_OCTL (read-write) $0000A000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0


GPIOA_BOP (write-only) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


GPIOA_BC (write-only) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


GPIOA_LOCK (read-write) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

 ok.
"ending coding the 68HC11 in assembler" ... you say that as tho it's a bad thing ?

One of my most fun era's was programming the HC11 in Assembly. It was smooth as silk, the code flowed from my fingertips like beer from a keg at a Australian pub!

[MT]

"ending coding the 68HC11 in assembler" ... you say that as tho it's a bad thing ?

One of my most fun era's was programming the HC11 in Assembly. It was smooth as silk, the code flowed from my fingertips like beer from a keg at a Australian pub!

No i didnt say assembler is a bad thing rather that at that point in time i didnt understand the concepts of "FROTH"
(beer) on a 68HC11, thats all. 68HC11 was a neat device back then we used to shoehorn in things in 2k of EEPROM.

[iMo]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

[profdc9]

I use the STM32F103CBT6, and the main reason is that I am trying to produce projects with longevity.  It has some quirks and bugs due to errata that are quite annoying, however, it more-or-less works and is so cheap and common is hard to imagine it won't be around for decades to come.  Of course, if I didn't care about that, I could use STM32F4, but if a project is going to last a long time, it should be made with parts that are super common and available.  I've been burned by parts not being that available with the consequence they become quite expensive and rare. 

[techman-001]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

No problem, what do you want in it ?

[iMo]

The Forth above.. Such it uses 128kB of flash (and 20kB of ram)..

[techman-001]

I use the STM32F103CBT6, and the main reason is that I am trying to produce projects with longevity.  It has some quirks and bugs due to errata that are quite annoying, however, it more-or-less works and is so cheap and common is hard to imagine it won't be around for decades to come.  Of course, if I didn't care about that, I could use STM32F4, but if a project is going to last a long time, it should be made with parts that are super common and available.  I've been burned by parts not being that available with the consequence they become quite expensive and rare.

Rumor has it that STM32F103CBT6 and the clones will still be available at the heat death of the universe.

And now you have the very cheap and STM32F103 pin compatible GD32VF103  RISC-V chip from China. Sure you'll need new firmware but the peripherals are mostly the same as far as I can see at this point but I'm not 100% familiar with it yet.

GD32VF103 Literature package: https://sourceforge.net/projects/mecrisp/files/Target%20literature%20package%20for%20GD32VF103.tar.gz/download

What I've done with it so far: https://mecrisp-stellaris-folkdoc.sourceforge.io/gd32vf103.html#gd32vf103-longan-nano

[jhpadjustable]

And now you have

Not until I can easily buy 4 or 480 bare chips at a competitive price, I don't.  The GD32VF103 does promise to be a leading choice once they're generally available at a reasonable price. Or am I just looking in the wrong places?

I bought 480 stm32F051's in 2014 for $0.56 each. UFN32, 64KB flash, 8kB ram. It's a lifetimes supply of luve!

If you can't be with the one you luve, luve the one you're with. 

[techman-001]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/bluepill-128kb-usb.tar.gz/download

[bingo600]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

EDIT: Totally missed techman's reply above ... And that imu asked for for Forth for a Bluepill     Well here's the BMP (BlackMagic Probe) guide anyway & a DIY from src

Please direct any BMP related replies to this thread , i have asked Dave to move this post there too.
https://www.eevblog.com/forum/microcontrollers/make-a-blackmagic-probe-out-of-a-stm32-bluepill/msg2823502/#msg2823502




I just "pulled" the latest git 30 min ago , and built it for a bluepill (attched)
driver - contains udev/inf files , bmp .. the binaries.

**** git version ****
From https://github.com/blacksphere/blackmagic
   8a07f44..0b6f393  master     -> origin/master
Updating 8a07f44..0b6f393


***** PIN Defs *****

See here for STM BMP Pin defs
https://github.com/blacksphere/blackmagic/blob/master/src/platforms/swlink/platform.h

/* Hardware definitions... */   - SWLINK
#define TMS_PORT   GPIOA
#define TCK_PORT   GPIOA
#define TDI_PORT   GPIOA
#define TDO_PORT   GPIOB
#define JRST_PORT   GPIOB
#define TMS_PIN      GPIO13
#define TCK_PIN      GPIO14
#define TDI_PIN      GPIO15
#define TDO_PIN      GPIO3
#define JRST_PIN   GPIO4

#define SWDIO_PORT    TMS_PORT
#define SWCLK_PORT    TCK_PORT
#define SWDIO_PIN   TMS_PIN
#define SWCLK_PIN   TCK_PIN


You could use any STM programming sw as a replacement for st-link  (ie. if you have windows)
Only problem is if the programming sw honours the chips reported 64k , and refuses to program more than that.

st-flash --flash=0x20000  - overrides the 64k reported , and tells it to use 128k

I use linux , don't know if st-flash exists for windows (it might)
Edit: There's a v1.3.0 here  - It might work , i use 1.5.1-50 (linux) SVN
https://github.com/texane/stlink/releases/tag/1.3.0

You might be able to program via serial/uart w. stm32flash , and it seems like Tormod made it use 128K for a stm32f103c8
https://sourceforge.net/projects/stm32flash/
There's a 64-bit win exe here
https://sourceforge.net/projects/stm32flash/files/


Edit: Seems line imu is using STM's st-link to program 90k Forth into a 64K device wo. problems , that means the BMP combined might be progra,med w. st-link too.
That ought to make life easier for a M$ user.

Programmer
----------------------
I use a cheap st-link "usb alu stick" clone , and SWD for programming the bluepill.


***** st-link for "easy" programming  else use oocd *****
Try to install via your distro's install first


else build from source

git clone https://github.com/texane/stlink
cd stlink
make
cd build/Release
make
make install
(make sure /usr/local/lib/ is in some .conf file in /etc/ld.so.conf.d)
ldconfig





********  Program the Bluepill w. the combined dfu & binary in the attached zip *****

st-flash erase
** Now disconnect & reconnect the BMP

blackmagic/src$ st-flash --flash=0x20000 write bmp-combined-dfu-bin.bin 0x8000000
st-flash 1.5.1-50-g3690de9
2019-12-10T19:49:45 INFO common.c: Loading device parameters....
2019-12-10T19:49:45 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-12-10T19:49:45 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Forcing flash size: --flash=0x00020000
2019-12-10T19:49:45 INFO common.c: Attempting to write 90196 (0x16054) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08016000 erased
2019-12-10T19:49:47 INFO common.c: Finished erasing 89 pages of 1024 (0x400) bytes
2019-12-10T19:49:47 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-12-10T19:49:47 INFO flash_loader.c: Successfully loaded flash loader in sram
 89/89 pages written
2019-12-10T19:49:53 INFO common.c: Starting verification of write complete
2019-12-10T19:49:54 INFO common.c: Flash written and verified! jolly good!


************ DONE *******************


DIY

BMP project recommends swlink as probe target for a bluepill

git clone --recursive https://github.com/blacksphere/blackmagic.git
cd blackmagic
make
cd src
make clean
#make PROBE_HOST=stlink
make PROBE_HOST=swlink




***** st-link for "easy" programming  else use oocd *****
Try to install via your distro's install first


else build from source

git clone https://github.com/texane/stlink
cd stlink
make
cd build/Release
make
make install
(make sure /usr/local/lib/ is in some .conf file in /etc/ld.so.conf.d)
ldconfig





********  Program the Bluepill dfu & then upgrade *****

Requires that you have build from source (DIY).


st-flash erase

blackmagic/upgrade$ sudo st-flash erase
st-flash 1.5.1-50-g3690de9
2019-12-10T19:54:20 INFO common.c: Loading device parameters....
2019-12-10T19:54:20 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-12-10T19:54:20 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Mass erasing

** Now disconnect & reconnect the BMP

Flash the dfu bootloader
st-flash --flash=0x20000 write blackmagic_dfu.bin 0x8000000

Now the dfu bootloader is programmed
** Now disconnect & reconnect the BMP




dfuutil will fail if the binary is larger than 64KB , on a stm32f103c8 device.
It honours the flashsize reported from the c8 , even if it "has" 128KB


But there is a "trick" ....
 
If blackmagic DFU is installed on the BMP you can use the blackmagic_upgrade executable to upgrade the BMP
The blackmagic_upgrade is included as source in the upgrade dir.


First build blackmagic_upgrade
----------------------------------
If you are in the src dir , then cd ../upgrade , then :
make

Now blackmagic_upgrade should be there.

sudo ./blackmagic_upgrade   

Will upgrade the target w. a  blackmagic.bin from ../src     -- use sudo


/blackmagic/upgrade$ sudo ./blackmagic_upgrade
[sudo] password for bingo:       

Black Magic Probe -- Firmware Upgrade Utility -- Version 1.0
Copyright (C) 2011  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Resetting device in firmware upgrade mode...
Found device at 003:006
All operations complete!

/blackmagic/upgrade$


*********** DONE ******************

[iMo]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

[wnorcott]

And now you have the very cheap and STM32F103 pin compatible GD32VF103  RISC-V chip from China. Sure you'll need new firmware but the peripherals are mostly the same as far as I can see at this point but I'm not 100% familiar with it yet.

GD32VF103 Literature package: https://sourceforge.net/projects/mecrisp/files/Target%20literature%20package%20for%20GD32VF103.tar.gz/download

What I've done with it so far: https://mecrisp-stellaris-folkdoc.sourceforge.io/gd32vf103.html#gd32vf103-longan-nano

The GD32VF103CBF6  is completely different, totally different architecture than the STM32F103 or the similarly named GD32F103CBF6 .
   
The Sipeed Longan Nano board a GD32VF103CBF6 dev board, is available from SeedStudio for $4.90 apiece including a micro SD card reader and a color OLED display on the board and even a form fitted plastic case.

https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html

Despite the naming similarity, GD32VF103CBF6 RISC-V chip is 128KB Flash, 32KB SRAM  (not 20 KB) and runs at 108 MHz.    I am working with one of these feverishly now.  I have the Microsoft Visual Studio Code and PlatformIO and gcc entire toolchain installed and support for the Longan Nano board.  Also have Sigrok installed and running with a cheap Saleae clone.  Have a DS Logic on order. Running it on the Lenovo 14w laptop I just bought for $129, and running Manjaro Linux from a fast USB thumb drive. 

It is a bit of back and forth because I am working with a new laptop and a new operating system and having to install everything myself.

GD32VF103CBF6 is quite a learning curve but I think will be worth the time invested.   Despite 'pin compatibility' with STM32 the RISC-V chip is thoroughly modern chip one of the most modern on the market (< 6 month old?) and has the following:

two 12-bit ADCs with 16 channels each, two 12-bit DACs, 6 timers, three SPIs, two I2Cs, three USARTs, two UARTs, two I2Ss, two CANs, an USBFS, a CRC calculate unit. 

So far I got rudimentary understanding of  timers, interrupts and basic sleep mode somewhat figured out by reading the data sheet, searching for Github projects and judicious cut/paste code, reading RISC-V spec.  It's so new you really have to spend time just finding and gathering together the various guides online.   You burn firmware using the DFU interface that it understands, while the USB cable is connected to the PC.  There are also serial FTDI type programming option or through the JTAG port with a debugger, neither of which have I tried.   

Got it to sleep on timer and/or button press, interrupt routines on either, reads a bunch of H/W registers and displays on the OLED color display ever 3.5 seconds.  Reads and writes files to the SD card.   And of course does a blinky but it's an 8 colors blinking on one of the onboard LED, changes colors every 3.5 seconds when the timer fires.   Due to the sleep mode and the fact I can profile instruction counts, it is doing 771,000 instructions per second not 108 million, due to sleeping most of the time.  Have not measured current draw on the thing yet.

It uses a USB C connector but the way for power.

I have to the video working I got the SD card reader/writer working, got the H/W register code to fetch  the instructions executed count since startup (not sure if STM32 has this).   So it is pretty easy to compute actual instruction count for a loop or what have you.


I don't have the STM32 background myself and no MCU expert but bought several Blue Pill boards for $1.50 each on order to play with.  Going forward though my focus is on RISC-V and the Longan Nano board.

It is also available from Amazon Prime for less than $10.  I got one to start with and ordered another 10 from SeeedStudio to play with.

   One nice thing is you can program a Longan Nano board to be a debugger for other Longan Nano boards and just connect a ribbon cable to the already soldered JTAG headers.  That is kind of cool.  It also uses Altera USB Blaster or clones, or JLINK neither of which I have tried, and also an RV Link dedicated programmer from Seeed Studio I have one on order too just to keep handy that cost me $7.90.

[bingo600]

Just an info , not related to the RISC-V chip mentioned above , but the normal STM32 compatible GD32F103xxx

Remember the GD32F103C8F6  only have 64K as per the DS.
So some of the Code > 64K tricks that work on a "Normal" Bluepill wont work on a GD32 "Bluepill" unless it has a GD32F103CBF6 (128K) MCU on it

/Bingo

[bingo600]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

Technically the result is correct 
You have cheated and loaded 90K into an "official" 64K device , that gives ~ -24k

The Forth must be using the chip id (device) reported flash size , not the "nice gift from ST as in 2 x flash"

/Bingo

[iMo]

The Forth should return the correct results. Forth does not care about chip IDs..

[techman-001]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

Interesting!
What's the full chip part number and the board type etc ?

I used the STM datasheet specified location to obtain the Flash which on my Olimex P103 gives this result:

free (bytes)
FLASH.. TOTAL REPORTED: 131072 USED: 97028 FREE: 34044
RAM.... TOTAL PRESET: 20000 USED: 1456 FREE: 18544

This is correct for my chip, a STM32F103RBT6 so unless I have made a error somewhere, while it seems your chip does have 128KB Flash, it doesn't seem to be stating more than 64KB ?

30.1.1  Flash size register

        Base address: 0x1FFFF7E0
        Read only = 0xXXXX where X is factory-programmed

Bits 15:0 F_SIZE: Flash memory size

                This field value indicates the Flash memory size of the device in Kbytes.
                Example: 0x0080 = 128 Kbytes.

So all I do is read that register, mask out the upper 4  bytes and multiply by 1024 to get bytes:

$1FFFF7E0 @ $FFFF and 1024 * .    131072 ok.

What is the value you get now that you have a working Forth on that chip ?

[techman-001]

There is more to life than STM32F103's.

Could you build an stm32F103 (BP) image for 128kB of flash, plz?

Done: plz let me know if you have any issues.

Cool!
I get following (flashed in with st-link):

Code: [Select]

ramfree . 19112 ok.
flashfree . -24692 ok.
free  (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

ok.

here . 536871820 ok.I think there is an issue with the results..

Technically the result is correct 
You have cheated and loaded 90K into an "official" 64K device , that gives ~ -24k

The Forth must be using the chip id (device) reported flash size , not the "nice gift from ST as in 2 x flash"

/Bingo

That's correct, my Mecrisp-Stellaris Forth "free" word only reads the chip "Flash size register" according to the STM datasheet.

30.1.1  Flash size register
Base address: 0x1FFF F7E0
Read only = 0xXXXX where X is factory-programmed
This field value indicates the Flash memory size of the device in Kbytes.
Example: 0x0080 = 128 Kbytes.

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

[techman-001]

The Forth should return the correct results. Forth does not care about chip IDs..

Actually my "free" word *only* cares about the chip "Device electronic signature" and uses the "Flash size register" value to report the Flash Size.

People have asked me before "why not dynamically find the actual Flash value" and that's a good question.

1) STM already did that test and they have marked the Flash kB value in the chip "Flash size register".
2) To test the second 64 kB Flash I'd have to write it with a sequence of bit changes, but how many times do I do this, once, a hundred, a thousand times ?
3) It would fail the test if one bit failed to flash but even if it passed, it would only be at *your* local temperature and voltage and may fail at other temperatures etc.
4) Passing the test is no real guarantee it's all good.

Mecrisp-Stellaris Forth can do this as it can read and write Flash on the chip, from the chip.

Who wants a 64-128 kB Flash Test Word added to a bootable Bluepill usb image ?

[bingo600]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...


Don't test the flashsize by writing to it , you'll wear it out - It's a "Public Secret" that the STM32F103C8 has 2 x flash 
Do you use the Flash for Forth program storage (aka are you writing to flash) ?
If yes , you might want to change your Forth to 128K if it's a C8 (same size as CB) , especially if you would not write to a device with negative flash left

NOTE: ST could change the die to a 64K at anytime for the C8 wo. breking specs in the DS , but i doubt they would change such an OLD die now.

/Bingo

[iMo]

I've been using BluePill 103C8.
Now the key message is following: all STM32F103C8 chips have got 2x more flash as advertised.
ALL stm's C8 we ever seen on stm32duino forum (last 5y) have got 128kB (fully working).

PS: those are not "rejects" - STM does not produce 64kB chips anymore.. That is a common practice today.. That is applicable for larger STM chips as well (!).

Thus the 64kB C8 has got 128kB flash. Your 128kB forth works fine here it seems:

Code: [Select]

ok.
compiletoram ok.
init-bignum ok.
: myfac fac bu. cr ; ok.
50 myfac 30414093201713378043612608166064768844377641568960512000000000000
ok.
see fac
00016BDA: F847
00016BDC: 6D04  ldr r4 [ r0 #50 ]
00016BDE: 2601  movs r6 #1
00016BE0: B500  push { lr }
00016BE2: F7FF  bl  000163F2  --> s>b
00016BE4: FC06
00016BE6: CF08  ldmia r7 { r3 }
00016BE8: 1C5B  adds r3 r3 #1
00016BEA: F847
00016BEC: 6D04  ldr r4 [ r0 #50 ]
00016BEE: B430  push { r4  r5 }
00016BF0: 2401  movs r4 #1
00016BF2: 001D  lsls r5 r3 #0
00016BF4: CF40  ldmia r7 { r6 }
00016BF6: 42AC  cmp r4 r5
00016BF8: D00A  beq 00016C10
00016BFA: 0023  lsls r3 r4 #0
00016BFC: F847
00016BFE: 6D04  ldr r4 [ r0 #50 ]
00016C00: 461E  mov r6 r3
00016C02: F7FF  bl  000163F2  --> s>b
00016C04: FBF6
00016C06: F7FF  bl  00016AFA  --> bu*
00016C08: FF78
00016C0A: 3401  adds r4 #1
00016C0C: 42AC  cmp r4 r5
00016C0E: D1F4  bne 00016BFA
00016C10: BC30  pop { r4  r5 }
00016C12: BD00  pop { pc }

Bytes: 58 ok.

see myfac
20000398: B500  push { lr }
2000039A: F646  bl  1FE46554
2000039C: 30DB
2000039E: F2C0  bl  202C03A4
200003A0: 0001
200003A2: 4780  blx r0
200003A4: F646  bl  1FE463EE
200003A6: 7023
200003A8: F2C0  bl  202C03AE
200003AA: 0001
200003AC: 4780  blx r0
200003AE: F242  bl  20242410
200003B0: 602F
200003B2: 4780  blx r0
200003B4: BD00  pop { pc }

Bytes: 30 ok.
hex ok.
here . 200003B8 ok.
see see
000147D2: B500  push { lr }
000147D4: F7EE  bl  00002D20  --> '
000147D6: FAA4
000147D8: F644  bl  FFE587DC
000147DA: 7000
000147DC: F2C2  bl  002D67E0
000147DE: 0000
000147E0: 6306  str r6 [ r0 #30 ]
000147E2: 6B06  ldr r6 [ r0 #30 ]
000147E4: 6386  str r6 [ r0 #38 ]
000147E6: CF40  ldmia r7 { r6 }
000147E8: F7FF  bl  00014750  --> seec
000147EA: FFB2
000147EC: F7ED  bl  0000262E  --> cr
000147EE: FF1F
000147F0: F7ED  bl  000026FA  -->  .' Bytes: '
000147F2: FF83
000147F4: 4207
000147F6: 7479
000147F8: 7365
000147FA: 203A
000147FC: F644  bl  FFE58800
000147FE: 7000
00014800: F2C2  bl  002D6804
00014802: 0000
00014804: 6B43  ldr r3 [ r0 #34 ]
00014806: 6B82  ldr r2 [ r0 #38 ]
00014808: 1A9B  subs r3 r3 r2
0001480A: F847
0001480C: 6D04  ldr r4 [ r0 #50 ]
0001480E: 461E  mov r6 r3
00014810: F7EF  bl  0000437E  --> .
00014812: FDB5
00014814: BD00  pop { pc }

Bytes: 68 ok.
What is needed is to forget the chip's IDs and to set the proper flash sizes such it shows good numbers

[techman-001]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...

/Bingo

It's very curious, especially considering that STM themselves only use the STM32F103C8T6 in their Discovery Boards (SWD programmer section). I have a recent STM32L073 Nucleo here and it also uses a STM32F103C8T6 also.

While using the same die to save costs is a very logical and long used method, I can't help being suspicious of Chinese st-link clones in the same way I'm suspicious of Chinese "blue pills', namely their use of recycled e-waste as new parts.

[iMo]

Xilinx does the same with 20x more expensive chips..

[techman-001]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...


Don't test the flashsize by writing to it , you'll wear it out - It's a "Public Secret" that the STM32F103C8 has 2 x flash 
Do you use the Flash for Forth program storage (aka are you writing to flash) ?
If yes , you might want to change your Forth to 128K if it's a C8 (same size as CB) , especially if you would not write to a device with negative flash left

NOTE: ST could change the die to a 64K at anytime for the C8 wo. breking specs in the DS , but i doubt they would change such an OLD die now.

/Bingo

Then I must be the only one around with 12 bonafide STM32F103C8T6 units ?

This attempted flashing of my recent eb13e308316527be6a8963098c7291d5.bin (90240 bytes) results in the errors below. It flashes fine with a < 64KB binary.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
Warn : no flash bank found for address 8010000
wrote 65536 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 2.032206s (31.493 KiB/s)
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
diff 0 address 0x08010000. Was 0xff instead of 0x00
...

[techman-001]

Do you really think it's a gift ? Could it be that STM marked 64kB rather than 128kB on those chips because the second 64KB block failed their testing in some way that may not be apparent at room temperature etc  ?

Rumours are that ST uses the same die for several models (saves production $$) , and all C8's i've met has 128K flash.
The STM32F101 used today in most of the ST-Link alu-clones doesn't even have USB , according to the DS.
But the Clones work 

I don't think it's rejects , just a (CB die) that reports a (C8) ID ...


Don't test the flashsize by writing to it , you'll wear it out - It's a "Public Secret" that the STM32F103C8 has 2 x flash 
Do you use the Flash for Forth program storage (aka are you writing to flash) ?
If yes , you might want to change your Forth to 128K if it's a C8 (same size as CB) , especially if you would not write to a device with negative flash left

NOTE: ST could change the die to a 64K at anytime for the C8 wo. breking specs in the DS , but i doubt they would change such an OLD die now.

/Bingo

Then I must be the only one around with 12 bonafide STM32F103C8T6 units ?

This attempted flashing of my recent eb13e308316527be6a8963098c7291d5.bin (90240 bytes) results in the errors below. It flashes fine with a < 64KB binary.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
Warn : no flash bank found for address 8010000
wrote 65536 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 2.032206s (31.493 KiB/s)
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
diff 0 address 0x08010000. Was 0xff instead of 0x00
...

I wrote this up on my doc site for anyone interested to see the proofs:-

STM32F103C8T6, 2 x 64kB flash ? https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8t6-128kb.html#stm32f103c8t6-128kb

[bingo600]

Then I must be the only one around with 12 bonafide STM32F103C8T6 units ?

This attempted flashing of my recent eb13e308316527be6a8963098c7291d5.bin (90240 bytes) results in the errors below. It flashes fine with a < 64KB binary.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : flash size = 64kbytes
Warn : no flash bank found for address 8010000
wrote 65536 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 2.032206s (31.493 KiB/s)
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
diff 0 address 0x08010000. Was 0xff instead of 0x00
...

Could those be very old chips ?

As in before ST switched to "one die rules them all" 


WRT: Chip id for a 128K C8 , that programs ~90K wo. probs , you can see my BMP post here
https://www.eevblog.com/forum/microcontrollers/stm32-without-stm-libraries/msg2823454/#msg2823454

*** SNIP ***

blackmagic/src$ st-flash --flash=0x20000 write bmp-combined-dfu-bin.bin 0x8000000
st-flash 1.5.1-50-g3690de9
2019-12-10T19:49:45 INFO common.c: Loading device parameters....
2019-12-10T19:49:45 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-12-10T19:49:45 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Forcing flash size: --flash=0x00020000
2019-12-10T19:49:45 INFO common.c: Attempting to write 90196 (0x16054) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08016000 erased
2019-12-10T19:49:47 INFO common.c: Finished erasing 89 pages of 1024 (0x400) bytes
2019-12-10T19:49:47 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-12-10T19:49:47 INFO flash_loader.c: Successfully loaded flash loader in sram
 89/89 pages written
2019-12-10T19:49:53 INFO common.c: Starting verification of write complete
2019-12-10T19:49:54 INFO common.c: Flash written and verified! jolly good!


What IMHO was surprising for me , was that imo mentioned he used st-link for programming , if that also included using "st-link util" from ST.
Then even ST allows programming > 64K in a F103C8  , where i'd have expected ST programs to use same method as your forth .. And "barf"

/Bingo

Ps: The GD32F103C8F6 uses another flash implementation , and follows the DS, having "just" 64K

[bingo600]

I wrote this up on my doc site for anyone interested to see the proofs:-

STM32F103C8T6, 2 x 64kB flash ? https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8t6-128kb.html#stm32f103c8t6-128kb

Just reread your article above.

I think OOCD is playing nice as your Forth is , using the flashsize reported by the chip.
You prob need to "tame" OOCD, and not use the probed value.

/Bingo

[iMo]

GD32F103 is a flash-less chip. There is only sram on the their arm chip (64kB+20kB for C8).
They store the binary on an external standard 64kB 8pin SPI flash die, bonded on the flash-less arm die.
Thus there are 2 chips inside the package.
GD32 boots off the external flash into the sram upon reset, and executes the binary off the sram.
Most probably all GD32F and GD32V mcus work that way (GigaDevices company is the major serial flash memory manufacturer there).

FYI - an info from early 2016: https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices

PS: and yes, I flashed both 128kB mecrisp forth and 128kB BMP with stlink (the clone) via stm's stlink utility (win7 64b) into my 5y old BluePill (c8) with no problem.

PPS: based on an analysis done at stm32duino forum years back (I cannot find the thread today) the stm is producing only 128kB and 512kB F103 chips. Therefore 64kB and 128kB are all 128kB, and 256kB and 512kB are all 512kB (any package sizes).

[techman-001]

I wrote this up on my doc site for anyone interested to see the proofs:-

STM32F103C8T6, 2 x 64kB flash ? https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8t6-128kb.html#stm32f103c8t6-128kb

Just reread your article above.

I think OOCD is playing nice as your Forth is , using the flashsize reported by the chip.
You prob need to "tame" OOCD, and not use the probed value.

/Bingo

Bingo, one of my 12 STM32F103C8T6 boards with a reported 64kB Flash is now running a 90kB binary

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

Ok, I'm now officially convinced that the STM32F103C8T6 probably has a second 64kB laying around. I modified the OpenOCD config to ignore the reported Flash Size and the 90kB binary flashed no problem.

** Programming Started **
auto erase enabled
Info : device id = 0x20036410
Info : ignoring flash probed value, using configured bank size
Info : flash size = 128kbytes
wrote 91136 bytes from file ./eb13e308316527be6a8963098c7291d5.bin in 4.948380s (17.986 KiB/s)
** Programming Finished **
** Verify Started **
verified 90240 bytes in 1.311107s (67.214 KiB/s)
** Verified OK **
** Resetting Target **
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020 (STMicroelectronics), part: 0x6410, ver: 0x1)
shutdown command invoked

I think it's time to make a "64KB reported, second 64kB block found and tested" Forth Word I think.

Thanks, Bingo!

[bingo600]

Bingo, one of my 12 STM32F103C8T6 boards with a reported 64kB Flash is now running a 90kB binary

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

Ok, I'm now officially convinced that the STM32F103C8T6 probably has a second 64kB laying around. I modified the OpenOCD config to ignore the reported Flash Size and the 90kB binary flashed no problem.

Thanks, Bingo!

Remember to update your article 

Now you just got 12 more testboards 

Btw: I even think a (CB) image would run fine on a (C8) , was that what you tried ?

/Bingo
/Bingo

[bingo600]

PS: and yes, I flashed both 128kB mecrisp forth and 128kB BMP with stlink (the clone) via stm's stlink utility (win7 64b) into my 5y old BluePill (c8) with no problem.

Interesting that even ST is allowing st-util to program more than 64K on a C8 , might be a "good hint".
Did you have to override something ?? , or set an ignore error flag or

/Bingo

[techman-001]

Bingo, one of my 12 STM32F103C8T6 boards with a reported 64kB Flash is now running a 90kB binary

free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 90228 FREE: -24692
RAM.... TOTAL PRESET: 20000 USED: 888 FREE: 19112

Ok, I'm now officially convinced that the STM32F103C8T6 probably has a second 64kB laying around. I modified the OpenOCD config to ignore the reported Flash Size and the 90kB binary flashed no problem.

Thanks, Bingo!

Remember to update your article 

Now you just got 12 more testboards 

Btw: I even think a (CB) image would run fine on a (C8) , was that what you tried ?

/Bingo
/Bingo

"Remember to update your article " <--- Done !

I'm reflashing my other 11 boards right now. No problems so far.

I loaded a CB image which does have a compilation config informing Mecrisp-Stellaris Forth that 128kB of Flash is available so when Flash is low it can warn the user.

Other than that, the image is identical to a 64kB Mecrisp-Stellaris Forth which warns when Flash is low near 64kB usage.

Cheers!

[iMo]

PS: and yes, I flashed both 128kB mecrisp forth and 128kB BMP with stlink (the clone) via stm's stlink utility (win7 64b) into my 5y old BluePill (c8) with no problem.

Interesting that even ST is allowing st-util to program more than 64K on a C8 , might be a "good hint".
Did you have to override something ?? , or set an ignore error flag or

/Bingo

No.