STM32CubeMX :: STM32F030F4 support

Development of new Cores using the STMCubeMX and HAL
Post Reply
User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Thu Mar 31, 2016 2:09 pm

A few days ago I started playing with the STM32CubeMX and the the Sheepdoll's HALMX core files.
I liked the idea of creating a new arduino core for STM32 micros by using the STM32CubeMX that is currently active and is developed by ST.

-= STM32Cube FW_F0 V1.5.0 =-

I tried to build my own configuration files for supporting the 20-pin STM32F030F4 micro-controller I bought recently that has only 16kB flash and 4kB of RAM.
So far, I managed to use the Serial port at 9600 bps and the digital pins just for blinking a few leds.

Next step is to check the serial port baud rate because the baud rate doesn't change with Serial.begin(19200).
It is stuck to 9600 bps (the value I initially set to CubeMX configuration).

User avatar
mrburnette
Posts: 1827
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by mrburnette » Thu Mar 31, 2016 2:16 pm

I liked the idea of creating a new arduino core for STM32 micros by using the STM32CubeMX that is currently active and is developed by ST.
Me 2 :D

Keep up the effort... Serial is a big deal IMO.

Ray

User avatar
sheepdoll
Posts: 236
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by sheepdoll » Thu Mar 31, 2016 6:06 pm

Vassilis wrote:A few days ago I started playing with the STM32CubeMX and the the Sheepdoll's

So far, I managed to use the Serial port at 9600 bps and the digital pins just for blinking a few leds.

Next step is to check the serial port baud rate because the baud rate doesn't change with Serial.begin(19200).
It is stuck to 9600 bps (the value I initially set to CubeMX configuration).
Congratulations getting the basics to work.

As I have noted here, this "core" was more of a proof of concept than an actual working core.

The baud rate thing is a weakness to the CubeMX model. The code is generated by the tool and the HAL init is called before the setup() function. So serial.begin() inherits the baud rate from MX_USARTn_UART_Init() which is defined in usart.c where 'n' is the number that MX and the hardware defines for the port. The actual mapping between Serialn and USARTn is in the variant.c

Most of these files are created by the cubeMX tool. So far in my limited testing I have found that the user code in main() is preserved. This makes it pretty safe to run the MX tool to set things like baud rate.

My workflow then to change the baud rates is to re generate the code from CubeMX. This probably breaks the Arduino mindset. There might be a workaround which I have not tested, which would be to call the MX api for changing the baud rate directly in setup() before calling serial.begin() to set the baud rate using the HAL accessors to &huartn. These are actually the few lines of code that I have not been able to sit down and test with needing an uninterrupted window of 3 to 12 hours to do so.

The question is which is simpler. Use the graphical tool to set up the pins, Or to expose the pin numbers in the setup() section?

I chose the former, and placed the MXnnnn.ino file inside the git branch. This way one can check out the variant using git into a new branch and change the pin mapping. Downside is that each sketch or sketch family has it's own git branch to maintain. Upside is that if a mistake is made, there is the git history to recover from.

User avatar
RogerClark
Posts: 7146
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Thu Mar 31, 2016 9:07 pm

I may have got this wrong...

Buy you already have to modify main() to add the setup() and loop() calls,( as well as perhaps some other changes)

So what it sounds like would be needed is a more radical modification, to main() so that the serial init was not performed in main(), but in Serial.begin().


Vassilis... I presume you are uploading via STLINK or the hardware Serial bootloader, as the vector offset thing to allow the use of the bootloader, is also a problem with using the files from the Cube, as from what I recall, the offset value is set in a header, deep in the includes.

I briefly took a look at how to make the offset configurable at compile time, but I had to modify one of the Cube generated headers, and add an #ifdef, to a new preprocessor define, that could be added in as a compile time argument ( like is done in the maple core)

(btw. I still didnt get it working with the bootloader, but I was trying to walk before I could run, as I had not got the F103C to work with STLINK first)


IMHO. I think using the Cube to generate files, so we can use the HAL etc is an excellent idea, but I think we are likely to need to modify some of the files generated by the Cube, and not just main.c

So either we'd need a checklist of changes that people would need to perform when they used the Cube to generate a new core, or we'd need to have some clever automated system to patch the files generated by the Cube
(Im sure that this sort of patching has been done by other projects, but Im not sure what tools ( utilities ) would be needed

User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Fri Apr 01, 2016 4:16 pm

Vassilis... I presume you are uploading via STLINK or the hardware Serial bootloader, as the vector offset thing to allow the use of the bootloader, is also a problem with using the files from the Cube, as from what I recall, the offset value is set in a header, deep in the includes.
Yes. I use the STLINK. The vector offset is an issue to must be solved. The most problems have their solutions. Just we must find the easiest solution for that!
So either we'd need a checklist of changes that people would need to perform when they used the Cube to generate a new core, or we'd need to have some clever automated system to patch the files generated by the Cube

You are right about that. Instructions are easy to be written but often hard to be implemented. Some step will be forgotten.
On the other hand, an automated patch is easy to be executed it but very hard to be implemented (created).
I think that issue is a double-edged knife.

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: STM32CubeMX :: STM32F030F4 support

Post by stevech » Sat Apr 02, 2016 4:35 am

Vector table relocation... I wonder if this will help in your goal.
On an STM32F4 with 1MB flash, I wrote an "A/B" bootloader. At power up, the vectors in low memory run the code in low memory. I call that the B code. A and B each have their own vectors table and are thus independent of one another.

Normally, B quickly decides to run the A code which is in different sequential sectors of flash. The A code hums along until a user tells the A code to mark a flag in non-volatile memory that a the A code needs to be updated, then A reboots the MCU.

B runs again and sees the update-is-needed flag. B then gets a stream of data from a communications port that is the .hex or .bin for the new A code. B then streams it in, validates on the fly and writes a new version of A to where A lives. No SD memory - streams in directly to the B code which writes flash sectors with a new A. When B successfully gets all of A written, and validates an MD5 checksum for it, B then clears the update pending flag in flash and reboots itself. Now B runs the new A code.

The way I use this is that A and B are identical source code. The linker file for B puts everything based at address 0 in flash (which is actually at 0x08000000 in the MCU's address space but remapped by hardware. The linker file for B forces the vectors to be at 0x400 offset.
The linker file for A is the same but the base is set to 0x08080000 and the same 0x400 offset for the vectors. The vectors for A and B are in flash, not RAM (safer).

When B runs A it disables interrupts and remaps the vector table to A's place. So when A runs, that other vector table is used.
This is done with this code

Code: Select all

	extern uint32_t __vector_table; // linker generated. when 'B' runs 'A' must code as this..
	SCB->VTOR = (uint32_t)&__vector_table; // may be relocated due to linker file
	__enable_irq(); // may be off if launched by boot code
where __vector_table comes from the Linker script file.

To build A and B, I have two projects in one IDE workspace. Both use the same source code files. They differ only in the linker script file for A and B.
So I hit one key and both A and B are compiled to two .hex files. I flash the B file via SWD but that could be DFU or a serial/usb bootloarder.

Then reset the MCU and B runs. It supports a host PC protocol (any will do) so that a user can tell B to mark update for A as pending and kick off the process for B to install or update A.

In normal use, only new A files are distributed and put on a PC. The PC sends that A code to the MCU's B code via a comms link like UART or whatever. The B code gets updated only when essential.

This A/B scheme can work on any MCU that has room for B and A. B need not be identical to (and as large as) A, but in my case, it's easy, and the same host PC interface is in both A and B.

If comms with the PC are lost and B never finished the update of A, B runs and doesn't launch to A nor stick in a reflash state. The until comms com back, the MCU is running B which is an older version of the same app. This deals with, say, a cellular network link to the PC that is down.

If the new A is very faulty, its watchdog timer will force a reset which runs B. B sees the reset cause was watchdog timeout and starts an update of A process with the host PC providing a corrected version of A

This scheme also supports remote unattended updates- no one need be on site to push buttons or plug cables.

The 2MB flash ST's have an A/B scheme too, but it's better than what I have in that the remapping of vectors and the whole memory map is changed between two 1MB address ranges. It's for having a fall-back version. My scheme does the same fall-back but with software based A/B remapping on smaller MCU. My scheme will work on, say, a 32KB or 64KB flash MCU.

User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Wed Apr 06, 2016 3:03 pm

A few minutes ago I sent a pull request with the changes I did to the forked HALMX_Arduino_STM32.

1) I tried to make the Serial port work in Interrupt mode. I saw that only the Tx was implemented (not in interrupt mode). Now, both Tx and Rx pins work with interrupts. For that I have made some modifications to the files:
UARTClass.h , UARTClass.cpp, variant.h and variant.cpp

2) I also added the new board to the boards.txt file.
3) Added the Stream.cpp file to the Core folder (it was missing). Now the Serial.find(...) seems to work ok!

4) The Serial.begin( [baudrate] ) works now.

5) I created a batch file (FileRenamer.bat) for renaming the file extension startup_stm32f030x6.s in to startup_stm32f030x6.S
[it changes the s to S]



I have a small experience in HAL + Arduino SAM Core. I don't know if I modified the above libraries in a wrong way. I think the Sheepdoll could answer that.

I just try to help.

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: STM32CubeMX :: STM32F030F4 support

Post by stevech » Wed Apr 06, 2016 7:24 pm

I've been using ST's HAL for 1+ years now, daily. And CubeMX. Professional work.
These are great.

If I can help, happy to do so. My current project I/O is setup by the two tools above and includes

CubeMX for pin mapping and automatic code generation for all the I/O libraries and their init code. I needed to write no drivers.
CPU clocks and dividers
Timers - perioic interrupt and capture 3.5MHz period and DMA samples
UARTs (interrupt and DMA
Smartcard reader interface and ISO7816 on my side of the interface (M4)
SDIO (uSD card) with DMA, 25Mbps
SPI
RAMdisk using MCU flash
Bootloader/firmware updater (in-application)

SWD for debugging

User avatar
RogerClark
Posts: 7146
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Wed Apr 06, 2016 8:39 pm

Guys

I'm happy to accept the PR, but if possible can @sheepdoll and anyone else take a look, as I dont have any experience of the HAL either ;-)

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: STM32CubeMX :: STM32F030F4 support

Post by stevech » Wed Apr 06, 2016 9:31 pm

all righty, then.

Post Reply