I am new to this list and to RIOT. Can someone tell me how progress is going for the above board that is listed as a “supported” board, because I don’t see any
board support for the STM32 in the relevent part of the source tree.
If someone has something even half completed I would like to have it and possibly contribute.
I have hardware arriving in the next few days.
Can someone tell me how progress is going for the above board that is listed as a “supported” board, because I don’t see any
board support for the STM32 in the relevent part of the source tree.
The above mentioned board was supported by RIOTs thirdparty repositories [1, 2]. We are however in the middle of migrating these repositories into RIOTs master. For this I created a new, cleaned up pull request for the stm32f4discovery [3]. This includes the basic needed functionality, there are however some testing efforts still to be done.
On top of this efforts are currently on the way to implement a low-level SPI driver for this board.
For getting started Peter was so nice to create a how-to in the RIOT wiki [4].
If someone has something even half completed I would like to have it and possibly contribute.
I have hardware arriving in the next few days.
You are more then welcome to look at the pending PR and do some extensive testing. Checkout the PR and let us know of any bugs and problems you encounter!
I got the stm32f4 build going on the command line (used the ipc_pingpong as an example).
Trying to setup eclipse to do the same by following the guide in the wiki.
In the section on Including “The Riot source” tree into the gui, I ran into grief as it stated it could not link the Riot folder when there was a project allready
within it … i.e examples/ipc_pingpong which is the example I got going …
Is there another way of getting the full tree in there …
it turned out that the tutorial you are talking about is not up to date, cause the RIOT source-tree changed. @BytesGalore will work on it in the next week and update the wiki page. This will (re)allow development with Eclipse and additionally adjust it for stm-boards.
Furthermore debugging should be possible for the stm32f4discovery board. We'll have a look at this also. It's a fun coincidence you have this issue, cause we just discussed fixing it the last days...
I have debugging working ok …ish in eclipse (luna) my only real issue is something to do with reset.
If I don’t hard reset the board (black button) before each GDB session, I can get into a state where after startup.c and before main() the ubit goes into a isr_hard_fault().
But as long as I remember to do the reset it is fine.
I have the eclipse environment setup to do a 5 second reset/halt, but that doesn’t seem to do anything …
I am also a newbie to the Riot world and am working with the STM32F4 board. I am trying to get the IPC pingpong example running (I have modified the code slightly to blink an LED). I had the same problem with the isr_hard_fault(). I think this fault is related to how the gdb debugger is running – I did not have a problem if I was not using the debugger. I needed to add “monitor reset” to GDB runtime options. My understanding is that this command clears some of the buffers that GDB uses and my guess is that these buffers also get cleared when you hard reset the STM.
seems like you found the updated tutorial for debugging ARM with Eclipse? Great! To be honest I also just installed Eclipse for using with GDB. We'll have a look at this.
I wrote the tutorial about configuring Eclipse to run/debug the stm32f4 board so I am glad if you understood everything ! Eclipse is also sometimes unstable for me when I debug, so as you said we need to reset the board with the black button. That's why I created some tools to clean some process and init again these process then, to make it a bit more comfortable.
By the way, I did not catch what is your exact problem, is it just annoying for you having to hard reset for each debug session or have you a real problem because of this hard reset ?
Hi everyone,
Have anyone tried using openOCD as a gdb server to debug with RIOT ? As GNU ARM eclipse Plug-ins will be installed when we follow [1], we can use its “The OpenOCD debugging Eclipse plug-in” to debug with openOCD. Just follow [2] [3] [4] to setup openOCD and the plugin. (there only one thing that we should take care is the configuration scripts in other options field. For stm32f4discovery board it’s should be -f board/stm32f4discovery.cfg, or -f interface/(your debugger script) -f target/(your cpu script) in a general way. Those script can be found in openOCD installation folder)
I have using openOCD for several months to debug my STM32F1 board with RIOT and it’s seem to be quite fine.
I am not using openocd, I am using the st-util, st-flash tools to program and use GDB on, these tools don’t support the “monitor …” comands I don’t think.
I think that is an openocd thing …
I want to know how to get rid of the hard fault issue with these tools …
As a quick test I uploaded and debugged a totally different application/rtos and it did not have the issue. Debugged just fine.