Firmware

[electric_vehicle_lover]

The code do not touch on the buzzer.

Please go ahead and commit all yoir changes. I will pull and verify if it works. I have no problem in chaging for something that works. I use Linux Ubuntu on a virtual machine.

I have some dev boards here with the same STM32F103 and I can test the code using oscilloscope to see if we have the expected timmings.

[jayjay23]

I have now several controllers unscrewed and the one I started this thread with had the yellow transparent (thin) battery plastic tape:-D (others have the rubbery stuff, yes), and as an additional electric isolation mine hat some dirt under the plastic tape !!!

I can have short look at the PINs, but today my time already running out, so I have nothing to commit actually (well if I tried one spl we should keep only one, and if we find a common gcc path and agree on one makefile, we can make this also the first files appear).

Edited November 19, 2015 by jayjay23

[DebboR]

1 minute ago, jayjay23 said:

I have now several controllers unscrewed and the one I started this thread with had the yellow transparent (thin) battery plastic tape:-D (others have the rubbery stuff, yes), and as an additional electric isolation mine hat some dirt under the plastic tape !!!

Haha, another example of chinese manufacturing trying to save every last tenth of a cent :D

[jayjay23]

Another short comment, PB9 is the power switch LED which has separate connector which I totally forgot to check, so maybe it's working. Another thing I wanted to mention is that I wrongly soldered the LEDs so I measured the voltage and it's between 5V and 1,68V (off)? I plugged LEDs from another wheel and they were quite dark, but htis could also be that the resistor is near the LEDs and not onboard, who knows.

[Restless]

Small update from my side, finally i got a response from the seller for the Boards.

I'll give u guys my bank informations via PM :)

[jayjay23]

One comment for our dev boards, I had now two boards to which I could not connect right away, now that we are trying to use the JTAG PINs I read that disabling JTAG seems to be one function with disabling JTAG and SWD, so maybe there boards were it does not work out of the box, are disabling both, in which case I read there is some kind of reset debug connect (I don't know exactly how it works, maybe by setting some rest pin and then trying to connect, it should then connect before the firmware disables the JTAG/SWD interface).

On my deleted formware though it seems that the SWD was enabled, still the JTAG PINs reused for GPIO, so maybe if it's not the SPL used directly (disable all) but with some registers directly this intermediate state (JTAG disabled, SWD enabled) can be achieved.

[jayjay23]

Ok found it:

GPIO_PinRemapConfig(GPIO_Remap_...., ENABLE);

  *     @arg GPIO_Remap_SWJ_NoJTRST      : Full SWJ Enabled (JTAG-DP + SW-DP) but without JTRST
  *     @arg GPIO_Remap_SWJ_JTAGDisable  : JTAG-DP Disabled and SW-DP Enabled
  *     @arg GPIO_Remap_SWJ_Disable      : Full SWJ Disabled (JTAG-DP + SW-DP)

So I will use GPIO_Remap_SWJ_JTAGDisable for our boards as they have SWD not used for special puproses.

In case we have some initial firmware that disables all, we need some reset BOOT pin setup to get the SWD enabled.

It works, so now all LEDs do it, and the SWD port is still working! I will look to check that state in.

[electric_vehicle_lover]

Great!!!

They need to program the chip on production. Since the swd is labeled on the board, I bet they use it for programming and used for the development.

 

[electric_vehicle_lover]

@jayjay23 I pull your code and it fails to build with this error:

If I remove -lgcc from this line on makefile, it works:
LFLAGS  = -Tsrc/stm32_flash.ld -L../../gcc/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/current -lgcc -nostartfiles

And the make clean also fails:

Also, could you please prepare the makefile to leave all the built files on a forlder like BUILD or something?? this way we can just ignore this folder on .gitignore.

So, if the controller board uses internal clock system, I will read about it and try figure out the configuration. Later measure with osciloscope a square wave on GPIO to validate the clock configuration.

[electric_vehicle_lover]

@jayjay23 make clean for me works if is like this:

clean: 
    rm -f src/main.lst src/main.elf src/main.bin
    find src/ -name *.o | xargs rm -f

Can you please update the make file??

[electric_vehicle_lover]

@jayjay23 I just made a commit to select the right clock (HSI - High Speed Internal clock). Look at this note from STM32F10x reference manual:

When the HSI is used as a PLL clock input, the maximum system clock frequency that can be achieved is 64 MHz.

Can you please test now the Systick interrupt to see if we get the correct time??

On the Makefile, please change ODFLAGS = -S to ODFLAGS = -0. With 0 there is no optimization on the code and is the best to debug using the JTAG.

[jayjay23]

20 hours ago, electric_vehicle_lover said:

If I remove -lgcc from this line on makefile, it works:

I think I added for having math functionality, I use sin() and alike in the IMU code (which is currently not there again). If this math stuff is too big or too slow we can discuss to use some integer-math replacement instead. The error is originated from the hardcoded -L path in front of -lgcc,

 I changed the -L path to the gcc libraries to be also created automatically:

TCPREFIX  = ../../gcc/gcc-arm-none-eabi/
BINPREFIX = bin/arm-none-eabi-
CC      = $(TCPREFIX)$(BINPREFIX)gcc

LFLAGS  = -Tsrc/stm32_flash.ld -L$(TCPREFIX)lib/gcc/arm-none-eabi/current -lgcc -nostartfiles
 

would this be ok? (TCPREFIX is now just the base path, BIN the prefix and path to the binaries, and the -L path is the base path plus library path (hardcoded))

20 hours ago, electric_vehicle_lover said:

And the make clean also fails:

The original line is very simple:

find -name *.o | xargs rm

Can you check why a 'l' is added right after the end? Maybe 'find' or 'xargs' need some parameters to work together, there are also more complex syntax like with {} placeholder, but I found it nice it was less compicated. The '-f' is workaround that enabled some new functionality in 'rm', due to this I would more like to know the root cause or get another syntax of find/xargs.

[jayjay23]

@electric_vehicle_lover:

Can you check whether one of the following works for you:

find -name *.o -print0 | xargs -0 rm

or

find -name *.o -print0 | xargs -0 rm --

(don't know right now what the -- is for, something with filenames starting with a - not treated as a option I think)

or

find -name *.o -exec rm -- {} +

(http://stackoverflow.com/questions/896808/find-exec-cmd-vs-xargs)

[jayjay23]

20 hours ago, electric_vehicle_lover said:

Also, could you please prepare the makefile to leave all the built files on a forlder like BUILD or something?

I thought about that in the beginning, but I thought it's maybe not worth the effort, do you think it's usefull? The .gitignore file looks like it can use recursive

wildcards like *.o and so on.

[electric_vehicle_lover]

6 hours ago, jayjay23 said:

I think I added for having math functionality, I use sin() and alike in the IMU code (which is currently not there again). If this math stuff is too big or too slow we can discuss to use some integer-math replacement instead. The error is originated from the hardcoded -L path in front of -lgcc,

 I changed the -L path to the gcc libraries to be also created automatically:

TCPREFIX  = ../../gcc/gcc-arm-none-eabi/
BINPREFIX = bin/arm-none-eabi-
CC      = $(TCPREFIX)$(BINPREFIX)gcc

LFLAGS  = -Tsrc/stm32_flash.ld -L$(TCPREFIX)lib/gcc/arm-none-eabi/current -lgcc -nostartfiles

Seems ok to me.

For some reason I am now getting this error but I don't know why...

jpinto@ubuntu:~/generic-electric-unicycle/firmware$ make all
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/startup_stm32f10x_md.s -o src/startup_stm32f10x_md.o
as: unrecognized option '-mcpu=cortex-m3'
Makefile:62: recipe for target 'src/gpio.o' failed
make: *** [src/gpio.o] Error 1
jpinto@ubuntu:~/generic-electric-unicycle/firmware$ 
 

And the GCC version I am using:

jpinto@ubuntu:~/generic-electric-unicycle/firmware$ ../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977]
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

jpinto@ubuntu:~/generic-electric-unicycle/firmware$ 
 

Edited November 23, 2015 by electric_vehicle_lover

[jayjay23]

19 hours ago, electric_vehicle_lover said:

as: unrecognized option '-mcpu=cortex-m3'

Seems to be a strange gcc setup problem to me.

Can you try what happens if you call the correct "as" directly:

gcc/gcc-arm-none-eabi/bin $ ./arm-none-eabi-as

This gives me a prompt that you can end with ctrl-C

If I call arm-none-eabi-as -mcpu=cortex-m3  I get the same prompt

If I call arm-none-eabi-as -mcpu=blahblah I get:

Assembler messages:
Error: unknown cpu `blahblah'
Error: unrecognized option -mcpu=blahbla

Note that this is quite different output to what you get.

If I call  "as -mcpu=cortex-m3" which uses my system assembler, which is not capable of creating arm code I get your error:

as: unrecognized option '-mcpu=cortex-m3'

 

So my guess is that your gcc for some unknown reason (maybe environment variables?) is calling the system "as" instead of the "arm as".

Maybe you can try to call "arm as" directly, by stripping all options that as do not understand, I can compile the assembler file with this command:

 ../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-as -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -c -g -mcpu=cortex-m3 -mthumb src/startup_stm32f10x_md.s -o src/startup_stm32f10x_md.o

 

Edited November 24, 2015 by jayjay23

[electric_vehicle_lover]

Finally found it!! Thanks.

For the assembly work, on make file:

AS      = $(TCPREFIX)$(BINPREFIX)as

AFLAGS     = -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -c -g -mcpu=cortex-m3 -mthumb

%.o: %.c
    @echo ".compiling"
    $(AS) $(ASFLAGS) src/startup_stm32f10x_md.s -o src/startup_stm32f10x_md.o
    $(CC) $(CFLAGS) $< -o $@

Then I was getting this error:

jpinto@ubuntu:~/generic-electric-unicycle/firmware$ make all
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-as  src/startup_stm32f10x_md.s -o src/startup_stm32f10x_md.o
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/gpio.c -o src/gpio.o
arm-none-eabi-gcc: error trying to exec 'cc1': execvp: No such file or directory
Makefile:65: recipe for target 'src/gpio.o' failed
make: *** [src/gpio.o] Error 1
 

Finally I added the path for toolchain where CC1 is found:

export PATH=$HOME/gcc/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/current:$PATH

I am moving on...

@jayjay23 please update the Makefile and commit it.
 

 

[jayjay23]

Hi @electric_vehicle_lover

7 hours ago, electric_vehicle_lover said:

For the assembly work, on make file:

I have seen this too, I just didn't used it as it was working with gcc (I still think it should work on correct installation), but as it is more

clear even, I have no problem integrating it.

I also noticed that this AS step was actually done for every object, so I moved it to a separate make task.

I also noticed that I had left a startup.....c file from what you checked in when you added all your code, now I was not sure whether this

makes everything run, but I with the AS change I had linking problems which were solved by removing the .c startup code. I shortly

checked the compilation result on the chip and it sill runs.

 

I also added one line (SystemInit();) in the beginning of main (not commited as still under discussion) and the leds are now faster, maybe

1/2 to 1/4s (with the counter changed to 10 to get 1s blinking).

commited the Makefile and the remove of the startup...c file.

[electric_vehicle_lover]

Thanks.

Next I had this error:

In file included from src/spl/CMSIS/stm32f10x.h:484:0,
                 from src/spl/inc/stm32f10x_rcc.h:32,
                 from src/gpio.c:2:
src/spl/CMSIS/core_cm3.h:90:75: fatal error: stdint.h: No such file or directory
 #include <stdint.h>                           /* Include standard types */
                                                                           ^
And I added this line to CFLAGS:

-I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/

Now I have this error:

.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/gpio.c -o src/gpio.o
as: unrecognized option '-mcpu=cortex-m3'
Makefile:64: recipe for target 'src/gpio.o' failed
make: *** [src/gpio.o] Error 1
 

NOTE: I also added -Wfatal-errors to CFLAGS so the compiler stops on the first error.

So I added -C option to CFLAGS so the compiler just compiles and do not assembly. Here is the output and current error:

.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/gpio.c -o src/gpio.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/main.c -o src/main.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_gpio.c -o src/spl/src/stm32f10x_gpio.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_i2c.c -o src/spl/src/stm32f10x_i2c.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_dma.c -o src/spl/src/stm32f10x_dma.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_rcc.c -o src/spl/src/stm32f10x_rcc.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/misc.c -o src/spl/src/misc.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/CMSIS/system_stm32f10x.c -o src/spl/CMSIS/system_stm32f10x.o
.compiling
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -I../../gcc/gcc-arm-none-eabi/arm-none-eabi/include/ -S -Wfatal-errors -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/CMSIS/core_cm3.c -o src/spl/CMSIS/core_cm3.o
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-as    -o src/startup_stm32f10x_md.o src/startup_stm32f10x_md.s
..linking
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-ld -v  src/gpio.o src/main.o src/spl/src/stm32f10x_gpio.o src/spl/src/stm32f10x_i2c.o src/spl/src/stm32f10x_dma.o src/spl/src/stm32f10x_rcc.o src/spl/src/misc.o src/spl/CMSIS/system_stm32f10x.o src/spl/CMSIS/core_cm3.o src/startup_stm32f10x_md.o -Tsrc/stm32_flash.ld -L../../gcc/gcc-arm-none-eabi/lib/gcc/arm-none-eabi/current -lgcc -nostartfiles -o src/main.elf
GNU ld (GNU Tools for ARM Embedded Processors) 2.24.0.20150921
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-ld:src/gpio.o: file format not recognized; treating as linker script
../../gcc/gcc-arm-none-eabi/bin/arm-none-eabi-ld:src/gpio.o:1: syntax error
Makefile:60: recipe for target 'main.elf' failed
make: *** [main.elf] Error 1
 

[electric_vehicle_lover]

Ok, a clean build but I don't know if this code runs:

make all
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/gpio.c -o src/gpio.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/main.c -o src/main.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_gpio.c -o src/spl/src/stm32f10x_gpio.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_i2c.c -o src/spl/src/stm32f10x_i2c.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_dma.c -o src/spl/src/stm32f10x_dma.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/stm32f10x_rcc.c -o src/spl/src/stm32f10x_rcc.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/src/misc.c -o src/spl/src/misc.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/CMSIS/system_stm32f10x.c -o src/spl/CMSIS/system_stm32f10x.o
.compiling
arm-none-eabi-gcc -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb src/spl/CMSIS/core_cm3.c -o src/spl/CMSIS/core_cm3.o
arm-none-eabi-as    -o src/startup_stm32f10x_md.o src/startup_stm32f10x_md.s
..linking
arm-none-eabi-ld -v  src/gpio.o src/main.o src/spl/src/stm32f10x_gpio.o src/spl/src/stm32f10x_i2c.o src/spl/src/stm32f10x_dma.o src/spl/src/stm32f10x_rcc.o src/spl/src/misc.o src/spl/CMSIS/system_stm32f10x.o src/spl/CMSIS/core_cm3.o src/startup_stm32f10x_md.o -Tsrc/stm32_flash.ld -Larm-none-eabi-lib/gcc/arm-none-eabi/current -nostartfiles -o src/main.elf
GNU ld (2.25-10ubuntu1+5build1) 2.25
...copying
arm-none-eabi-objcopy -Obinary src/main.elf src/main.bin
arm-none-eabi-objdump -S src/main.elf> src/main.lst
 

How??

I decide to install the ARM-NONe-EABI that comes on Ubuntu repos and the makefile is this:

TCPREFIX  = arm-none-eabi-
CC      = $(TCPREFIX)gcc
AS      = $(TCPREFIX)as 
LD      = $(TCPREFIX)ld -v
CP      = $(TCPREFIX)objcopy
OD      = $(TCPREFIX)objdump
GDB     = $(TCPREFIX)gdb

STM32FLASH = tools/flash

# -mfix-cortex-m3-ldrd should be enabled by default for Cortex M3.
# CFLAGS -H show header files
AFLAGS  = -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -c -g -mcpu=cortex-m3 -mthumb 
CFLAGS  = -Isrc -Isrc/spl/CMSIS -Isrc/spl/inc -mfloat-abi=soft -msoft-float -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb
LFLAGS  = -Tsrc/stm32_flash.ld -L$(TCPREFIX)lib/gcc/arm-none-eabi/current -nostartfiles

@jayjay23, are you using Linux Ubuntu? if yes, would you mind to change to this compiler version and change the Makefile??

[electric_vehicle_lover]

I got it :-)

I received today the STLink V2, I got the code to build for the first time and I flashed a board I have here with an STM32F103 - here is screesnhots of the Eclipse showing a debug session and the current code for LED blinking:

Unfortunately, I used my oscilloscope to see the pins and I didn't got any signal on the pins, even with the code running. Something to work later. 

[jayjay23]

21 hours ago, electric_vehicle_lover said:

I decide to install the ARM-NONe-EABI that comes on Ubuntu repos and the makefile is this:

Does it mean the working compile process was with the Ubuntu gcc toolchain and the downloaded one gave the errors, or vice versa?

21 hours ago, electric_vehicle_lover said:

@jayjay23, are you using Linux Ubuntu? if yes, would you mind to change to this compiler version and change the Makefile??

No, I'm using gentoo since more than ten years now, I have used ubuntu shortly and a few years suse, I think it's impossible that all contributors use the same distribution.

The question is why did the downloaded version did not work, you just unpacked it and gave it a try right?

[jayjay23]

The gcc version (from launchpad) that I'm using is this:

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]

 

I still think that for some reason your gcc installation was broken, the errors you were getting were all related to 'I can not find my own files'. It's a bit difficult to track this down from remote, btw, what did my different 'as' calles had given you?

If you want and we can find a suitable tool and time slot we can also try a remote session?

If you want to stick to the ubuntu gcc, I would still think that the original release from launchpad will serve more different people right in the future, so in that case could you adjust your environment (e.g. with links) to suite the launchpad version?

[electric_vehicle_lover]

Ok I got the code blinking and measured with oscilloscope -- the timings seems to be ok. I also pushed the code.
I had to configure the GPIO as Push Pull as Open Drain don't work on my board - I think is safe to use Push Pull mode.

@jayjay23 Since I use different tools like the compiler, Makefile, OpenOCD scripts and Eclipse project files, I thought that maybe I will try to make all that files be outside of the project folder and I will create another another repo just on my personal account of github for my specific files. I am thinking in put this generic_unicycle firmware folder inside my repo but ignore it by git - I think it will work. So, please go ahead and keep the files for your setup. I want to document on the wiki the most important things for my configuration.

 

---------------

I think there is a bug:

  counter++;
  if (counter > 100) // 1 second
  {
    .....
   }

    counter = 0;

counter may goes from 0 to 101... the loop should be 100 units of 10ms to be 1 second.

 

Edited November 26, 2015 by electric_vehicle_lover

[jayjay23]

Hey, cool, the osci is amazing, does it has PC connection, or how do you make the screenshots!

Ok, if you can manage that I hope it would be the right decision for other to join, end of next week I will introduce the project in our company and see if anybody joins.

Yes, the counter should be (if c >= 100), it reaches the if with a 1 already as the ++ is in front, but 1 to 101 is still one too much :-)

Regarding the push/poll open/drain I think it's how you use the PINs, the LEDs are already powered with 5V and the minus side goes into the chip. This reversed

to when you want to measure a voltage coming from the chip (though I have not confirmed this assumption anywhere).