Difference between revisions of "Proj-2013-2014-Python-STM32F4"

From air
Jump to navigation Jump to search
 
(48 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
= Team =
  
= Team =
 
*Tutors : Olivier Richard
 
*Tutors : Olivier Richard
−
*Members : [[User:Xinxiu TAO|TAO Xinxiu]] , [[User:Ye XIA|XIA Ye]]
 +
*Members : [[User:Ye XIA|Ye XIA]] , [[User:Xinxiu TAO|Xinxiu TAO]]
   
   
 
= Objectives =
  
= Objectives =
  +
  +
  +
= Software Requirements Specification (SRS) =
  +
The SRS document:
  +
* [[Proj-2013-2014-Python-STM32F4:SRS]]
  +
   
 
= Points à traiter =
  
= Points à traiter =
 
* Modidification des Makefile
  
* Modidification des Makefile
 
utilisation de arm-none-eabi-g++ et des bonnes options
 
utilisation de arm-none-eabi-g++ et des bonnes options
  +
https://launchpad.net/gcc-arm-embedded
   
 
* support STL
  
* support STL
 
Voir https://github.com/andysworkshop/stm32plus
  
Voir https://github.com/andysworkshop/stm32plus
  +
à voir aussi
  +
uSTL http://msharov.github.io/ustl/
  +
 
* Lib C
  
* Lib C
−
Voir newlib
 +
Voir newlib et newlib-nano
  +
https://launchpad.net/gcc-arm-embedded
  +
  +
<pre>
  +
from gcc-arm-embedded source
  +
https://launchpadlibrarian.net/160487135/readme.txt
  +
  +
* C Libraries usage *
  +
  +
This toolchain is released with two prebuilt C libraries based on newlib:
  +
one is the standard newlib and the other is newlib-nano for code size.
  +
To distinguish them, we rename the size optimized libraries as:
  +
  +
libc.a --> libc_s.a
  +
libg.a --> libg_s.a
  +
  +
To use newlib-nano, users should provide additional gcc link time option:
  +
--specs=nano.specs
  +
  +
Nano.specs also handles two additional gcc libraries: libstdc++_s.a and
  +
libsupc++_s.a, which are optimized for code size.
  +
  +
For example:
  +
$ arm-none-eabi-gcc src.c --specs=nano.specs $(OTHER_OPTIONS)
  +
  +
This option can also work together with other specs options like
  +
--specs=rdimon.specs
  +
  +
Please be noticed that --specs=nano.specs is a linker option. Be sure
  +
to include in linker option if compiling and linking are separated.
  +
  +
** additional newlib-nano libraries usage
  +
  +
Newlib-nano is different from newlib in addition to the libraries' name.
  +
Formatted input/output of floating-point number are implemented as weak symbol.
  +
If you want to use %f, you have to pull in the symbol by explicitly specifying
  +
"-u" command option.
  +
  +
-u _scanf_float
  +
-u _printf_float
  +
  +
e.g. to output a float, the command line is like:
  +
$ arm-none-eabi-gcc --specs=nano.specs -u _printf_float $(OTHER_LINK_OPTIONS)
  +
  +
For more about the difference and usage, please refer the README.nano in the
  +
source package.
  +
</pre>
  +
  +
   
−
* gc Garbage Collection
+
* Garbage Collection
 
Voir tinygc http://tinygc.sourceforge.net/
  
Voir tinygc http://tinygc.sourceforge.net/
  +
à voir aussi celui de micropython
   
 
* libprce
  
* libprce
 
Voir T-Rex is a minimalistic regular expression http://tiny-rex.sourceforge.net/ http://sourceforge.net/projects/tiny-rex/
  
Voir T-Rex is a minimalistic regular expression http://tiny-rex.sourceforge.net/ http://sourceforge.net/projects/tiny-rex/
−  
−  
   
 
= Progress=
  
= Progress=
Line 31: Line 88:
   
 
== Week 1 (13/01 - 19/01) ==
 
== Week 1 (13/01 - 19/01) ==
−
*Project discovery
 +
* Project discovery
−
*Research of related projects
 +
* Research of related projects
  +
   
 
== Week 2 (20/01 - 26/01) ==
 
== Week 2 (20/01 - 26/01) ==
  +
* STM32 develop environment
−
*Try the official examples of ST on the cards
  
  +
−
To avoid using the commercial software IDE and understand better, We decided to develop on Linux for this project.
  
  +
'''Add USB device'''
−
During the tries, for certain examples, we've got different results on STM32F407 and STM32F401.
 
  +
Create a new udev rule in /etc/udev/rules.d/45-usb-stlink-v2.rules:
−
We choose STM32F407 as the hardware for the following developement.
  
  +
SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="660", GROUP="plugdev"
  +
To reboot :
  +
$ sudo service udev restart
  +
  +
'''Download the GNU/ARM toolchain'''
  +
Download the Linux current installation tarball from
  +
https://launchpad.net/gcc-arm-embedded/+download
  +
$ tar -xvjf gcc-arm-none-eabi-xxxxxxxxxxxxxxxxxx-linux.tar.bz2
  +
Add the fallowing to your ~/.bashrc
  +
export PATH=$PATH:~/xxxxxxx/gcc-arm-none-eabi-xxxxxxxxx/bin
  +
$ source ~/.bashrc
  +
To check :
  +
$ arm-none-eabi-gcc --version
  +
If you get an error message “bash : ... file does not exist”.
  +
Maybe it is caused by the difference between 32bit and 64bit system. Try :
  +
$ sudo apt-get install ia32-libs*
  +
  +
'''Download and Build STLINK'''
  +
STLINK is for programming and debugging firmware.
  +
you'll first need to install a couple of packages:
  +
$ sudo apt-get install autoconf pkg-config libusb-1.0 git
  +
Retrieve a copy of the STLINK source:
  +
$ git clone https://github.com/texane/stlink.git
  +
Build the code following the instructions in the README, with:
  +
$ ./autogen.sh
  +
$ ./configure
  +
$ make
  +
As a sanity check, look in ~/st-link and you should see st-util, st-flash, etc...
  +
You may check if the board could be connected by execute st-util.
  +
If it does not work please confirm if the rule you added in the first step corresponds your system.
  +
  +
'''Refer to link''' : http://www.wolinlabs.com/blog/linux.stm32.discovery.gcc.html
  +
  +
* Try the official examples of ST on the cards
  +
To avoid using the commercial software IDE and understand better, We decided to develop on Linux for this project.
  +
During the tries, for certain examples, we've got different results on STM32F407 and STM32F401.
  +
We choose STM32F407 as the hardware for the following developement.
  +
   
 
== Week 3 (27/01 - 02/02) ==
 
== Week 3 (27/01 - 02/02) ==
−
*Test Project MicroPython
 +
* Test Project MicroPython
−
*Test Project Shedskin
 +
* Test Project Shedskin
  +
  +
* STM32 hardware
  +
[[File:PythonSurSTM32_Hardware_1.png|800px]]
  +
  +
[[File:PythonSurSTM32_Hardware_2.png|800px]]
  +
  +
  +
== Week 4 (02/02 - 09/02) ==
  +
* STM32 breakdown situation & solution
  +
  +
'''Cause Reason'''
  +
After
  +
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;
  +
GPIOC->MODER = 0x04000000;
  +
GPIOC->ODR ^= (1 << 13);
  +
is used (compiled and burned successfully)
  +
  +
'''Status'''
  +
'''1)''' $st-flash write timer_gpio_out.bin 0x8000000
  +
2012-02-09T23:25:54 INFO src/stlink-common.c: Loading device parameters....
  +
2012-02-09T23:25:54 WARN src/stlink-common.c: unknown chip id! 0
  +
stlink_sram_flash() == -1
  +
make: *** [write] Error 255
  +
  +
'''2)''' hold the Reset button while:
  +
$./st-util
  +
2012-02-25T16:00:42 INFO src/stlink-common.c: Loading device parameters....
  +
2012-02-25T16:00:42 WARN src/stlink-common.c: unknown chip id! 0xe0042000
  +
2012-02-25T16:00:42 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
  +
Chip ID is 00000000, Core ID is 00000000.
  +
KARL - should read back as 0x03, not 60 02 00 00
  +
init watchpoints
  +
Listening at *:4242...
  +
  +
'''3)''' $st-flash erase
  +
2012-02-09T23:28:01 INFO src/stlink-common.c: Loading device parameters....
  +
2012-02-09T23:28:01 WARN src/stlink-common.c: unknown chip id! 0xe0042000
  +
Mass erasing
  +
  +
'''4)''' If I hold the Reset button while erasing:
  +
ahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
  +
2012-02-09T23:28:28 INFO src/stlink-common.c: Loading device parameters....
  +
2012-02-09T23:28:28 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
  +
2012-02-09T23:28:28 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0 bytes (0 KiB) in pages of 256 bytes
  +
Mass erasing
  +
  +
'''5)''' If I hold the Reset button while flashing:
  +
dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
  +
../../flash/flash write lcd.bin 0x08000000
  +
2012-02-10T14:13:21 INFO src/stlink-common.c: Loading device parameters....
  +
2012-02-10T14:13:21 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
  +
2012-02-10T14:13:21 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
  +
2012-02-10T14:13:21 INFO src/stlink-common.c: Attempting to write 7332 (0x1ca4) bytes to stm32 address: 134217728 (0x8000000)
  +
2012-02-10T14:13:21 WARN src/stlink-common.c: pecr.pelock not clear (0x7)
  +
2012-02-10T14:13:21 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
  +
stlink_fwrite_flash() == -1
  +
make: *** [write] Error 255
  +
  +
'''Solution'''
  +
'''1)''' hold the Reset button while:
  +
$ st-util
  +
2013-03-23T15:51:17 INFO src/stlink-common.c: Loading device parameters....
  +
2013-03-23T15:51:17 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
  +
2013-03-23T15:51:17 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
  +
Chip ID is 00000410, Core ID is 1ba01477.
  +
KARL - should read back as 0x03, not 60 02 00 00
  +
init watchpoints
  +
Listening at *:4242...
  +
  +
'''2)''' Next you will need to launch gdb (in a new terminal) from the tools directory
  +
and make use of the compiled binary that you pulled created earlier during the "make all".
  +
$ tools/arm-2011.03/bin/arm-none-eabi-gdb -q build/fw_coptercontrol/fw_coptercontrol.elf
  +
Reading symbols from
  +
/home/xxx/OpenPilot/build/fw_coptercontrol/fw_coptercontrol.elf...done.
  +
(gdb) target remote localhost:4242
  +
Remote debugging using localhost:4242
  +
0x0800010c in ?? ()
  +
(gdb) bt
  +
#0 0x0800010c in ?? ()
  +
#1 0xffffffff in ?? ()
  +
Backtrace stopped: frame did not save the PC
  +
(gdb) i r
  +
r0 0x0 0
  +
r1 0xa5a5a5a5 2779096485
  +
r2 0x0 0
  +
r3 0x200002d4 536871636
  +
r4 0x20000cd0 536874192
  +
r5 0xa5a5a5a5 2779096485
  +
r6 0xa5a5a5a5 2779096485
  +
r7 0xa5a5a5a5 2779096485
  +
r8 0xa5a5a5a5 2779096485
  +
r9 0xa5a5a5a5 2779096485
  +
r10 0xa5a5a5a5 2779096485
  +
r11 0xa5a5a5a5 2779096485
  +
r12 0xa5a5a5a5 2779096485
  +
sp 0x20000938 0x20000938
  +
lr 0xffffffff 4294967295
  +
pc 0x800010c 0x800010c
  +
fps 0xaddeadde 2917051870
  +
cpsr 0x1000000 16777216
  +
(gdb) c
  +
Continuing.
  +
  +
Hit CTRL+C to test breakpoints and use l to see line numbers
  +
  +
(gdb) c
  +
Continuing.
  +
^C
  +
Program received signal SIGTRAP, Trace/breakpoint trap.
  +
0x080039a0 in nmeaProcessGPRMC (GpsData=0xa5a5a5a5, gpsDataUpdated=<value optimized out>, param=0x20000cd0,
  +
nbParam=<value optimized out>) at ../Modules/GPS/NMEA.c:559
  +
559 GpsData->Heading = NMEA_real_to_float(param[8]);
  +
(gdb) l
  +
  +
I quitted the gdb when i found that the board worked again. Again you can easily verify the firmware.
  +
  +
There are some situations solved by erasing or flashing while holding the reset button(black), but it does not work in our issue.
  +
  +
'''Refer to link''' :
  +
http://forums.openpilot.org/topic/20173-regrouping-on-various-stm32f4discovery-swd-debugging-for-oplink-revo-cc3d/
  +
  +
* Test of STM32 printf
  +
Refer to link : http://vedder.se/2012/07/usb-serial-on-stm32f4/
  +
  +
We have tried the program for the STM32F4 Discovery that uses the USB-CDC class to show up as an virtual serial port.
  +
It has routed the write system call to use this port, so the stdio printf function will print directly to this serial port.
  +
After have uploaded the program to the STM32F4 discovery and plug in a micro-USB cable to the port next to the audio jack.
  +
The serial port should show up as /dev/ttyACM0 on most GNU/Linux distributions, such as Ubuntu.
  +
Start a serial port terminal, such as gtkterm (sudo apt-get install gtkterm on Debian/Ubuntu), and open ttyACM0.
  +
As the following shot-screen :
  +
[[File:PythonSurSTM32_printf_shotscreen.png|800px]]
  +
  +
== Week 5 (10/02 - 17/02) ==
  +
  +
* SRS document [[Proj-2013-2014-Python-STM32F4:SRS]]
  +
* build and learn Project STM32Plus
  +
  +
== Week 6-8 (17/02 - 10/03) ==
  +
* The first version of the program
  +
We have finished the first version of the program. In order to trait the text easier, we have made the choice of using TCL script language.
  +
The file structrue of the project is shown as bellow:
  +
[[File:PythonSurSTM_file_struct.png|900px]]
  +
'''py2stm.tcl''' : executable file, the main program of the project;
  +
'''print''' : directory, the library and .o files corresponding to realise printf function;
  +
'''shedskin_lib''' : directory, the modified library of shedskin;
  +
'''defaut''' : necessary files for compiling and executing on STM (link file, the file who realise the functions of low level, etc)
  +
  +
'''Needed Library & Program''' : STM32Plus, Arm-gcc, STLink. These paths are all defined at the beginning of the file '''py2stm.tcl'''.
  +
With the help of this program, from a python source code, we could translate, generate project,
  +
and download the compiled project to the card only with one command.
  +
  +
The program work flow is shown as the following:
  +
[[File:PythonSurSTM_flow_chart.png|400px]]
  +
To support arm-g++ compiling, we have modified the library of shedskin. We have deleted the corresponding code of GC and PCRE.
  +
Instead of using GC, we have included the library of STM32Plus to support the fonctions of malloc, std::string, etc.
  +
  +
The usage of the program is shown bellow:
  +
[[File:PythonSurSTM_usage.png|900px]]
  +
  +
an example:
  +
[[File:PythonSurSTM_compile.png|900px]]
  +
In the make file, we will compile the corresponding files of ShedSkin library, the needed low level functions,
  +
and link the stm32plus library. When we choose Deubg Mode, we will also need to link the STM Common library.
  +
  +
With the option -b, the compiled program for stm will be burned to the card when finishing compile.
  +
[[File:PythonSurSTM_burn.png|900px]]
  +
  +
When there's a error (the python file doesn't exist)
  +
[[File:PythonSurSTM_no_file.png|900px]]
  +
  +
With the option -d, the function printf will be supported in the generated project.
  +
We have defined some low level functions in the file print/syscall.c to support printf, and we have done an redirection of the USB.
  +
The content of the printf will be sent to the USB, so users could use gtkterm to open the port ttyACM0 to have look at it and debug.
  +
The device will be found after the burn as following:
  +
[[File:PythonSurSTM_dev.png|900px]]
  +
  +
With the help of gtkterm ( or other visual tools ), we could choose the port ttyACM0, and see the content of the printf:
  +
[[File:PythonSurSTM_gtkterm.png|900px]]
  +
  +
To support the fonction printf, we have used arm-gcc and arm-g++ in the same time.
  +
The reason is that, most of the examples of STM32 are in C ( STM official examples included ), In this project,
  +
the code translated by shedskin is in CPP, so we have to face up to the difficulty of using arm-gcc and arm-g++.
  +
We have used extern "C" {...} to compile the printf corresponding CPP code.
  +
If not, the linker will not be able the find the reference of the calling of C functions.
  +
  +
For this function, during the executing of the program, we will not copy the source code of the printf to the generated project,
  +
we compile the printf corresponding fonctions only once, the .o files will be in the directory of py2stm/print.
  +
We think these functions are diffrent to the copied low level functions, they are not part of the genereated project,
  +
so we compile only once and we reuse them when linking.
  +
  +
For the reason of the redirection of USB, every time after we download the program to the card,
  +
we could not download normally for another time. In this case, we could run stlink/st-util when
  +
clicking the reset button of the card, then we will be able to download again.
  +
[[File:PythonSurSTM_stlink.png|900px]]
  +
  +
== Week 9-11 (10/03 - 31/03) ==
  +
  +
'''Debug'''
  +
We have fixed some bugs of no-existed head files, not found function definitions.
  +
We have resorved the problem of exception and print in the source files.
  +
  +
'''Evaluation'''
  +
  +
We have tried all the examples in the project Shedskin, we have get the evaluation result:
  +
For 117 files (.py) :
  +
0,1,2,3,4,5,6,7,8,9,10,11,12,13,15,16,18,19,20,21,22,23,24,25,26,28,31,32,33,36,38,40,43,44,45,
  +
46,50,52,53,54,55,56,59,60,64,69,71,75,76,77,78,79,81,82,83,84,86,88,89,93,94,95,97,98,99,100,102,
  +
103,104,105,106,107,108,109,110,111,112,113,114,115,118,119,120,123,124,126,127,129,130,132,133,
  +
134,137,138,139,140,141,142,143,144,146,147,148,152,155,156,157,158,161,162,167,168,170,175,176,183,187
  +
We have finished the compilation.
  +
  +
For 10 fichiers (.py):
  +
122,131,135,150,159,160,163,164,172,173
  +
We could not finish the compilation for the reason of the using of system time.
  +
  +
For 14 files (.py):
  +
29,30,37,125,128,136,151,153,154,165,166,171,190,195
  +
We could not finish the compilation for the reason of the using of iostream of files.
  +
  +
For 13 fichiers (.py):
  +
39,51,177,180,181,182,184,192,193,194,196,198,199
  +
Shedskin could not support their translation.
  +
  +
For 12 files (.py):
  +
169,174,179,185,186,188,189,191,197,200,201,202
  +
We could not finish the compilation for different reasons.
  +
  +
== Week 12 (31/03 - 07/04) ==
  +
Report Writing
  +
  +
[[Media:PythonSurSTM_Rapport.pdf|Report]]
  +
  +
[[Media:PythonSurSTM_Soutenance.pdf|PowerPoint]]

Latest revision as of 17:25, 6 February 2016

Introduction

Python_sur_STM32F4


Team


Objectives

Software Requirements Specification (SRS)

The SRS document:


Points à traiter

  • Modidification des Makefile
 utilisation de arm-none-eabi-g++ et des bonnes options 
 https://launchpad.net/gcc-arm-embedded
  • support STL
  Voir https://github.com/andysworkshop/stm32plus
  à voir aussi 
  uSTL http://msharov.github.io/ustl/
  • Lib C
Voir newlib et newlib-nano
https://launchpad.net/gcc-arm-embedded

 from gcc-arm-embedded source 
 https://launchpadlibrarian.net/160487135/readme.txt

* C Libraries usage *

This toolchain is released with two prebuilt C libraries based on newlib:
one is the standard newlib and the other is newlib-nano for code size.
To distinguish them, we rename the size optimized libraries as:

  libc.a --> libc_s.a
  libg.a --> libg_s.a

To use newlib-nano, users should provide additional gcc link time option:
 --specs=nano.specs

Nano.specs also handles two additional gcc libraries: libstdc++_s.a and
libsupc++_s.a, which are optimized for code size.

For example:
$ arm-none-eabi-gcc src.c --specs=nano.specs $(OTHER_OPTIONS)

This option can also work together with other specs options like
--specs=rdimon.specs

Please be noticed that --specs=nano.specs is a linker option. Be sure
to include in linker option if compiling and linking are separated.

** additional newlib-nano libraries usage

Newlib-nano is different from newlib in addition to the libraries' name.
Formatted input/output of floating-point number are implemented as weak symbol.
If you want to use %f, you have to pull in the symbol by explicitly specifying
"-u" command option.
   
  -u _scanf_float
  -u _printf_float

e.g. to output a float, the command line is like: 
$ arm-none-eabi-gcc --specs=nano.specs -u _printf_float $(OTHER_LINK_OPTIONS)

For more about the difference and usage, please refer the README.nano in the
source package.


  • Garbage Collection
 Voir  tinygc http://tinygc.sourceforge.net/
 à voir aussi celui de micropython
  • libprce
 Voir T-Rex is a minimalistic regular expression http://tiny-rex.sourceforge.net/ http://sourceforge.net/projects/tiny-rex/

Progress

project start : 13/01/2014

Week 1 (13/01 - 19/01)

  • Project discovery
  • Research of related projects


Week 2 (20/01 - 26/01)

  • STM32 develop environment
   Add USB device
       Create a new udev rule in /etc/udev/rules.d/45-usb-stlink-v2.rules: 
       SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="660", GROUP="plugdev"
       To reboot :
       $ sudo service udev restart
   
   Download the GNU/ARM toolchain
       Download the Linux current installation tarball from 
       https://launchpad.net/gcc-arm-embedded/+download
       $ tar -xvjf gcc-arm-none-eabi-xxxxxxxxxxxxxxxxxx-linux.tar.bz2
       Add the fallowing to your ~/.bashrc
       export PATH=$PATH:~/xxxxxxx/gcc-arm-none-eabi-xxxxxxxxx/bin
       $ source ~/.bashrc
       To check :
       $ arm-none-eabi-gcc --version
       If you get an error message “bash : ... file does not exist”. 
       Maybe it is caused by the difference between 32bit and 64bit system. Try :
       $ sudo apt-get install ia32-libs*
   
   Download and Build STLINK
       STLINK is for programming and debugging firmware.
       you'll first need to install a couple of packages:
       $ sudo apt-get install autoconf pkg-config libusb-1.0 git
       Retrieve a copy of the STLINK source:
       $ git clone https://github.com/texane/stlink.git
       Build the code following the instructions in the README, with:
       $ ./autogen.sh
       $ ./configure
       $ make
       As a sanity check, look in ~/st-link and you should see st-util, st-flash, etc... 
       You may check if the board could be connected by execute st-util. 
       If it does not work please confirm if the rule you added in the first step corresponds your system.
   
   Refer to link : http://www.wolinlabs.com/blog/linux.stm32.discovery.gcc.html
  • Try the official examples of ST on the cards
   To avoid using the commercial software IDE and understand better, We decided to develop on Linux for this project.
   During the tries, for certain examples, we've got different results on STM32F407 and STM32F401. 
   We choose STM32F407 as the hardware for the following developement.


Week 3 (27/01 - 02/02)

  • Test Project MicroPython
  • Test Project Shedskin
  • STM32 hardware

PythonSurSTM32 Hardware 1.png

PythonSurSTM32 Hardware 2.png


Week 4 (02/02 - 09/02)

  • STM32 breakdown situation & solution
 Cause Reason
   After 
   RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;
   GPIOC->MODER = 0x04000000;
   GPIOC->ODR ^= (1 << 13);
   is used (compiled and burned successfully)
   
 Status
   1) $st-flash write timer_gpio_out.bin 0x8000000
   2012-02-09T23:25:54 INFO src/stlink-common.c: Loading device parameters....
   2012-02-09T23:25:54 WARN src/stlink-common.c: unknown chip id! 0
   stlink_sram_flash() == -1
   make: *** [write] Error 255
   
   2) hold the Reset button while: 
   $./st-util
   2012-02-25T16:00:42 INFO src/stlink-common.c: Loading device parameters....
   2012-02-25T16:00:42 WARN src/stlink-common.c: unknown chip id! 0xe0042000
   2012-02-25T16:00:42 INFO src/stlink-sg.c: Successfully opened a stlink v1 debugger
   Chip ID is 00000000, Core ID is 00000000.
   KARL - should read back as 0x03, not 60 02 00 00
   init watchpoints
   Listening at *:4242...
   
   3) $st-flash erase
   2012-02-09T23:28:01 INFO src/stlink-common.c: Loading device parameters....
   2012-02-09T23:28:01 WARN src/stlink-common.c: unknown chip id! 0xe0042000
   Mass erasing
   
   4) If I hold the Reset button while erasing:
   ahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ ../../flash/flash erase
   2012-02-09T23:28:28 INFO src/stlink-common.c: Loading device parameters....
   2012-02-09T23:28:28 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
   2012-02-09T23:28:28 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0 bytes (0 KiB) in pages of 256 bytes
   Mass erasing
   
   5) If I hold the Reset button while flashing:
   dahl@ubuntu:~/Desktop/3/stlink/example/32l_lcd$ make write
   ../../flash/flash write lcd.bin 0x08000000
   2012-02-10T14:13:21 INFO src/stlink-common.c: Loading device parameters....
   2012-02-10T14:13:21 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10386416
   2012-02-10T14:13:21 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
   2012-02-10T14:13:21 INFO src/stlink-common.c: Attempting to write 7332 (0x1ca4) bytes to stm32 address: 134217728 (0x8000000)
   2012-02-10T14:13:21 WARN src/stlink-common.c: pecr.pelock not clear (0x7)
   2012-02-10T14:13:21 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
   stlink_fwrite_flash() == -1
   make: *** [write] Error 255
 
 Solution
   1) hold the Reset button while:
   $ st-util
   2013-03-23T15:51:17 INFO src/stlink-common.c: Loading device parameters....
   2013-03-23T15:51:17 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
   2013-03-23T15:51:17 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
   Chip ID is 00000410, Core ID is 1ba01477.
   KARL - should read back as 0x03, not 60 02 00 00
   init watchpoints
   Listening at *:4242...
   
   2) Next you will need to launch gdb (in a new terminal) from the tools directory 
   and make use of the compiled binary that you pulled created earlier during the "make all". 
   $ tools/arm-2011.03/bin/arm-none-eabi-gdb -q build/fw_coptercontrol/fw_coptercontrol.elf
   Reading symbols from 
   /home/xxx/OpenPilot/build/fw_coptercontrol/fw_coptercontrol.elf...done.
   (gdb) target remote localhost:4242
   Remote debugging using localhost:4242
   0x0800010c in ?? ()
   (gdb) bt
   #0 0x0800010c in ?? ()
   #1 0xffffffff in ?? ()
   Backtrace stopped: frame did not save the PC
   (gdb) i r
   r0 0x0 0
   r1 0xa5a5a5a5 2779096485
   r2 0x0 0
   r3 0x200002d4 536871636
   r4 0x20000cd0 536874192
   r5 0xa5a5a5a5 2779096485
   r6 0xa5a5a5a5 2779096485
   r7 0xa5a5a5a5 2779096485
   r8 0xa5a5a5a5 2779096485
   r9 0xa5a5a5a5 2779096485
   r10 0xa5a5a5a5 2779096485
   r11 0xa5a5a5a5 2779096485
   r12 0xa5a5a5a5 2779096485
   sp 0x20000938 0x20000938
   lr 0xffffffff 4294967295
   pc 0x800010c 0x800010c
   fps 0xaddeadde 2917051870
   cpsr 0x1000000 16777216
   (gdb) c
   Continuing.
   
   Hit CTRL+C to test breakpoints and use l to see line numbers
   
   (gdb) c
   Continuing.
   ^C
   Program received signal SIGTRAP, Trace/breakpoint trap.
   0x080039a0 in nmeaProcessGPRMC (GpsData=0xa5a5a5a5, gpsDataUpdated=<value optimized out>, param=0x20000cd0,
   nbParam=<value optimized out>) at ../Modules/GPS/NMEA.c:559
   559 GpsData->Heading = NMEA_real_to_float(param[8]);
   (gdb) l
   
 I quitted the gdb when i found that the board worked again. Again you can easily verify the firmware.
   
 There are some situations solved by erasing or flashing while holding the reset button(black), but it does not work in our issue.
   
 Refer to link : 
   http://forums.openpilot.org/topic/20173-regrouping-on-various-stm32f4discovery-swd-debugging-for-oplink-revo-cc3d/
  • Test of STM32 printf
 Refer to link : http://vedder.se/2012/07/usb-serial-on-stm32f4/
 
 We have tried the program for the STM32F4 Discovery that uses the USB-CDC class to show up as an virtual serial port. 
 It has routed the write system call to use this port, so the stdio printf function will print directly to this serial port.
 After have uploaded the program to the STM32F4 discovery and plug in a micro-USB cable to the port next to the audio jack.
 The serial port should show up as /dev/ttyACM0 on most GNU/Linux distributions, such as Ubuntu.
 Start a serial port terminal, such as gtkterm (sudo apt-get install gtkterm on Debian/Ubuntu), and open ttyACM0. 
 As the following shot-screen :
 PythonSurSTM32 printf shotscreen.png

Week 5 (10/02 - 17/02)

Week 6-8 (17/02 - 10/03)

  • The first version of the program

We have finished the first version of the program. In order to trait the text easier, we have made the choice of using TCL script language. The file structrue of the project is shown as bellow: 

 PythonSurSTM file struct.png
 py2stm.tcl    : executable file, the main program of the project;
 print             : directory, the library and .o files corresponding to realise printf function;
 shedskin_lib : directory, the modified library of shedskin;
 defaut          : necessary files for compiling and executing on STM (link file, the file who realise the functions of low level, etc)
 
 Needed Library & Program : STM32Plus, Arm-gcc, STLink. These paths are all defined at the beginning of the file py2stm.tcl.
 With the help of this program, from a python source code, we could translate, generate project, 
 and download the compiled project to the card only with one command.

The program work flow is shown as the following: 

 PythonSurSTM flow chart.png
 To support arm-g++ compiling, we have modified the library of shedskin. We have deleted the corresponding code of GC and PCRE.
 Instead of using GC, we have included the library of STM32Plus to support the fonctions of malloc, std::string, etc.

The usage of the program is shown bellow: 

 PythonSurSTM usage.png
 
 an example:
 PythonSurSTM compile.png
 In the make file, we will compile the corresponding files of ShedSkin library, the needed low level functions, 
 and link the stm32plus library. When we choose Deubg Mode, we will also need to link the STM Common library.
 
 With the option -b, the compiled program for stm will be burned to the card when finishing compile.
 PythonSurSTM burn.png
 
 When there's a error (the python file doesn't exist)
 PythonSurSTM no file.png
 
 With the option -d, the function printf will be supported in the generated project.
 We have defined some low level functions in the file print/syscall.c to support printf, and we have done an redirection of the USB.
 The content of the printf will be sent to the USB, so users could use gtkterm to open the port ttyACM0 to have look at it and debug.
 The device will be found after the burn as following:
 PythonSurSTM dev.png
 
 With the help of gtkterm ( or other visual tools ), we could choose the port ttyACM0, and see the content of the printf:
 PythonSurSTM gtkterm.png
 
 To support the fonction printf, we have used arm-gcc and arm-g++ in the same time. 
 The reason is that, most of the examples of STM32 are in C ( STM official examples included ), In this project, 
 the code translated by shedskin is in CPP, so we have to face up to the difficulty of using arm-gcc and arm-g++.
 We have used extern "C" {...} to compile the printf corresponding CPP code. 
 If not, the linker will not be able the find the reference of the calling of C functions.
 
 For this function, during the executing of the program, we will not copy the source code of the printf to the generated project,
 we compile the printf corresponding fonctions only once, the .o files will be in the directory of py2stm/print. 
 We think these functions are diffrent to the copied low level functions, they are not part of the genereated project,
 so we compile only once and we reuse them when linking.

 For the reason of the redirection of USB, every time after we download the program to the card, 
 we could not download normally for another time. In this case, we could run stlink/st-util when 
 clicking the reset button of the card, then we will be able to download again.
 PythonSurSTM stlink.png

Week 9-11 (10/03 - 31/03)

 Debug
 We have fixed some bugs of no-existed head files, not found function definitions.
 We have resorved the problem of exception and print in the source files.

 Evaluation
 
 We have tried all the examples in the project Shedskin, we have get the evaluation result:
 For 117 files (.py) : 
 0,1,2,3,4,5,6,7,8,9,10,11,12,13,15,16,18,19,20,21,22,23,24,25,26,28,31,32,33,36,38,40,43,44,45,
 46,50,52,53,54,55,56,59,60,64,69,71,75,76,77,78,79,81,82,83,84,86,88,89,93,94,95,97,98,99,100,102,
 103,104,105,106,107,108,109,110,111,112,113,114,115,118,119,120,123,124,126,127,129,130,132,133,
 134,137,138,139,140,141,142,143,144,146,147,148,152,155,156,157,158,161,162,167,168,170,175,176,183,187
 We have finished the compilation.
 
 For 10 fichiers (.py):
 122,131,135,150,159,160,163,164,172,173
 We could not finish the compilation for the reason of the using of system time.
  
 For 14 files (.py):
 29,30,37,125,128,136,151,153,154,165,166,171,190,195
 We could not finish the compilation for the reason of the using of iostream of files.
 
 For 13 fichiers (.py):
 39,51,177,180,181,182,184,192,193,194,196,198,199 
 Shedskin could not support their translation.
 
 For 12 files (.py):
 169,174,179,185,186,188,189,191,197,200,201,202
 We could not finish the compilation for different reasons.

Week 12 (31/03 - 07/04)

Report Writing

Report

PowerPoint

Retrieved from "https://air.imag.fr/index.php?title=Proj-2013-2014-Python-STM32F4&oldid=26725"