Hardware serial 4 on STMF103RE about arduino_stm32 HOT 66 CLOSED

Should work, but has not been tested.

What board do you have?

The Maple RET6 official board type was not included in the list of boards as no one seems to have one.

However I used the old Maple RET6 files from the original maple IDE to make the generic STM32F103RE board type.

But its not been fully tested, as I seem to be the only person using that board type, and I'm using a generic STM32F103RC board not and RE board ( they are very similar processors, its just the RC has less Flash etc)

Please note Serial mapping depends on whether you are using the Maple bootloader. If you are using a board with the bootloader, "Serial" is USB Serial, Serial1 is HW serial 1
Otherwise "Serial" is HW serial 1, "Serial1" is HW serial 2 etc

If not all 4 hardware serials are functioning, it should be easy to fix, as its likely to be an issue with the one if the setup files like board.cpp or board.h in the variant folder

from arduino_stm32.

Hi, I am using a custom board based on the Maple RET6, I am also using the maple bootloader, I'll take a look at those files. If I try to compile using STM32F103RE option it comes back with an error even with Serial3.

from arduino_stm32.

I can see under board.h

/* Note: UART4 and UART5 have pins which aren't broken out :( */
#define BOARD_NR_USARTS 3
#define BOARD_USART1_TX_PIN PA9
#define BOARD_USART1_RX_PIN PA10
#define BOARD_USART2_TX_PIN PA2
#define BOARD_USART2_RX_PIN PA3
#define BOARD_USART3_TX_PIN PB10
#define BOARD_USART3_RX_PIN PB11

USART 4 is not defined, but this doesnt explain the error with Serial3? but compiling with Serial2 works.

Does compiling with the Generic STMF103RE support DFU mode(as the Maple boards do)?

Thanks,
Sky

from arduino_stm32.

@skyng22003

The MapleRET6 board didn't have those pins broken out to the pin headers, so it looks like when I copied the files I didn't spot this and add the definitions in for those USARTS

Does compiling with the Generic STMF103RE support DFU mode(as the Maple boards do)?
No. It only has setup for non-bootloader.

The only generic board that has menus to select bootloader or nonbootloader is the ST32F103C series.
I was actually contemplating removing bootloader support from that as well, as most people find it too complicated.
The problem is that the repo has 2 audiences. Some people are just migrating from a UNO and expect everything to work just the same and don't want complicated menus.
Other people use custom boards and need all the config

As you have a custom board, ie its not an official Maple or a Maple clone, or a generic board you can buy off the shelf, you will need to make your own board variant to support your board.

I'll add the missing definitions to the Generic STM32F103RE board (in fact I need to add the sub types of RB, RC, and RE to the F103R boards, like I did with the F103Z series - but as no one else seemed to be using these boards, it wasnt my top priority)

You'll also need to look at the linker scripts for the F103C board, specifically the mem-flash.inc file which specifies the start location

MEMORY
{
  ram (rwx) : ORIGIN = 0x20000C00, LENGTH = 17K
  rom (rx)  : ORIGIN = 0x08005000, LENGTH = 108K
}

I'm not sure why the ram offset is C00 for the bootloader version, where as its 0x00 on non-bootloader.
Flash offset makes sense, as the bootloader is a little under 0x5000 long.

obviously your LENGTH values will be different

Probably the best thing you could do is to get hold of the old Maple Windows IDE and look in the Maple RET6 files, because they should have the correct linker settings, however in terms of board.cpp and board.h, you'd probably be better of taking my new STM32F103Z series files, as those are the cleanest copy at the moment (as I did them last)

BTW. You may want to look at this other repo https://github.com/avikde/koduino which is also STM32 for Arduino, but I don't think he is focused on boards using the Maple bootloader and currently I don't think he has support for F103 boards

from arduino_stm32.

Update.

It looks like there are some other issues with adding USART4 and USART5.

Currently there appear to be definitions missing somewhere else in the code.

I'm currently tracking them down, so if you wait, I'll upload something later which at least compiles on RE and has 5 USARTS, however I dont have time to add in the feature of a Maple RET6 using bootloader at the moment

Edit.

There is a typo in one of the original libmaple files

struct usart_dev;
extern struct usart_dev *USART1;
extern struct usart_dev *USART2;
extern struct usart_dev *USART3;
#ifdef STM32_HIGH_DENSITY
extern struct usart_dev *UART4;
extern struct usart_dev *UART5;
#endif

well kinda of.

They are called UART as they are UARTS not USARTS but there is a macro elsewhere that assumes they are USARTS

I'm not sure how much hassle it will be to change the macro

It may be easier just to changer them all to USART

I'll get back to you on this one ;-)

from arduino_stm32.

Sorry to bug you again, I've found that the code and the upload works fine by configuring the hardware as LeafLabs Maple Rev3+ isn't it easier just to modify this for the RET6?

Technically my board is an identical copy of the Maple RET6 so I'm happy to help to get this to work so everyone can also use it.

I just need to know what needs to be done?

Thanks again!

from arduino_stm32.

Just looked at the original maple RET6 linker looks like this

MEMORY
{
ram (rwx) : ORIGIN = 0x20000C00, LENGTH = 61K
rom (rx) : ORIGIN = 0x08005000, LENGTH = 492K
}

from arduino_stm32.

I think you'd need to change some other things as well.

in Boards.txt it there is a define for the board as STM32F103RB

maple.build.extra_flags=-DMCU_STM32F103RB -mthumb  -DBOOTLOADER_maple -march=armv7-m  -D__STM32F1__ 

You'd need to change that to

maple.build.extra_flags=-DMCU_STM32F103RE -mthumb  -DBOOTLOADER_maple -march=armv7-m  -D__STM32F1__ 

As that definition is used internally by an ifdef to configure lots of things

You'd also need to change the stuff in boards.cpp and boards.h specifically the PIN MAP in board.cpp and also the enum that defines the pin names in board.h

The RET board is probably closer to the ZET board than it is to the RB,

I'd so a mashup of the ZET stuff and the Maple Rev 3

I'll take a look at the UART issue in a minute and try to work out the best solution.

My concern is whether the actual hardware control of UART 4 and 5 differs from the USARTS e.g. Universal Synchronous Asynchronous vs Universal Asynchronous

i.e if the register map is different there will need to be a lot more code changes, however the easiest thing is probably for me to just fix the Macro or rename USART1 2 and 3 to UART 1 2 and 3 and change the macro, but I don't like writing messy code.
It always comes back to bite you later ;-)

from arduino_stm32.

I've referenced the original maple boards.txt does this make sense?

By ZET you mean f103zxx?

##############################################################
maple.name=LeafLabs Maple RET6 to Flash

maple.upload.tool=maple_upload
maple.upload.protocol=maple_dfu
maple.upload.maximum_size=492000
maple.upload.use_1200bps_touch=false
maple.upload.file_type=bin
maple.upload.ram.maximum_size=61000
maple.upload.flash.maximum_size=492000
maple.upload.usbID=1EAF:0003
maple.upload.altID=1
maple.upload.auto_reset=true

maple.build.mcu=cortex-m3
maple.build.f_cpu=72000000L
maple.build.board=MAPLE_REV3
maple.build.core=maple
maple.build.extra_flags=-DMCU_STM32F103RE -mthumb -DBOOTLOADER_maple -march=armv7-m -D__STM32F1__
maple.build.ldscript=ld/flash.ld
maple.build.variant=maple
maple.build.variant_system_lib=libmaple.a
maple.build.vect=VECT_TAB_FLASH
maple.build.density=STM32_HIGH_DENSITY
maple.build.error_led_port=GPIOA
maple.build.error_led_pin=5
maple.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1

from arduino_stm32.

ZET I mean STM32F103Z series including ZC,ZD and ZE (selectable on sub menu)

Re: Boards.txt

It looks about right

You could just duplicate it, and add a new board e.g. see below

##############################################################
mapleRET6.name=LeafLabs Maple RET6 to Flash

mapleRET6.upload.tool=maple_upload
mapleRET6.upload.protocol=maple_dfu
mapleRET6.upload.maximum_size=492000
mapleRET6.upload.use_1200bps_touch=false
mapleRET6.upload.file_type=bin
mapleRET6.upload.ram.maximum_size=61000
mapleRET6.upload.flash.maximum_size=492000
mapleRET6.upload.usbID=1EAF:0003
mapleRET6.upload.altID=1
mapleRET6.upload.auto_reset=true

mapleRET6.build.mcu=cortex-m3
mapleRET6.build.f_cpu=72000000L
mapleRET6.build.board=MAPLE_REV3
mapleRET6.build.core=mapleRET6
mapleRET6.build.extra_flags=-DMCU_STM32F103RE -mthumb -DBOOTLOADER_maple -march=armv7-m -D__STM32F1__

mapleRET6.build.ldscript=ld/flashRET6.ld
mapleRET6.build.variant=maple
mapleRET6.build.variant_system_lib=libmapleRET6.a
mapleRET6.build.vect=VECT_TAB_FLASH
mapleRET6.build.density=STM32_HIGH_DENSITY
mapleRET6.build.error_led_port=GPIOA
mapleRET6.build.error_led_pin=5
mapleRET6.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1

Ah hang on.

flash.ld is no good

you will need to make a new flash.ld

flashRET6.ld and reference it from your board file

don't bother with including mem-flash, just copy the memory block into the flash in place of the include line

INCLUDE mem-flash.inc

MEMORY
{
ram (rwx) : ORIGIN = 0x20000C00, LENGTH = 61K
rom (rx) : ORIGIN = 0x08005000, LENGTH = 492K
}

Edit. I just changed the boards stuff a few times, you may need to grab it again

from arduino_stm32.

Edit. I just spotted a typo in USART5 RX pin.

It has now been fixed,

Pull the repo again

from arduino_stm32.

Oops

Mistakes in my boards config. Hang on I'll push a fix in a minute

from arduino_stm32.

OK

Do a pull now. I've added a MapleRET 6 board to the repo, using you memory definition etc

However I can't test it as I don't have that board

Let me know if it works

PS. know we should do this via a branch, but its a fairly simple change so lets hope it works first time ;-)

from arduino_stm32.

So i've modded the ZET board files now looks like this

do I need to change the BOARD GENERIC STM32F103Z_H?

#ifndef BOARDS_GENERIC_STM32F103Z_H
#define BOARDS_GENERIC_STM32F103Z_H

/* A few of these values will seem strange given that it's a

• high-density board. */

#define CYCLES_PER_MICROSECOND 72
#define SYSTICK_RELOAD_VAL 71999 /* takes a cycle to reload */

#define BOARD_BUTTON_PIN 38
#define BOARD_LED_PIN 13

/* Note: UART4 and UART5 have pins which aren't broken out :( */
#define BOARD_NR_USARTS 5
#define BOARD_USART1_TX_PIN PA9
#define BOARD_USART1_RX_PIN PA10
#define BOARD_USART2_TX_PIN PA2
#define BOARD_USART2_RX_PIN PA3
#define BOARD_USART3_TX_PIN PB10
#define BOARD_USART3_RX_PIN PB11
#define BOARD_USART4_TX_PIN PC10
#define BOARD_USART4_RX_PIN PC11
#define BOARD_USART5_TX_PIN PC12
#define BOARD_USART5_RX_PIN PD2

from arduino_stm32.

Great thanks, I'll test it now

from arduino_stm32.

Hi just tested, STMF103RE compiles fine with Serial4 but Maple RET6 does not compile maybe typo?

from arduino_stm32.

OK
Looks like its missing something

probably BOARD_HAVE_UART4

in boards.h

#define BOARD_HAVE_USART(n) (defined(BOARD_USART##n##_TX_PIN) && \
                             defined(BOARD_USART##n##_RX_PIN))
/** Feature test: nonzero iff the board has USART1. */
#define BOARD_HAVE_USART1               BOARD_HAVE_USART(1)
/** Feature test: nonzero iff the board has USART2, 0 otherwise. */
#define BOARD_HAVE_USART2               BOARD_HAVE_USART(2)
/** Feature test: nonzero iff the board has USART3, 0 otherwise. */
#define BOARD_HAVE_USART3               BOARD_HAVE_USART(3)
/** Feature test: nonzero iff the board has UART4, 0 otherwise. */
#define BOARD_HAVE_UART4                BOARD_HAVE_USART(4)

You are right, its possibly a typo related to the UART / USART thing

It looks like leaflabs never tested any of the Serial stuff for UART 4 and 5 as none of their boards had those connections

from arduino_stm32.

I know why this is occurring

Its missing the definitions from the Maple variant, I only added them to the generic board

The problem is that you will need to add more pins to the PIN MAP

Probably best to duplicate the whole maple variant folder and make a mapleRET6 variant

Then look at the PINMAP in board.cpp and the enum in board.h and add those extra pins

Note unfortunately the Maple pin numbers are the pins on their hardware and not the real STM port and pin numbers that I used on the R and Z series boards.

It may be easier if you duplicate the generic STM32F103rxx board variant folder, and raname it, and change the flash.ld file to be the flashRet6 file, and change the board.variant in the boards.txt file

Sorry, I doni't have time to do this for you now, as I need to get on with my day job ;-(

from arduino_stm32.

No problem, thanks for your help, I'll give it a go ^^

from arduino_stm32.

@skyng22003

BTW,. What hardware do you use to reset the USB ? Are you using 2 transistors like the maple mini or just one transistor.
I have seen designs that use a P channel (FET) and i was going to attempt to modify one of my boards to add this to a generic STM32F103ZET board, but have not got around to it.

from arduino_stm32.

I had a go, so I duplicated the STM32F103rxx folder and renamed it maple_ret6 and added flashRET6.ld and modified the boards.txt to (see below) but it still no compile with serial 4

##############################################################
mapleRET6.name=LeafLabs Maple RET6 to Flash

mapleRET6.upload.tool=maple_upload
mapleRET6.upload.protocol=maple_dfu
mapleRET6.upload.maximum_size=492000
mapleRET6.upload.use_1200bps_touch=false
mapleRET6.upload.file_type=bin
mapleRET6.upload.ram.maximum_size=61000
mapleRET6.upload.flash.maximum_size=492000
mapleRET6.upload.usbID=1EAF:0003
mapleRET6.upload.altID=1
mapleRET6.upload.auto_reset=true

mapleRET6.build.mcu=cortex-m3
mapleRET6.build.f_cpu=72000000L
mapleRET6.build.board=GENERIC_STM32F103R
mapleRET6.build.core=maple
mapleRET6.build.extra_flags=-DMCU_STM32F103RE -mthumb -DBOOTLOADER_maple -march=armv7-m -D__STM32F1__

mapleRET6.build.ldscript=ld/flashRET6.ld
mapleRET6.build.variant=maple_ret6
mapleRET6.build.variant_system_lib=libmapleRET6.a
mapleRET6.build.vect=VECT_TAB_FLASH
mapleRET6.build.density=STM32_HIGH_DENSITY
mapleRET6.build.error_led_port=GPIOA
mapleRET6.build.error_led_pin=5
mapleRET6.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1

##############################################################

from arduino_stm32.

Yeah, 2 transistors identical to the original design.

from arduino_stm32.

Not sure what TZ you are in, but I'll take a look in my lunchhour which starts shortly
11:48 am here.

Easiest thing is for me to add just change the Generic STM32f103RE board setup to work like a cross between the Z and the C series

from arduino_stm32.

Thanks! I'm at GMT, UK so almost 3am!

from arduino_stm32.

jeez

Go to bed ;-)

Is it critical ??

I'll take a look in a minute, but it may take an hour to get all the various menus etc and linker files correct

from arduino_stm32.

Not really, I'm one of those people that after I started on a problem its quite hard to stop ha ha!

from arduino_stm32.

Would be interested to help write some sort of tutorial for adding new boards, if its something that you would like to pursue.

from arduino_stm32.

Its not that hard to add new boards really, its just the menus if you want them inside a single board that can get tricky

I'll have a go at updating my R series boards stuff now

from arduino_stm32.

BTW which bootloader are you using the maple mini or the maple one ??

from arduino_stm32.

maple RET6

from arduino_stm32.

Maple RET6 bin I downloaded from the leaflabs site

from arduino_stm32.

I'm gonna head off. Thanks again!

from arduino_stm32.

OK
I would say its nearly working... Which it is, but I suspect there may be bugs, so probably best if you take a look when you get up ;-)

I don't have an RE board, so I have no way to test. I have an RC but no additional hardware so can't test the maple bootloader stuff

I'm testing on my Maple Rev 3 but it doesnt run on that, however its not surprising as there were a lot of changes in the RET6

from arduino_stm32.

I've done a push to the generic R series boards, but have not tested it even on my RC board

I'll see if I can confirm things are still OK on my RC board for serial upload etc, and you'll need to take a look on your home made RET board when you get up

Edit. Uploads via serial to my RC board still seem fine.

from arduino_stm32.

Hi have tested both Serial3 and Serial4 on my Generic STM32F103RC board and both work fine

i.e Serial = HW Serial1. hence Serila3 = HW Serial4 and Serial4 = HW Serial5

I didn't test the others, apart from "Serial" i.e hw serial 1 which I use all the time

On your system, the mapping with be different as Serial = USB Serial, hence Serial1 = HW Serial1 and Serial5 = HW Serial 5

from arduino_stm32.

Just did a preliminary test, and it works! Will do a more detail test when I get back later. Thank you. On a unrelated note I use Visual Studio with Visual Micro but the upload does not work for STM32_Arduino any good environment recommendations other than using the Arduino IDE?

from arduino_stm32.

@skyng22003

Please "Star" the repo if possible (not sure how you do that, but it seems to be possible as I have 45 stars and I'd like more ;-) )

Re: Visual Studio

I'd be interested to hear your setup.

I do C# dev for some projects so I have Visual Studio 2012, as well as 2010 and 2008 installed on one machine.

Not sure how the upload process would work for VS.

On the Arduino IDE it calls the batch file e.g. maple_upload.bat passing some args

I know some other devs have been looking at Eclipse, but I don't think anyone has that working yet

In he future it would be good to do In Circuit Debugging via STLink (which is why some people are looking at Eclipse), but at the moment I only have 1 config that uploads via STLink and thats purely for upload, i.e not even any debug messages as yet on STlink, hence people normally prefer to use DFU (Maple) or Serial upload

Anyway. Our time zones are very different at the moment as its just after 8pm here, and I'm not a night owl, so usually call it a day by 10pm - buy which time bugs seem impossible to fix ;-)

from arduino_stm32.

So I have Visual Studio 2013 with Visual Micro, I can see all of the STM32_Arduino boards apart from the variant menu (eg the Generic STM32F103R series) this does not even compile. For boards such as the Maple Rev 3+ it compiles but when it comes to uploading it does not work.

Message from output window:
Compiling 'stmf32_test' for 'LeafLabs Maple Rev 3+ to Flash'
Binary sketch size: 18,656 bytes (used 17% of a 108,000 byte maximum) (13.03 secs)
Uploading to I/O board using 'COM25'
Resetting to bootloader via Serial
The system cannot find the file specified

from arduino_stm32.

Sorry should mention Visual Micro works though the Arduino IDE and I have 1.6.0 installed

from arduino_stm32.

OK

It looks like VS doesn't support the new features that were added into Arduino 1.5 in terms of sub-menus

If you are not seeing the sub menu's its not going to upload correctly

check for uodates to whatever interoperability system you are using

Without sub menu's we'd need to add loads more top level boards, which is impractical

Sorry, you'll really need to do your own boards.txt file in this case, as I can't make a boards.txt file that doesn't work well with the Arduino IDE

from arduino_stm32.

Yeah, I agree. But interestingly the Maple Rev3+ does not have any sub menus but it still does not upload? Is this still a sub menu issue?

from arduino_stm32.

I'm not sure why thats not working for you

This is the boards.txt entry for the Maple Rev 3

##############################################################
maple.name=LeafLabs Maple Rev 3+ to Flash

maple.upload.tool=maple_upload
maple.upload.protocol=maple_dfu
maple.upload.maximum_size=108000
maple.upload.use_1200bps_touch=false
maple.upload.file_type=bin
maple.upload.ram.maximum_size=17000
maple.upload.flash.maximum_size=108000
maple.upload.usbID=1EAF:0003
maple.upload.altID=1
maple.upload.auto_reset=true

maple.build.mcu=cortex-m3
maple.build.f_cpu=72000000L
maple.build.board=MAPLE_REV3
maple.build.core=maple
maple.build.extra_flags=-DMCU_STM32F103RB -mthumb  -DBOOTLOADER_maple -march=armv7-m  -D__STM32F1__  
maple.build.ldscript=ld/flash.ld
maple.build.variant=maple
maple.build.variant_system_lib=libmaple.a
maple.build.vect=VECT_TAB_FLASH
maple.build.density=STM32_MEDIUM_DENSITY
maple.build.error_led_port=GPIOA
maple.build.error_led_pin=5
maple.build.gcc_ver=gcc-arm-none-eabi-4.8.3-2014q1

if you look at the line

maple.upload.tool=maple_upload

this specifies to the IDE that it needs to use maple_upload system and in platform.txt

its defined here

# Uploader tools
# -------------------

# Upload using Maple bootloader over DFU
tools.maple_upload.cmd=maple_upload
tools.maple_upload.cmd.windows=maple_upload.bat
#tools.maple_upload.cmd.linux=maple_upload                
tools.maple_upload.path={runtime.hardware.path}/tools/win
tools.maple_upload.path.macosx={runtime.hardware.path}/tools/macosx
tools.maple_upload.path.linux={runtime.hardware.path}/tools/linux    

tools.maple_upload.upload.params.verbose=-d
tools.maple_upload.upload.params.quiet=
tools.maple_upload.upload.pattern="{path}/{cmd}" {serial.port.file} {upload.altID} {upload.usbID} "{build.path}/{build.project_name}.bin"

hence on windiows its supposed to be using

tools.maple_upload.cmd.windows=maple_upload.bat

But you then get the error message

The system cannot find the file specified

I'd recommend you turn on verbose in compile and upload in the IDE and try to work out what file the IDE can't find

Anyway. I need to head off now. So good luck with tracking that issue down.

from arduino_stm32.

It can't find the compiled bin file
I think its the slash?
\AppData\Local\V.Micro\Arduino\Builds\stmf32_test\maple/stmf32_test.bin

from arduino_stm32.

Umm.

I've not seen an issue with the slash for maple uploads, but there was an issue with the serial upload

Looking the the tools win folder at serial_upload.bat

There is some weird looking dos script code that does the slash replacement

Try using it in the maple_upload.bat file

But I think the issues stem from your IDE setup and using visual studio as there are many other peope using the IDE on its own without any such issues

from arduino_stm32.

Hello again, was wondering which file has the maps which maps the physical pins to the pin numbers used in the IDE? Thanks

from arduino_stm32.

Board.cpp PIN_MAP array and there is an enum in board.h

from arduino_stm32.

So in the enum is the pin number order starting from 0?

from arduino_stm32.

Depends on the PIN MAP array in board.cpp for the particular board

Pin 0 is not PA0 for all boards

For the Maple and Maple mini boards the PIN MAP array is all mixed up to match the hardware location of the pins on those boards.

The enum in the bottom of board.h maps real PIN numbers e.g PA0 to their location in the PIN MAP array.

For the generic boards I've been slowly trying to tidy this up, so that its in a logical order when the pins are accessed using their real names,
However its only the generic R and Z series where the PIN MAP is in a logical order, and even then I have not had chance to confirm that absolutely every pin works ok for GPIO and their secondary use e.g. SPI

from arduino_stm32.

Hi again, I changed the Pin map of the STM32F103R from
PA0, PA1, PA2, PA3, PA4, PA5, PA6, PA7, PA8, PA9, PA10, PA11, PA12, PA13, PA14, PA15,
PB0, PB1, PB2, PB3, PB4, PB5, PB6, PB7, PB8, PB9, PB10, PB11, PB12, PB13, PB14, PB15,
PC0, PC1, PC2, PC3, PC4, PC5, PC6, PC7, PC8, PC9, PC10, PC11, PC12, PC13, PC14, PC15,
PD0, PD1, PD2

to

PA3, PA2, PA0, PA1, PB5, PB6, PA8, PA9, PA10, PB7, PA4, PA7, PA6, PA5, PB8,
PC0, PC1, PC2, PC3, PC4, PC5, PC13, PC14, PC15, PB9, PD2, PC10, PB0, PB1,
PB10, PB11, PB12, PB13, PB14, PB15, PC6, PC7, PC8, PC9, PA13, PA14, PA15,
PB3, PB4, PC11, PC12

which is the same as Maple Rev 3, however the it is still not reading the correct digital pins when compiled ?

However if I compile with Maple Rev 3 the correct digital pins are read.

from arduino_stm32.

What am I missing?

from arduino_stm32.

Sorry I think I know where I went wrong..

from arduino_stm32.

I have remapped the the pins on STM32F103R according to the Maple RET6 would you like to add it to your build as a official board?

Again Thank you very much for all your help!

from arduino_stm32.

@skyng22003

The information I have you about enabling Serial USB is only partially correct.

I have realised that although adding -DBOOTLOADER_maple to the build extra flags, does cause the Serial USB to be compiled in, and does seem to work for me on my STM32F103RC board.

There is actually another problem.

Adding that define, causes some other code to also be compiled, which effects the NVIC (vector table), initialisation.

So...

I'm going to split the code up, so that there will be a separate define for -DSERIAL_USB

and I need a way to set the USER_ADD_ROM address, or more usefully the VECT_TAB_ADDR

Because we are getting to the point, where we are going to replace the bootloader with a "Bootloader 2.0" which is 12k smaller and also will allow all RAM to be used by the sketch, rather than the sketch not being allowed to use the lower 3k of RAM

FYI. The code in question is this, from board.cpp

#if defined(BOOTLOADER_maple)
    #define USER_ADDR_ROM 0x08005000
#else
    #if defined(BOOTLOADER_robotis)
        #define USER_ADDR_ROM 0x08003000
    #else
        #define USER_ADDR_ROM 0x08000000
    #endif
#endif
#define USER_ADDR_RAM 0x20000C00
extern char __text_start__;

static void setup_nvic(void) {
#ifdef VECT_TAB_FLASH
    nvic_init(USER_ADDR_ROM, 0);
#elif defined VECT_TAB_RAM
    nvic_init(USER_ADDR_RAM, 0);
#elif defined VECT_TAB_BASE
    nvic_init((uint32)0x08000000, 0);
#elif defined VECT_TAB_ADDR
    // A numerically supplied value
    nvic_init((uint32)VECT_TAB_ADDR, 0);
#else
    // Use the __text_start__ value from the linker script; this
    // should be the start of the vector table.
    nvic_init((uint32)&__text_start__, 0);
#endif
}

I'll let you know when changes have been made

from arduino_stm32.

@skyng22003 if you have a mapping thats exactly the same as the Maple RET6, yes I'd like to add it to the repo,
I'm not sure if you want to do it via a pull request etc or just send me a zip

BTW. You need to do a pull first, as I've changed a lot of stuff today and most likely you will need to make some minor changes to the boards.txt data and also in some of the variant headers and cpp files

from arduino_stm32.

Hi, sorry for the late reply I just did a pull, duplicated the generic_stm32f103rxx and updated the board.txt, board.cpp and board.h but I get a compile error 'void setup_nvic()' in wirish\boards.cpp

Thanks,
Sky

from arduino_stm32.

In addition there is also a error: 'VECT_TAB_ADDR'

from arduino_stm32.

I made some changes to support a new improved version of the bootloader

Which affected the code for the nvic()

Easiest thing is backup your boards.txt and then to pull the latest version,

The changes involve no longer using VECT TAB FLASH in boards.txt and use VECT ADD instead ( sorry I'm on my iPad and I can't lookup the exact names)

So if you diff boards.txt in a commit about 3 or 4 pushes ago, you will see what's been changed

It makes everything more flexible

Also the changes to the bootloader give 3k more ram to the board when you are using the bootloader, and 12k more flash

Things are getting so busy I had to setup a forum for this stuff

Take a look at www.stm32duino.com

Roger

from arduino_stm32.

Sorry, I think I fixed it, everything now compiles fine, how should I send you the zip?

from arduino_stm32.

We cross posted

Did you see the stuff about the new bootloader etc

Unfortunately I have not compiled a version of the bootloader for you board

It's a work in progress, but is nearly done

from arduino_stm32.

So, I have tested Serial 1-4, SPI with SD cards I will report any bugs.

from arduino_stm32.

I am not up to date with that, seems to work with the old maple bootloader though.

from arduino_stm32.

Thanks

from arduino_stm32.

Your welcome, thanks for creating this awesome project! Where should i upload it to?

from arduino_stm32.

Not sure if the forum supports zips can you email roger at rogerclark.net and I'll add it manually

from arduino_stm32.

Just sent you an email, let me know if you don't receive it.

from arduino_stm32.

I presume this is now working OK for you. It works for me, so I'm closing this issue

from arduino_stm32.