Thanks all, merged. --Pekka On 2014–09–13, at 23:56 , Eero Hakala <eero.k.hakala@xxxxxxxxx> wrote: > Jep, now Ivans code runs smoothly on nucleo board, I would never have guessed > to use the bin-file...! > My command line: > sudo ./st-flash --reset write > ../../Ell-i/ng-elli/ivan/Runtime/stm32/build/hardware/stm32f334nucleo/sketch.bin > 0x8000000 > > > Where can you get the gdb-version for arm? > > > -eero- > > > On Sat, Sep 13, 2014 at 6:33 PM, Ivan Raul <supra.material@xxxxxxxxx> wrote: > Hi to all, > > To flash the nucleo the first thing is to install the latest version of > texane/stlink, it already has Lari's addition merged, it works smoothly! > > mkdir texane > cd texane > git clone https://github.com/texane/stlink.git > cd stlink/ > ./autogen.sh > ./configure > make > sudo make install > > Now, to flash, the .bin file is the one used (I lost some time trying to make > it work by flashing the .hex ...) > st-flash write sketch.bin 0x8000000 > #if it complains about " WARN src/stlink-usb.c: Error -3 opening ST-Link/V2 > device ...", run it with sudo > sudo st-flash write sketch.bin 0x8000000 > > In order to see the green LED blink, it is necessary to configure pin 13: > ----------------------- > #include <Arduino.h> > > void setup() { > pinMode(13, OUTPUT); > } > > void loop() { > digitalWrite(13, 1); > for (volatile int i = 0; i < 100000; i++) > ; > digitalWrite(13, 0); > for (volatile int i = 0; i < 100000; i++) > ; > } > ------------------ > > Additionally, if you want to debug a little and see how the program executes: > > sudo st-util > > Then, it will show the port " Listening at *:4242..." > now, open gdb with the elf file as input > > arm-none-eabi-gdb sketch > > Now, in the debug command line "(gdb)" > > target remote localhost:4242 > > It will show that it is halted in the first instruction of the reset handler, > for me shows: > Reset_Handler () at > Runtime/stm32/build/../system/stm32/src/startup_stm32f334xx.c:287 > 287 __asm__ volatile ("mov sp, %0" : : "r" (stack)); > > You can play to step to the next instruction > > step > > Or continue the execution > > continue > > If you command continue, it will run normally and you will notice the LED > blinking > To halt the execution after continue, press the classic > > Ctrl+C > > You can check the registers: > > info reg > > Or check the information at certain address, for example: > > (gdb) x 0x0 > 0x0: 0x20003000 > (gdb) x 0x8000000 > 0x8000000 <g_pfnVectors>: 0x20003000 > > What happens here is that the first section of flash is also mapped to the > address 0x00000000, to enable the initialization to find the vectors at the > very beginning of the memory. What is shown there is the initial value of the > stack pointer. > > -------------------------------------- > > Regarding the initialisation procedure, I checked removing the copying of the > linker _estack provided variable to the stack. It is not necessary, the stack > pointer is initalised from the init vectors (at least with the st32f334). The > stack pointer is identical without the imperative assignment: > > With copying: > sp 0x20002ff0 0x20002ff0 > lr 0x8000197 134218135 > > Without copying > sp 0x20002ff0 0x20002ff0 > lr 0x8000197 134218135 > > ------------------------------------- > > BR, Ivan > > > > > > With Warm Regards, Ivan Raul > > On Fri, Sep 12, 2014 at 7:49 PM, Pekka Nikander <pekka.nikander@xxxxxx> wrote: > cd /tmp > git clone https://github.com/supramaterial/Runtime > cd Runtime/stm32/build > make sketch.cpp > # edit sketch.cpp to blink a led; see below > make > > That creates hardware/stm32f334nucleo/sketch.{hex,bin} > > How to flash that to the STM32F334nucleo, I don't know exactly. Lari knows, > he's done that. > > Here is a simple sketch for a LED in pin #3 > > ----------------------- > #include <Arduino.h> > > void setup() { > pinMode(3, OUTPUT); > } > > void loop() { > digitalWrite(3, 1); > for (volatile int i = 0; i < 10000; i++) > ; > digitalWrite(3, 0); > for (volatile int i = 0; i < 10000; i++) > ; > } > ------------------ > > YMMV. > > --Pekka > > > On 2014–09–12, at 20:30 , otso@xxxxxxxxxxxx wrote: > > > I have some time over weekend as well as the hardware, please send me the > > details of what has to be tested and how "works" is defined. I'll test it > > if I get more pressing issues with the hardware in order. > > > > -otso > > > >> Could someone please test this on a real STM32F334? If it works, I'll > >> merge it. > >> > >> --Pekka > >> > >> Begin forwarded message: > >> > >>> From: supramaterial <notifications@xxxxxxxxxx> > >>> Subject: [Runtime] Added support for STM32F334 emulator (#24) > >>> Date: 11 Sep 2014 1:05:12 GMT+3 > >>> To: Ell-i/Runtime <Runtime@xxxxxxxxxxxxxxxxxx> > >>> Reply-To: Ell-i/Runtime > >>> <reply+i-42466605-35e7ed84685e7220999a32a51c47bf889c73a76d-681239@xxxxxxxxxxxxxxxx> > >>> > >>> Please, test on real hardware, I just tested in the emulator. > >>> > >>> You can merge this Pull Request by running > >>> > >>> git pull https://github.com/supramaterial/Runtime master > >>> Or view, comment on, or merge it at: > >>> > >>> https://github.com/Ell-i/Runtime/pull/24 > >>> > >>> Commit Summary > >>> > >>> Add: C initialisation and headers for STM32F334 > >>> Add: Emulator SCB support for STM32F334 > >>> Add: Compile flags for emulator shared library for STM32F334 > >>> File Changes > >>> > >>> M stm32/emulator/inc/SCB.h (2) > >>> M stm32/make/emulator.mk (5) > >>> M stm32/make/system_lib.mk (2) > >>> A stm32/system/stm32/inc/system_stm32f3xx.h (76) > >>> D stm32/system/stm32/src/startup_stm32f334x8.S (421) > >>> A stm32/system/stm32/src/startup_stm32f334xx.c (328) > >>> Patch Links: > >>> > >>> https://github.com/Ell-i/Runtime/pull/24.patch > >>> https://github.com/Ell-i/Runtime/pull/24.diff > >>> — > >>> Reply to this email directly or view it on GitHub. > >>> > >> > >> > > > > > > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
