Nucleo F401 branch on github sheepdoll

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
User avatar
RogerClark
Posts: 7546
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sat Jun 13, 2015 3:26 am

No worries

I'll make a new repo and copy my F103 and your NucleoF401 stuff in there, but at the moment my F103 stuff isn't even blinking the LED any more.

BTW.
I recall @WestW (github) saying the Cube seems to be a work in progress but that was a few months ago.

I noticed when I initially tried to export the F103 HAL files that the Cube has to download a zip, which I presume has the F103 boilerplate in it.
And I see now there is a update menu until the Help menu. So I guess they may update the libs from time to time.

The F103 export seems to contain a DSPLib which I had to delete entirely, otherwise the IDE tries to build it all, including examples - which seem to hang the gcc compiler.


Anyway, I'll see if I can at least get an LED to blink on the F103 using the HAL

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

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sat Jun 13, 2015 3:45 am

@sheepdoll

OK.

I have at least got your basic blinky sketch working !

For some reason, the SWD (STlink) pins are currently miss-configured.

I'd have thought that if the Clock and Data lines PA14 and PA15 were not configured, they'd default to be SWD but this doesnt seem to be the case for me at the moment :-(

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

Re: Nucleo F401 branch on github sheepdoll

Post by sheepdoll » Sat Jun 13, 2015 4:12 am

RogerClark wrote:@sheepdoll

OK.

I have at least got your basic blinky sketch working !

For some reason, the SWD (STlink) pins are currently miss-configured.

I'd have thought that if the Clock and Data lines PA14 and PA15 were not configured, they'd default to be SWD but this doesnt seem to be the case for me at the moment :-(
Good work!

In the cube pinout tab there is a function called SYS. This seems to control the SWD settings. If you start with a raw chip this in not set. Same for the RCC.

I am using the Nucleo templates. When you start a new project There are two tabs in the upper left "Board Selector" sets up some standard demo boards. clicking on the (>>) button You can even view the user manual or go to the website.

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

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sat Jun 13, 2015 4:30 am

Thanks for the tip about "Sys"

Thats fixed my SWD issue :-)


Sorry to keep asking questions, but did you take the core files from the Arduino SAM and convert the functions into stubs by removing the code inside the functions ?

I notice not all files are present. I presume this is because its a work in progress.

BTW. I thought I'd look at what Avik did, and for some reason he chose not to use the SAM core as the base, and instead has written his own files e.g. gpio.c , I'm not sure the logic in doing this - I'll see if I can contact him


Also, I know I'm interested in getting the F103 going as well as the F4, but I wonder if the HAL API for the F103 and the F4 are identical.

i.e if we write functions for pinMode in the core, making calls to the HAL, I wonder if it would be fine for everything, or just things like GPIO

I looked at the basic stuff like pinMode and it seems like it is the same, but I wonder if SPI etc would be subtly different. i.e Ideally they would be the same

Anyway.

I think I may start a new repo and let all the F103 users play with at least blinking an LED using the Cube and the HAL ;-)

PS. I really need to write a script to delete some files after the cube does its export as I cant stop it outputting the examples and there is also a template c file that needs to be removed,

BTW. I did try enabling the USB device stuff, but it didnt compile as it seems to be missing something. This could just be a fault in the Arduino build, but I'd not be surprised if it was an issue in the Cube exported files.

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

Re: Nucleo F401 branch on github sheepdoll

Post by sheepdoll » Sat Jun 13, 2015 5:10 am

RogerClark wrote:Thanks for the tip about "Sys"

Thats fixed my SWD issue :-)


Sorry to keep asking questions, but did you take the core files from the Arduino SAM and convert the functions into stubs by removing the code inside the functions ?
No problem, answering questions. You must get tons of questions, so it is probably nice to be the other way round.

I was more interested in getting the headers to compile than the actual functions. I had to include some .c files in the library folder so it would build the archive. The next step is to pull the guts out of the Arduino/Proccessing/Wiring functions and replace them with HAL calls. Got a bit side tracked this evening playing with CubeMX.

Not sure why you are getting extra files, that will not compile. Did you check the changes I did in platforms.txt to set some of the defines the files were looking for?
I notice not all files are present. I presume this is because its a work in progress.
Much a work in progress ...
BTW. I thought I'd look at what Avik did, and for some reason he chose not to use the SAM core as the base, and instead has written his own files e.g. gpio.c , I'm not sure the logic in doing this - I'll see if I can contact him
Some of the stuff I am playing with is weeks, months old. It could be he did not have the updated versions. The sam core like AVR core is ATMEL centric. The maple core is much more friendly looking. The code I looked at seem to be sourced from the Maple which is what I had originally planed to do ...
Also, I know I'm interested in getting the F103 going as well as the F4, but I wonder if the HAL API for the F103 and the F4 are identical.

i.e if we write functions for pinMode in the core, making calls to the HAL, I wonder if it would be fine for everything, or just things like GPIO
the file diffs I was playing with this afternoon indicate that the upper level HAL files are pretty much the same. Some differences with the Clocks like HSE vs HSI. ST document DM00105879.pdf (I hate it when they use doc server names) Is the F4xx version of the HAL user manual which seems to be made with Doxygen. I have not tracked down the F1xx version.
I looked at the basic stuff like pinMode and it seems like it is the same, but I wonder if SPI etc would be subtly different. i.e Ideally they would be the same

Anyway.

I think I may start a new repo and let all the F103 users play with at least blinking an LED using the Cube and the HAL ;-)
Why I am posting this, so others can experiment with it.
PS. I really need to write a script to delete some files after the cube does its export as I cant stop it outputting the examples and there is also a template c file that needs to be removed,

BTW. I did try enabling the USB device stuff, but it didnt compile as it seems to be missing something. This could just be a fault in the Arduino build, but I'd not be surprised if it was an issue in the Cube exported files.
I just spent some time on the F401 enabling FATFS and the SD drivers. Have not attempted to build such as I was going to play with the USART today... What is fascinating is that at least on the F4 (could not find it on the F1) there are dedicated SD drivers for not only 1 bit mode, but 4 bit mode too. I thought one had to have special licenses to use 4 bit mode. The middleware is the same FATFS I have been using for AVR projects.

One would think that there would be a way to FATFS to one of the SPI ports. On the other hand if the hardware has built in SD with DMA enabled ...

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

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sat Jun 13, 2015 10:26 am

Thanks for all the information.

I tracked down the F1 HAL doc to here

http://www.st.com/st-web-ui/static/acti ... 154093.pdf

However its not practical to try to read both docs, even in two windows side by side and attempt to spot differences in the HAL.

BTW.
I see where you got the pin map from... Its from the SAM.

I think we may be better off just taking the PIN_MAP stuff from libmaple. The only thing that needs to be right from the start is that we must make sure the PIN_MAP gets compiled into Flash, otherwise we'd have the issue that libmaple has at the moment, where the PIN_MAP is not initialised when global vars (and hence class constructors) are initialized, and we end up with some libraries that don't work

But I'm pretty sure we have a fix for this in libmaple, but I've been wresting with code that Victor wrote to fix this, and I've not managed to get it to work for me. :-(


Anyway. I think the best thing I can do is add the HALMX folder at the same level in my repo as the STM32F1, F3 and F4 folders, so that the HALMX folder can then share the tools etc.

I'm not quite sure about a plan of attach (I'm sure other people would pitch in), but GPIO is going to be by far the easiest, then probably get the USARTS working.

Then SPI, then I2C (we can always use the bit banged implementation that libmaple uses for I2C as it just uses GPIO)

I'd also like to get it to work with the bootloader, but that should just need a small change, to move it to 0x8002000 - however using Maple's usb is going to be a bit more work.
I'm not sure if its worth using the Cube's USB stuff or not. I can't currently get it to compile, and even if I did, I'm not sure what driver would be needed.
But the plus point with the CubeUSB is that there are options to run as HID, Audio or Mass Storage rather than Virtual serial.
However it doesnt seem to have the option to be able to do more than on usb type at once. (unlike the Leonardo / pro micro which can operate as virtual serial and HID at the same time - I think)
(Actually, no one has mentioned HID so far at all, which is a bit surprising, since the device has native USB)

Anyway, I'm not sure I'll get much more done today.

I may have a go at moving it to 0x8002000 and use the bootloader (only for uploads) - just to see how hard it is to modify thing

Cheers

Roger

Edit.

I just remembered the (arrggghhhh) linker script license.

I'm someone clever, e.g. Rick.. Could re-write the script.

It really doesn't look like anything special. I wonder if the libmaple linker script could be modified to do the same job.

In facts its such a small file, I doubt in reality even if it was written from scratch by someone else, whether it would end up looking very much different from the current file.

The other option is to post to ST's community forum to request clarification. i.e how come they are redistributing this file outside of System Workbench.

ummm. Annoying but not insurmountable

Edit.

The libmaple linker script is no good without modification, it has external references that are not in the HAL or code e.g. __start__
However if you google some parts of the Cube generated linker script, there are loads of existing scripts that seem to look virtually identical e.g

http://sourceforge.net/p/stm32/code-0/9 ... 2f407vg.ld

which could be "adapted" to work, and which don't seem to have any license stipulations.

In fact. I took the one from sourceforge, and just had to change the FLASH and RAM size, and it worked for me ;-)
(see blow)

There are some differences, link min heap size and also it doesn't have " .ARM.attributes 0 : { *(.ARM.attributes) }"

But I'm afraid I've no idea what most of this stuff does. (again, perhaps Rick can help)

I think, I'll put this stuff into a new repo and make it a sub module on the main repo, so people can have a play

Code: Select all

ENTRY(Reset_Handler)

MEMORY
{
  FLASH   (rx)  : ORIGIN = 0x08000000, LENGTH = 128K
  RAM     (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}

_estack = ORIGIN(RAM) + LENGTH(RAM);

MIN_HEAP_SIZE = 0;
MIN_STACK_SIZE = 256;

SECTIONS
{
  /* Interrupt vector table */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector))
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    /* Code */
    *(.text)
    *(.text*)
    /* Constants */
    *(.rodata)
    *(.rodata*)
    /* ARM->Thumb and Thumb->ARM glue code */
    *(.glue_7)
    *(.glue_7t)
    KEEP (*(.init))
    KEEP (*(.fini))
    . = ALIGN(4);
    _etext = .;
  } >FLASH

  .ARM.extab :
  {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } >FLASH

  .ARM :
  {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } >FLASH

  .ARM.attributes :
  {
    *(.ARM.attributes)
  } > FLASH

  .preinit_array :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH

  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH

  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(.fini_array*))
    KEEP (*(SORT(.fini_array.*)))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  _sidata = .;

  /* Initialized data */
  .data : AT ( _sidata )
  {
    . = ALIGN(4);
    _sdata = .;   /* create a global symbol at data start */
    *(.data)
    *(.data*)

    . = ALIGN(4);
    _edata = .;   /* define a global symbol at data end */
  } >RAM

  /* Uninitialized data */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;    /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;    /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >RAM

  PROVIDE(end = _ebss);
  PROVIDE(_end = _ebss);

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(4);
    . = . + MIN_HEAP_SIZE;
    . = . + MIN_STACK_SIZE;
    . = ALIGN(4);
  } >RAM

  /DISCARD/ :
  {
    libc.a(*)
    libm.a(*)
    libgcc.a(*)
  }
}

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

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sat Jun 13, 2015 11:40 am

Update

I've pushed all my files to a new repo

https://github.com/rogerclarkmelbourne/ ... uino_STM32

This doesn't contain the tools, its just the files for the HALMX folder that needs to go inside the Arduino_STM32 folder

It seems to work fine for me with using an STM32F103C8 (even though I have exported the Cube as a F103CB (as its only the size of Flash that is different)

I compiled for NucleoF401 and it was OK, but I can't test it (as I don't have one of those.

(umm. Thinking... I have a F3 Nucleo, so it may be worth seeing if it works, and I also have a F407, so its worth exporting the cube for that as well)

Anyway, its something to play with.

Note to anyone reading this rather than the whole thread.

None of the Arduino API is present yet. I'm just using this blink test sketch (which does work) - uploading via STLink (though Serial upload could easiy be made to work)

Code: Select all

void setup() {
  // put your setup code here, to run once:
}

void loop() {
   HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);
    HAL_Delay(100);/* Insert delay 200 ms */
}

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

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sat Jun 13, 2015 10:10 pm

Re: variations between tha F1 and F4 HAL etc.

I took a look at the MakerLabMe wiring_digital.c

https://github.com/MakerLabMe/STM32_Ard ... _digital.c

And it seems to need a lot of ifdef's to support the different processors.

This seems to be mainly due to pinMode needing to setup the GPIO clocks, which are different on the F1 and the F4.

I will need to read the HAL docs, as it seems odd that the HAL would not abstract this. But I suspect perhaps it doesn't. Or perhaps when Andy of MakerMabMe started his stuff the HAL was older and didn't do this.

To early to tell the the moment

Edit

Makerlabme doesn't use the HAL, as far as I can tell.

And it doesn't look like Koduino uses the HAL (as far as I can see)

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

Re: Nucleo F401 branch on github sheepdoll

Post by sheepdoll » Sun Jun 14, 2015 4:07 am

I finally got the standard blinkey sketch to run on https://github.com/sheepdoll/Arduino_ST ... ting/HALMX. This uses macros to define millis() as HAL_GetTick() and delay() as HAL_Delay(). Not sure what do do with micros() as HAL sets up a millisecond timer. A lot of my AVR code uses microsecond timing. Will eventually want that as I use a resolution of between 24 and 25 uSeconds in the main loop for the frame rate. There is a lot of stuff to read on timer setup which is probably way down the path here... I really want to get some of the serial backchannel setup.

One has to love the C++ preprocessor. I forgot and left a stub for mills(){} so the LED would turn on and not blink. gdb showed me that the code was jumping into the stub. So when you make two functions identical through #define. They really are identical. Probably all the instances of mills were replaced with HAL_GetTick.

Surprisingly in the pushed code is not all that much is needed to glue digital IO onto HAL. At the moment there are not a lot of checks for setting up pins wrong. Arduino sam code checks the pin mapping array for peripherals that are blocking. As this array is static in flash, enabling a built in peripheral as part of the Arduino setup could behave unpredictably if the user arbitrarily decides to change the pinMode.

I will either need to shadow the peripheral maps with something that can be placed into a switch or compare, or make and find accessors into the upper levels if the abstraction layer. Mostly this does affect the pin mode clocks. On the F4xxx these are set in the gpio.c init() section called from main(). This works if the pin is defined in CubeMX and the header included. If a raw chip is setup in CubeMX and there is no gpio startup in main, then the pinMode() will fail as there is no clock. More likely the pinMode() will fail at compile as the gpio.h headers are not included and symbols left undefined.

Catching up on some of the other issues. At this point I really do not care about the linker script license. This project is "Educational" As the same code appears in multiple places, with and without license, I suspect this is an over aggressive use of cut and paste.

For the time being I am going to stay with the HALMX sandbox I setup. This may make it difficult to automatically update the https://github.com/rogerclarkmelbourne/ ... uino_STM32 branch other than to option copy the changes over.

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

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sun Jun 14, 2015 4:29 am

Re: delay();

I'm not sure why we cant use the HAL_Delay() for delay() ? They are both in milliseconds.

I did a bit of background reading around microsecond timing using Sys Tick, but the basic HAL code wont be enough to do this, some specific timer callbacks will be needed.

BTW. I also found some code that looks like it would handle the serial comms

http://stackoverflow.com/questions/2487 ... hal-driver

Re: GPIO Clock enable.

As its on a port by port basis, all I did in the bootloader is enabled all GPIO clock for all possible ports, A to E in the case of the F103, this didn't seem to cause any problems, so I suspect the same thing is possible in gpio.c (the Cube already wrote code enabling all the GPIO clocks even though I don't think in the pin GIO thing I was using all ports.

Post Reply