HALMX :: MXBluePillF103C8 Roadmap

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:

HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Mon Apr 18, 2016 6:46 am

On March 2016 I started working on Sheepdoll's (Julie S. Porter) great work on HALMX core files. I focused on STM32F103C8 MCU because it's widely used by STM32Duino members. I think it is very hard for members to watch the whole forum posts and see what feature is added to the HALMX core.
I saw that Sheepdoll has a generic HALMX roadmap but the changes I have done so far are tested only MXBluePillF103C8 variant. Not to the entire HALMX variants. For that reason, I created this post that informs the members with the changes are made by me or any other member, to the MXBluePillF103C8 variant.



Things that work:

[14 May 2016]
* USBSerial. Added support to USB Virtual COM port.
* Bootloader. The Maple DFU firmware upload method is used to upload the compiled sketches to HALMX.

[09 May 2016]
* Added the interrupt based Serial transmission function on Serial1, 2 and 3 ports.

[19 April 2016]
* wiring_analog.c Support to AnalogRead() and AnalogWrite() functions

[14 April 2016]
* SPI library
* wiring.h The delayMicroseconds() was re-written for STM32. The previous assembly code wasn't work correct to the tests I had made.
* wiring_digital.c The LOW and HIGH were placed in reverse on digitalRead(...). Fixed!

[09 April 2016]
* Hardware Serial ports. Serial 1, Serial 2 and Serial 3 work in Interrupt mode.


Things to do:
* Wiring library. Support to I2C interface
* SPI library in DMA and Interrupt mode.
Last edited by Vassilis on Fri Jun 03, 2016 1:36 pm, edited 5 times in total.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Mon Apr 18, 2016 5:43 pm

The analogRead() and analogWrite() functions are ready. I will send the PR in 1-2 days.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by RogerClark » Mon Apr 18, 2016 10:27 pm

Thanks Vassilis

Sorry I dont have time to do much of this myself.

Im not sure if you did a pull from my repo into yours, as I updated some files to allow use with the bootloader.

Re:Bootloader for all STM32

I dont think we can write one bootloader that would work for all.

I am not sure if all STM32 devices have USB support ??

We could write a serial bootloader for those devices that only have serial, but I doubt there would be much point as I suspect those devices have a built in serial bootloader, or people would just use STLink.

The F4 has built in DFU, but I dont know if its possible to enter DFU bootloader mode from code, or whether it can only be accessed by Boot0 and Boot1.

Anyway I think that writing new bootloaders would be the last think to do.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Tue Apr 19, 2016 8:59 pm

I did a pull and I saw your files. Thanks!
On March I did some tests to combine the stm32duino bootloader with CubeMX. That was totally failure. I had changed the flash address from the *.ld file but ... nothing. The bootloader was partially worked. I had unpluged the blupill from the usp port. I pressed the upload button on arduino IDE and simultaneously I plugged in the bluepill to the usb port. With that trick the bluepill was programed successfully.
I am thinking right now one more test to do but it is too late for that now. I will try it tomorrow.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by RogerClark » Tue Apr 19, 2016 9:15 pm

Vassilis

The only way I could get the BluePill to work with the bootloader was to unplug it, and then plug it back in, just when dfu-util was searching for dfu devices.

The maple mini worked better, as I just press the reset button when dfu-util is searching.

I dont know why the reset button is not resetting the usb on the BluePill, but the problem may also be because of the Skylake chipset in my new PC, as it is not BluePill friendly and it does not work with the GD32 at all.


Some of the problem with the BluePill is that when the sketch runs, the Windows device manager still shows the DFU device, even though the dfu code is no longer running in the BluePill.

We could force USB enumeration when the sketch starts, but it would then show probably show an unknown device.

I think we need to find some small CDC code to provide USB Serial, as the STM code seems far to big.

Perhaps the libopencm3 code, as used by the BMP could be used to provide the USB.
The interesting thing about the BMP is that it has 3 devices at the same time, i.e. it behaves as a composite device. I think this is the way forward, as I know there is a lot of interest in USB midi and also USB HID ( mouse and keyboard)

If we start with a USB composite device, even with only 1 sub device, it would make it much easier to add additional devices.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by mrburnette » Wed Apr 20, 2016 12:34 pm

RogerClark wrote: <...>
The maple mini worked better, as I just press the reset button when dfu-util is searching.
<...>
Generally, my Maple Mini does reset over the comm on Linux Mint 17.3. There has been a few cases recently when I have had to do the unplug-replug procedure but that is on an old Dell (memory challenged) with 32-bit Mint and I cannot remember this happening on the Acer in the lab, a 64-bit Linux install. When using Windows 8.1 64-bit OS, I can remember a time or two of having to press Reset+DFU to lock the bootloader.

IMO there is just a lots of state changes in both the host computer and the maple mini and a reset failure and synchronizing DFU simply fails miserably. The bane of bootloaders.

Ray

User avatar
Slammer
Posts: 255
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Slammer » Mon Apr 25, 2016 9:11 am

I used CubeMX to add support for CDC serial device. I managed to get/put bytes to USB serial but, indeed, the code is much larger than libmaple.
Code raised to 17KB, and the BSS segment to 5KB!, for the typical blink program with some printing. The same code with libmaple is about 14.5KB/1KB.
While this size increase is not a problem for larger devices, is a serious drawback for the small.
I am examining the map file to see what is allocated and why. Maybe, we have to "touch" the MX generated code specially in small devices like "Pills".

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by RogerClark » Mon Apr 25, 2016 10:28 am

@slammer

I presume somehow the linker is linking functions that are not actually used.

We use the --whole-archive flag on libmaple, on the "archive" code, to ensure that things like the hardware timer ISR's get linked correctly.

I tried removing it from the HALMX core, but unfortunately it didnt seem to reduce the code size.
So either I modified the wrong code in platform.txt, or its not the --whole-archive flag that could be causing the large code.

The other thing that could be tried is somehow compiling the code from the Cube using just a makefile, and see if the CDC code is still too large.

I think @sheepdoll has been trying to compile using Eclipse on OSX, but I'm not sure if she was using an Arduino plugin, or just the files from the Cube.

User avatar
Slammer
Posts: 255
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Slammer » Mon Apr 25, 2016 10:39 am

I am building the code outside Arduino environment using makefile. Comparison is done using the same makefile and maybe the results are a bit different than Arduino's build system. I will play with cflags to see if there is change in size. I am pretty sure that some cleanup is needed specially in arduino core files as many functions are almost implemented in HAL.
The most important is that the code works! Nice job Vassilis and Sheepdoll!

Here is the size report of libcore.a (is the library of all sources):

Code: Select all

arm-none-eabi-size _build/g103c/libcore.a
   text	   data	    bss	    dec	    hex	filename
     49	      0	      0	     49	     31	dtostrf.o (ex _build/g103c/libcore.a)
    200	      0	      0	    200	     c8	itoa.o (ex _build/g103c/libcore.a)
     16	      0	      0	     16	     10	new.o (ex _build/g103c/libcore.a)
    904	      0	      0	    904	    388	Print.o (ex _build/g103c/libcore.a)
     56	      0	      0	     56	     38	RingBuffer.o (ex _build/g103c/libcore.a)
    891	      0	      0	    891	    37b	Stream.o (ex _build/g103c/libcore.a)
    292	      0	      4	    296	    128	syscalls.o (ex _build/g103c/libcore.a)
    594	      0	      2	    596	    254	UARTClass.o (ex _build/g103c/libcore.a)
     94	      0	      0	     94	     5e	USARTClass.o (ex _build/g103c/libcore.a)
      6	      	      0	      0	      6	      6			wiring.o (ex _build/g103c/libcore.a)
    132	      0	      0	    132	     84	wiring_digital.o (ex _build/g103c/libcore.a)
    144	      0	      0	    144	     90	wiring_shift.o (ex _build/g103c/libcore.a)
     78	      0	      0	     78	     4e	WMath.o (ex _build/g103c/libcore.a)
   1897	      0	      1	   1898	    76a	WString.o (ex _build/g103c/libcore.a)
    372	      0	      0	    372	    174	startup_stm32f103xb.o (ex _build/g103c/libcore.a)
    184	      4	      0	    188	     bc	system_stm32f1xx.o (ex _build/g103c/libcore.a)
    342	      0	      4	    346	    15a	stm32f1xx_hal.o (ex _build/g103c/libcore.a)
    518	      0	      0	    518	    206	stm32f1xx_hal_cortex.o (ex _build/g103c/libcore.a)
   1778	      0	      0	   1778	    6f2	stm32f1xx_hal_dma.o (ex _build/g103c/libcore.a)
    826	      0	      0	    826	    33a	stm32f1xx_hal_flash.o (ex _build/g103c/libcore.a)
   1136	      0	      0	   1136	    470	stm32f1xx_hal_flash_ex.o (ex _build/g103c/libcore.a)
    680	      0	      0	    680	    2a8	stm32f1xx_hal_gpio.o (ex _build/g103c/libcore.a)
   7434	      0	      0	   7434	   1d0a	stm32f1xx_hal_i2c.o (ex _build/g103c/libcore.a)
   2146	      0	      0	   2146	    862	stm32f1xx_hal_pcd.o (ex _build/g103c/libcore.a)
     50	      0	      0	     50	     32	stm32f1xx_hal_pcd_ex.o (ex _build/g103c/libcore.a)
    524	      0	      0	    524	    20c	stm32f1xx_hal_pwr.o (ex _build/g103c/libcore.a)
   2716	      0	      0	   2716	    a9c	stm32f1xx_hal_rcc.o (ex _build/g103c/libcore.a)
    606	      0	      0	    606	    25e	stm32f1xx_hal_rcc_ex.o (ex _build/g103c/libcore.a)
   4440	      0	      0	   4440	   1158	stm32f1xx_hal_spi.o (ex _build/g103c/libcore.a)
    128	      0	      1	    129	     81	stm32f1xx_hal_spi_ex.o (ex _build/g103c/libcore.a)
      0	      0	      0	      0	      0	stm32f1xx_hal_tim.o (ex _build/g103c/libcore.a)
      0	      0	      0	      0	      0	stm32f1xx_hal_tim_ex.o (ex _build/g103c/libcore.a)
   2590	      0	      0	   2590	    a1e	stm32f1xx_hal_uart.o (ex _build/g103c/libcore.a)
   2054	      0	      0	   2054	    806	stm32f1xx_ll_usb.o (ex _build/g103c/libcore.a)
    578	    272	      1	    851	    353	usbd_cdc.o (ex _build/g103c/libcore.a)
    664	      0	      0	    664	    298	usbd_core.o (ex _build/g103c/libcore.a)
    906	      0	      1	    907	    38b	usbd_ctlreq.o (ex _build/g103c/libcore.a)
    150	      0	      0	    150	     96	usbd_ioreq.o (ex _build/g103c/libcore.a)
    396	      0	      0	    396	    18c	_spi.o (ex _build/g103c/libcore.a)
    128	      0	      0	    128	     80	gpio.o (ex _build/g103c/libcore.a)
    184	      0	      0	    184	     b8	i2c.o (ex _build/g103c/libcore.a)
    200	      0	      0	    200	     c8	main.o (ex _build/g103c/libcore.a)
    116	      0	      0	    116	     74	stm32f1xx_hal_msp.o (ex _build/g103c/libcore.a)
     98	      0	      0	     98	     62	stm32f1xx_it.o (ex _build/g103c/libcore.a)
    360	      0	      0	    360	    168	usart.o (ex _build/g103c/libcore.a)
     56	      0	      0	     56	     38	usb_device.o (ex _build/g103c/libcore.a)
    124	     16	      0	    140	     8c	usbd_cdc_if.o (ex _build/g103c/libcore.a)
    588	      0	    544	   1132	    46c	usbd_conf.o (ex _build/g103c/libcore.a)
    243	     52	      0	    295	    127	usbd_desc.o (ex _build/g103c/libcore.a)
    448	      4	    624	   1076	    434	variant.o (ex _build/g103c/libcore.a)
It is strange how big is the hal_i2c code (almost 7.5K!!!), hal_spi (4.5K), and all parts of usb support
Last edited by Slammer on Mon Apr 25, 2016 11:04 am, edited 2 times in total.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by RogerClark » Mon Apr 25, 2016 10:49 am

Ummm

Perhaps there are some postings on STM's own forums about the code size when using the Cube.

Its strange that compiler must be linking so much code that is never being used.

Post Reply