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. >> >>> >> >> >> >> >> > >> > >> >> >