STM32CubeMX :: STM32F030F4 support

Development of new Cores using the STMCubeMX and HAL
User avatar
RogerClark
Posts: 6917
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Wed Apr 13, 2016 7:05 am

Thanks

I tested the blink sketch on the F103 and it works, but I have issues with my STLink not being recognised, but I'm not sure why.

So I'm doing manual uploads

User avatar
martinayotte
Posts: 1222
Joined: Mon Apr 27, 2015 1:45 pm

Re: STM32CubeMX :: STM32F030F4 support

Post by martinayotte » Wed Apr 13, 2016 12:51 pm

Probably this famous SWD enable/disable flag ?

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 » Wed Apr 13, 2016 8:12 pm

I find it odd that Rodger has problems with the ST-Link. It was the ST-Link on the Nucleo that made it possible for me to download code from mac OSX. That is the part I am most concerned with breaking. So far it still seems to be working.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Wed Apr 13, 2016 8:42 pm

The problems i am having with STLInk is that the Windows CLI (exe) does not find the STLink hardware, unless I cd into its installation location in program files and run it from there.

It doesnt seem to work if I copy it to the tools/win/stlink folder.

I need to spend more time working out why this is happening.

I moved to a new Core i7 PC a short while ago, (still running W7), and since then I have had some USB issues. Though in this issue is a wierd one, as the STLink CLI seem to work under some circumstances.

User avatar
ahull
Posts: 1598
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: STM32CubeMX :: STM32F030F4 support

Post by ahull » Wed Apr 13, 2016 8:51 pm

Sounds like some Windows "security" feature, and/or a PATH issue. For all Windows issues click here. ;)
- Andy Hull -

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Wed Apr 13, 2016 9:07 pm

Andy

It was getting late the other evening when I tried to use the STLink, so things were not making any sense.

I.e. even when I added the path to where the exe is installed, the stlink-upload.bat failed to get the exe to attach to the stlink hardware.

I guess I can try running the IDE as Administrator, but I dont normally need to do this.
Perhaps some security default setting changed via Windows update when I initially install W7 on this new machine :-(

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

Re: STM32CubeMX :: STM32F030F4 support

Post by stevech » Thu Apr 14, 2016 4:10 am

Were you using the free ST-Link utility?
It's on my windows toolbar. Just click the icon. No admin.
But I use it more often from within my IDE - where it uses the UI of the IDE, not the standalone you see below.
2016-04-13_210801.jpg
2016-04-13_210801.jpg (246.75 KiB) Viewed 583 times

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

Re: STM32CubeMX :: STM32F030F4 support

Post by Vassilis » Thu Apr 14, 2016 7:01 am

Maybe an stlink firmware upgrade or downgrade will solve that problem.

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Thu Apr 14, 2016 10:05 am

OK.

I worked out what the problem was

The new version of the ST-Link CLI Exe (version 2.4) is not compatible with the stlink_upload.bat command

The new version seems to need the keyboard to be pressed (e.g. return pressed), after the upload if the -Run option is used.

So either we need to bundle version 2.1 of the CLI in the repo or we modify the bat file command line to remove the -Run option

As far as I can tell, the -Run option is not required, as we also use the -Rst (reset) option, and it seems to work fine without the -Run option, so I think we should remove it

I am not a lawyer, but as far as I can tell, the license on the STLink software allows it to be distributed, as the License grants in relation to STLink software ( http://www2.st.com/content/ccc/resource ... 217720.pdf)

"(iii) make, have made, use, sell, offer to sell, import and export or otherwise distribute Products also through multiple tiers."

So for windows users, I think its easier if I add the CLI (Exe) to the repo so that we have a version in the repo which matches the stlink_upload.bat

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

Re: STM32CubeMX :: STM32F030F4 support

Post by RogerClark » Thu Apr 14, 2016 11:28 am

@Vassillis and @sheepdoll

I've had a go at getting the HALMX core to work with the bootloader and I think it almost works, but at the moment I have no way to reset the board (generic STM32F103C) so that the PC spots that the DFU device is now available.

So the only way I can get it to work is if I unplug the board, then press upload, and when its waiting / looking for the DFU device, I plug the board in.

However, its definitely compiling and linking the code to 0x8002000 and the bootloader runs the code from that location

I had to change the linker (.ld) file to specify the flash start address as 0x8002000,

I also had to change

system_stm32f1xx.c

So that it has

Code: Select all

#ifndef VECT_TAB_OFFSET
#define VECT_TAB_OFFSET  0x0 /*!< Vector Table base offset field. 
                                  This value must be a multiple of 0x200. */
#endif
So that if VECT_TAB_OFFSET is defined in the compiler command line, (which we can do via boards.txt), we can pass in the offset of 0x2000

Hence in boards.txt I added the vector offset to this line

Code: Select all

MXBluePillF103C8.build.extra_flags=-DSTM32F103xB -DSTM32_MEDIUM_DENSITY -DSTM32F1 -DBOARD_NUCLEO_F103RB -DVECT_TAB_OFFSET=0x02000

So.. The only problem is, how do we manage the change to system_stm32f1xx.c as its a file produced by the Cube ??

Post Reply