STM32F4Discovery

Hi There,

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.

Many Thanks, Bernie

Hi Bernie,

Welcome aboard :slight_smile:

There’s an open pull request by Hauke which appears to be almost complete: https://github.com/RIOT-OS/RIOT/pull/1191

Cheers, Ludwig

Hi Bernie,

Hi There,

I am new to this list and to RIOT.

First of all: Welcome 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.

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!

Cheers, Hauke

[1] [2] [3] [4]

Thanks for the welcome guys :slight_smile:

Hauke: Many thanks for the quick guide. That was very helpful.

Cheers,

Bernie

Hi again guys,

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.

I am getting the following error on linking …

Hi All,

I finally got a Riot project compiling in Eclipse …seems my Path variable had a syntax error …

I have another issue though following the guide here --> https://github.com/RIOT-OS/RIOT/wiki/Using-the-Eclipse-IDE-for-C-and-CPP-Developers%2C-Howto

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 …

Regards, Bernie

Hello Bernie,

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

Regards, Peter

Hi Peter,

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 …

Cheers,

Bernie

Hi Bernie,

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.

Cheers,

Abhinav

Hi Bernie,

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.

Cheers, Peter

Hi Bernie,

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 ?

Best regards,

Maxime

Bernard Mentink <bmentink@gmail.com> a écrit :

HiAbhinav, Can you use monitor reset with the st-LINK device? I know you can do this with openocd …

Cheers, Bernie

Hi Bernie,

I am using OpenOCD with the st-link USB driver and I the monitor reset seems to have solved this problem.

Rgds,

Abhinav

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

[1] https://github.com/RIOT-OS/RIOT/wiki/Using-the-Eclipse-IDE-for-C-and-CPP-Developers%2C-Howto

[2] http://gnuarmeclipse.livius.net/blog/debugger-install/

[3] http://gnuarmeclipse.livius.net/blog/openocd-install/ [4] http://gnuarmeclipse.livius.net/blog/openocd-debugging/

Hi Somaraju,

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.

It seems to be specific to riot …

Cheers,

Bernie

Hi Bernie,

just for your info: the stm32f4discovery was just merged into RIOTs master.

Cheers, Hauke

good work! Will test in the next days.

Best Christian