STM32F103RET6 #556

enesbcs · 2019-07-02T18:52:05Z

Board description:

Name: STM32F103RET6 "Blue button" Development board
Link to all relevant information:
- Documentations: https://github.com/mcauser/BLUE_BUTTON_F103RET6/
- Where this hardware can be purchased: https://www.aliexpress.com/item/32787019266.html

"STM32F103xE" define can be found in some places in the Arduino_Core_STM32 but currently there are no board definitions for it.

BennehBoy · 2019-07-02T20:38:44Z

It should be fairly simple to add this by following the guide -> https://github.com/stm32duino/wiki/wiki/Add-a-new-variant-(board)

Best for someone who has the board to do it for ease of testing...

enesbcs · 2019-07-06T20:46:11Z

I am afraid we have completely different idea of what it means to be "simple". :) I doubt that i will be the "someone", it is way beyond my hardware knowledge, sorry.

cdrose · 2019-07-13T01:30:40Z

I need to do a board definition for a 103ZET6 at some point too, I will eventually get round to it but if someone has time to look at the RET6, I would expect the ZET6 to be very similar too (hint hint ;-))

pkourany · 2019-07-25T01:07:41Z

I have started work on a 103RCT6 variant but need to figure out the pin mappings for the variant.x files. The only difference with the RET6 is the flash size. Hopefully I can finish it in the next week or so if that helps any.

pkourany · 2019-08-06T12:59:11Z

I believe I have the 103RCT6 variant working. My board has no need for Arduino pins as nothing is broken out. The Blue Button board has almost everything broken out. This simply affects the way Arduino pin designations are allocated in variant.c and variant.h. Does anyone care about a specific allocation or I'll simply define them based on left/righ headers and a zig-zag numbering scheme?

enesbcs · 2019-08-06T15:52:26Z

I am currently using Roger Clark's Core which simply numbers sequentially the pins from PA0=0,PA1=1 .. PD2=50
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/variants/generic_stm32f103r/board/board.h
But as you wish. :)

pkourany · 2019-08-06T16:27:49Z

Yup, that's what I did for my board. I'll start work in the STM32F103RET6 variant with that approach.

pkourany · 2019-08-07T13:55:22Z

Ok, I believe this RET6 variant is good. I have attached a zip of the variant folder. Do not rename this folder. The following needs to be added to the boards.txt file under the Generic F1 section of the file:

# BLUEBUTTON_F103RET6 board
GenF1.menu.pnum.BLUEBUTTON_F103RET6=Blue Button F103RET6
GenF1.menu.pnum.BLUEBUTTON_F103RET6.upload.maximum_size=524288
GenF1.menu.pnum.BLUEBUTTON_F103RET6.upload.maximum_data_size=65536
GenF1.menu.pnum.BLUEBUTTON_F103RET6.build.board=NUCLEO_F103RB
GenF1.menu.pnum.BLUEBUTTON_F103RET6.build.product_line=STM32F103xE
GenF1.menu.pnum.BLUEBUTTON_F103RET6.build.variant=BLUEBUTTON_F103RET6

BLUEBUTTON_F103RET6.zip

Let me know how it goes!

enesbcs · 2019-08-07T17:16:48Z

Thanks, but when i tried to compile the Blink sample i got the following error:

/home/enes/.arduino15/packages/STM32/hardware/stm32/1.6.1/cores/arduino/stm32/timer.c: In function 'TIM8_UP_IRQHandler':
/home/enes/.arduino15/packages/STM32/hardware/stm32/1.6.1/cores/arduino/stm32/timer.c:1328:21: error: 'TIMER13_INDEX' undeclared (first use in this function); did you mean 'TIMER3_INDEX'?
   if (timer_handles[TIMER13_INDEX] != NULL) {
                     ^~~~~~~~~~~~~
                     TIMER3_INDEX

pkourany · 2019-08-07T17:31:14Z

Yup. There is a bug in one of the Core files. See this issue #585 for the fix.

enesbcs · 2019-08-07T21:22:48Z

OK, now the Blink example compiles without error.
But after i've uploaded the sketch to the device through Maple DFU Bootloader 2.0, neither the LED blinking starts, nor the DFU port appears. I guess i have to reupload the bootloader to it with a serial bootloader again.

pkourany · 2019-08-07T22:35:14Z

I don't use a bootloader so that's as far as I can help.

enesbcs · 2019-08-15T17:38:37Z

I've uploaded the compiled Blink sketch and uploaded directly to F103RET6 through serial, but it did not do anything: blinking do not start and there are no data coming from serial... this is the most basic sketch i know, do you have any suggestions for testing?
(I've compiled the same sketch with Roger Clark's core and the same sketch works on the same device through serial upload.)

pkourany · 2019-08-15T18:29:47Z

Did you make sure to assign the correct pin for the built-in LED in the varian.h file?

enesbcs · 2019-08-15T19:06:56Z

Honestly i never use built in LED definition, i know that my LED is located on PB11 so i am using this:

void setup() {
  Serial.begin(115200);
  pinMode(PB11, OUTPUT);
  Serial.print(F("\nSetup"));
}

void loop() {
  Serial.print(F("\nLoop"));
  digitalWrite(PB11, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(PB11, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
}

This code is working on the other core, led is blinking and "Loop" string arrives from serial, but on this official core, there are nothing happens after uploading&restart. I thought that at least the serial comm has to be working, but nope.

fpistm · 2019-08-19T13:59:55Z

OK, now the Blink example compiles without error.
But after i've uploaded the sketch to the device through Maple DFU Bootloader 2.0, neither the LED blinking starts, nor the DFU port appears. I guess i have to reupload the bootloader to it with a serial bootloader again.

I did not checked the variant provided by @pkourany but if the ldscript does not take in account the BL_SIZE then after a flash the bootloader is simply overwritten as it is wrote @0x8000000

pkourany · 2019-08-19T14:32:04Z

@fpistm, that is most likely the cause as I am not using a bootloader in my scenario.

fpistm · 2019-08-19T14:47:06Z

That's why the ldscript is preprocessed then this is automatically handled.

Arduino_Core_STM32/variants/PILL_F103XX/ldscript.ld

Line 55 in 6d9575e

_estack = 0x20000000 + LD_MAX_DATA_SIZE; /* end of RAM */

Arduino_Core_STM32/variants/PILL_F103XX/ldscript.ld

Lines 63 to 64 in 6d9575e

    
           RAM (xrw)      : ORIGIN = 0x20000000, LENGTH = LD_MAX_DATA_SIZE 
        
           FLASH (rx)      : ORIGIN = 0x8000000 + LD_FLASH_OFFSET, LENGTH = LD_MAX_SIZE - LD_FLASH_OFFSET

In platform.txt:
-Wl,--defsym=LD_FLASH_OFFSET={build.flash_offset} -Wl,--defsym=LD_MAX_SIZE={upload.maximum_size} -Wl,--defsym=LD_MAX_DATA_SIZE={upload.maximum_data_size}

Depending of the upload method the proper definitions are used:

Arduino_Core_STM32/boards.txt

Lines 779 to 780 in 6d9575e

    
           GenF1.menu.upload_method.dfu2Method.build.flash_offset=0x2000 
        
           GenF1.menu.upload_method.dfu2Method.build.bootloader_flags=-DBL_LEGACY_LEAF -DVECT_TAB_OFFSET={build.flash_offset}

fpistm · 2019-08-20T07:38:13Z

Could you provide a PR for this then I could review it/help.

fpistm · 2019-08-26T12:36:28Z

@pkourany, any update for this issue?

Note link that could be used to reference it in the README.md thanks @ThomasGravekamp work.
https://stm32-base.org/boards/STM32F103RET6-Generic-Board

pkourany · 2019-08-26T18:13:07Z

@fpistm are you looking to me to do the PR as I had not planned to do so?

fpistm · 2019-08-26T18:16:54Z

@fpistm are you looking to me to do the PR as I had not planned to do so?

In fact I thought you will provide it, as I understood you've made the variant ❓

pkourany · 2019-08-26T18:27:10Z

@fpistm, I did provide it (see earlier post attachment BLUEBUTTON_F103RET6.zip) but it seems it did not perfectly suit the OP's requirements. I am not sure what the final ldscript.ld and board.txt files look like since the OP has not provided feedback on your latest recommendations. I can do a PR once he does.

enesbcs · 2019-08-26T19:36:58Z

what recommandations?
i doubt that the provided bootloader fix will solve my issue as i wrote previously, i've tried to upload with nature serial (without bootloader), and i am unable to get any proof that the sketch is running - neither LED activity nor serial communications.

uzi18 · 2019-08-26T19:44:36Z

@fpistm maybe it is a good time to provide some generic mcu variants, with more menu options like for esp8266 etc. , it will resolve lots of issues

fpistm · 2019-08-26T19:52:54Z

@fpistm maybe it is a good time to provide some generic mcu variants, with more menu options like for esp8266 etc. , it will resolve lots of issues

any PR's are welcome 😄

Four variants available: * STM32F103R8T6 * STM32F103RBT6 * STM32F103RCT6 * STM32F103RET6 Fixes stm32duino#556 Co-authored-by: Paul Kourany <[email protected]> Signed-off-by: Frederic Pillon <[email protected]>

fpistm · 2019-08-28T09:56:29Z

I've made a PR based on @pkourany variant.
I've fixed some issues and provided 4 boards support:

STM32F103R8T6
STM32F103RBT6
STM32F103RCT6
STM32F103RET6

enesbcs · 2019-08-28T16:48:13Z

Thank you I've made some tests, it looks like almost perfect, only the HID upload method is failing.
Blink sketch with

Serial upload: Upload OK, after restart Serial print works, LED blinking OK
HID 2.2.1 upload: Upload OK, after restart nor serial, neither blinking works
DFU 2.0 upload: Upload OK, after restart Serial print works, LED blinking OK

fpistm · 2019-08-28T17:56:11Z

@enesbcs thanks for the test.

HID 2.2.1 upload: Upload OK, after restart nor serial, neither blinking works

The bootloader is for a C8 or CB so this is normal, I guess. @Serasidis do you confirm?

Serasidis · 2019-08-29T17:10:10Z

* HID 2.2.1 upload: Upload OK, after restart nor serial, neither blinking works

Burn again the HID bootloader and then, select from Arduino IDE:
Tools > USB Support (if available) > CDC (generic 'Serial' supersede U(S)ART)

Upload your Blink sketch through HID Bootloader 2.2

I did a successful test on my STM32F103RBT6 by using the hid_generic_pc13.bin file
https://github.com/Serasidis/STM32_HID_Bootloader/releases/download/2.2.1/stm32_binaries.zip

fpistm · 2019-08-29T17:38:31Z

Thanks @Serasidis

Serasidis · 2019-08-29T19:13:55Z

After a second glance, I noticed that @enesbcs uses the F103RET MCU that is a high density device.
The F103RET has 2k flash sectors instead of 1k flash sectors that have the F103C8T6 and F103RBT6
That means that the high density F103 devices need different handling during programming.

I will fix that

Four variants available: * STM32F103R8T6 * STM32F103RBT6 * STM32F103RCT6 * STM32F103RET6 Fixes #556 Co-authored-by: Paul Kourany <[email protected]> Signed-off-by: Frederic Pillon <[email protected]>

Serasidis · 2019-08-30T08:56:17Z

@enesbcs Could you please test this bootloader file ?

hid_bootloader_f103rct.zip

Serasidis · 2019-08-30T13:33:19Z

STM32 HID Bootloader v2.2.2 (Support for High Density F103 Devices)
Serasidis/STM32_HID_Bootloader@161fb7d#diff-04c6e90faac2675aa89e2176d2eec7d8

enesbcs · 2019-08-30T15:12:34Z

@enesbcs Could you please test this bootloader file ?

Sure, i will try it tonight.

enesbcs · 2019-08-30T19:20:34Z

Thank you @Serasidis it works flawlessly! All RET owner owe you a coffee! :)
Thanks also to @pkourany and @fpistm for expanding the core with new board support!

enesbcs added the new variant Add support of new bard label Jul 2, 2019

fpistm added help wanted 🙏 Extra attention is needed Request labels Jul 24, 2019

fpistm added the on going Currently work on this label Aug 28, 2019

fpistm mentioned this issue Aug 28, 2019

Add Generic STM32F103Rx boards #615

Merged

fpistm closed this as completed in #615 Aug 30, 2019

fpistm removed the on going Currently work on this label Aug 30, 2019

fpistm added this to the 1.7.0 milestone Aug 30, 2019

fpistm added enhancement New feature or request and removed Request labels Jul 16, 2024

STM32F103RET6 #556

STM32F103RET6 #556

Comments

enesbcs commented Jul 2, 2019

BennehBoy commented Jul 2, 2019

enesbcs commented Jul 6, 2019

cdrose commented Jul 13, 2019

pkourany commented Jul 25, 2019

pkourany commented Aug 6, 2019

enesbcs commented Aug 6, 2019

pkourany commented Aug 6, 2019

pkourany commented Aug 7, 2019 • edited Loading

enesbcs commented Aug 7, 2019

pkourany commented Aug 7, 2019

enesbcs commented Aug 7, 2019

pkourany commented Aug 7, 2019

enesbcs commented Aug 15, 2019

pkourany commented Aug 15, 2019

enesbcs commented Aug 15, 2019 • edited Loading

fpistm commented Aug 19, 2019 • edited Loading

pkourany commented Aug 19, 2019

fpistm commented Aug 19, 2019

fpistm commented Aug 20, 2019

fpistm commented Aug 26, 2019

pkourany commented Aug 26, 2019

fpistm commented Aug 26, 2019

pkourany commented Aug 26, 2019

enesbcs commented Aug 26, 2019 • edited Loading

uzi18 commented Aug 26, 2019

fpistm commented Aug 26, 2019

fpistm commented Aug 28, 2019 • edited Loading

enesbcs commented Aug 28, 2019

fpistm commented Aug 28, 2019

Serasidis commented Aug 29, 2019 • edited Loading

fpistm commented Aug 29, 2019

Serasidis commented Aug 29, 2019 • edited Loading

Serasidis commented Aug 30, 2019

Serasidis commented Aug 30, 2019

enesbcs commented Aug 30, 2019 • edited Loading

enesbcs commented Aug 30, 2019

pkourany commented Aug 7, 2019 •

edited

Loading

enesbcs commented Aug 15, 2019 •

edited

Loading

fpistm commented Aug 19, 2019 •

edited

Loading

enesbcs commented Aug 26, 2019 •

edited

Loading

fpistm commented Aug 28, 2019 •

edited

Loading

Serasidis commented Aug 29, 2019 •

edited

Loading

Serasidis commented Aug 29, 2019 •

edited

Loading

enesbcs commented Aug 30, 2019 •

edited

Loading