STM32F4-Discovery debug envirorment

[Boris_il_forte]

Hi!
I'm new on this forum, so i hope I've opened this topic in the correct location... if I'm wrong, I'm sorry... i Hope i'll will learn soon how to use this tool
I'm a Computer Science Engineering student, I've learned the "mythical" world of microcontrollers and ChibiOs/RT during a project at my university, and now I hope to use this awsome RTOS also for fun and "Industrial projects"
Ok, now I'll stop make you loosing time and start with my question
I've already set-up a basic chibiOs envirorment in eclipse, with CodeSourceryLite toolchain, and openocd to comunicate with the on-board stlink-v2, following some tutorials on this website and on the web...
All works fine... well... I should say only "works".

I've noticed some strange behaviours: firs of all, i must push the board reset button in order to let openocd connect with the board. I've tried already some version of openocd and this behaviour hasn't change yet.
the console output is the following:

Code: Select all

adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain
Info : clock speed 1000 kHz
Error: init mode failed
in procedure 'transport'
in procedure 'init'

The second point is that also the gdb connection seems to behave like openocd: i must push the reset button while connecting, connection fails and then i'll be able to launch again the gdb connection, this time succesfully. in this case, the console shows an error with the command target-extended.

this if I didn't push the reset button:

Code: Select all

Failed to execute MI command:
-target-select remote localhost:3333

Error message from debugger back end:
Remote connection closed
Remote connection closed

first time I start gdb:

Code: Select all

Failed to execute MI command:
load /path-to-executable/ch.elf 

Error message from debugger back end:
Error erasing flash with vFlashErase packet
Error erasing flash with vFlashErase packet

and then, the second time works...

aside from that, the debugger didn't work very well... it almost didn't work at all. that's not a huge problem, because as a java developer I'm used to debug via System.out/chprintf

anyone has suggestions? there is anyone that managed to get the stm32f4-discovery toolchain working perfectly on Linux?
I can post my configuration settings etc if needed...


Thanks for reading all this huge post, and sorry for my bad english

Boris

[Giovanni]

Hi,

Don't worry about the bad English, it can't be worse than mine.

OpenOCD can be problematic at times but I never experienced problems like the ones you reported, probably there is something wrong with your debug configuration.

Did you give ChibiStudio a try? it is a preconfigured Eclipse with all required extensions, the STM32 demos are already imported and ready to go, debug configurations are included.

Giovanni

[Tectu]

Hello Boris and welcome!

OpenOCD / GDB is configured in default mode that it doesn't do a reset when connecting. This allows to sneak into the CPU and read out the state in case of you get some strange errors. When it would reset your MCU, you'd be lost in tracking down mysterious behaviours. I don't know which flag it was, but there's some to make it reset at any connect.

However, the appropriate version is to execute mon reset halt (in GDB) after the initial connect and before you do a flash write. I'm not sure if your debugging problem is related to this. I'd say: Give it a try!

The problem that a initial, manual board reset is needed is something that more users are experiencing, personally, I never had this issue.


~ Tectu

[Boris_il_forte]

Hi,

Don't worry about the bad English, it can't be worse than mine.

it can be much worse xD

OpenOCD can be problematic at times but I never experienced problems like the ones you reported, probably there is something wrong with your debug configuration.
Did you give ChibiStudio a try? it is a preconfigured Eclipse with all required extensions, the STM32 demos are already imported and ready to go, debug configurations are included.

Giovanni

No, i've noticed it only...now... I think when i've started using chibios (about an year ago) there was only a plugin.
I'll give a try, although I personally prefer using only one eclipse envirorment for all my projects (java, c/c++, c, Chibios projects)

Hello Boris and welcome!

OpenOCD / GDB is configured in default mode that it doesn't do a reset when connecting. This allows to sneak into the CPU and read out the state in case of you get some strange errors. When it would reset your MCU, you'd be lost in tracking down mysterious behaviours. I don't know which flag it was, but there's some to make it reset at any connect.

However, the appropriate version is to execute mon reset halt (in GDB) after the initial connect and before you do a flash write. I'm not sure if your debugging problem is related to this. I'd say: Give it a try!

The problem that a initial, manual board reset is needed is something that more users are experiencing, personally, I never had this issue.


~ Tectu

I'm using this commands in the initialization:

Code: Select all

monitor reset halt -> i think this is the command you're talking about
monitor flash probe 0
monitor stm32f2x mass_erase 0

and this as run commands:

Code: Select all

monitor reset halt
continue

the rest of the configuration is the same reported in the Chibios guide.

openocd is launched with this arguments:

Code: Select all

 -f board/stm32f4discovery.cfg

I'm using openocd from git, compiled... yesterday, with ---enable-mantainer-mode flag and --enable-stlink-flag


as I've already said, i'm using Linux, Debian Testing.

I've tried with more that one discovery board, with differents computers (all debian), and all behaves the same way, I think because the configuration was very similar to the current one....

[Giovanni]

ChibiStudio is a normal Eclipse Juno, you can also do Java etc.

Giovanni

[Boris_il_forte]

ChibiStudio is a normal Eclipse Juno, you can also do Java etc.

Giovanni

I know, but ther's not a Debian repo of ChibiStudio xD
I'm a bit "closed" about this stuff...

however I've tried ChibiStudio, the first time it shows the same problems I've already noticed with my configuration, but then, when i flashed again the MCU with the demo in the workspace, it seems to work properly.

it seems to me that ther's something wrong when flashing the MCU, that makes openocd not recognising the board as an stm32-f4 board or something similar. Correct me please if i'm tellig stupid things, i didn't know anything about flashing MCU and how write protection works...
I'll try now to get my configuration working now, if there is a way to meke it working there's no reason to "hack" my board the way I used to xD
I'm not (already) been able to flash twice the MCU, because the secon time I've tried, i get this error:

Code: Select all

Variable references empty selection: ${project_loc}

I don't know if this is a common issue, or an issue of my workspace neither if i dowloaded an old version (I downloaded the last version on the topic about ChibiStudio on linux)
i'm wrong or it's already in a sort of alpha version? So seemed to me after searchig on sourceforge...


thank you so much for the help and your kindness


long life to ChibiOS! Just Amazing!


Boris

ps: "I used to hack my STM32F4-DISCOVERY board like you... Then I took an arrow in the knee"
Sorry, I just can't resist

[Giovanni]

You have to select the project (click on it) then launch OpenOCD from the external tools menu.

BTW, I use Eclipse under Ubuntu and there is no need of debs for that.

Giovanni

[Boris_il_forte]

You have to select the project (click on it) then launch OpenOCD from the external tools menu.

Folowing extactly your instruction worked. A bit strange behaviour for an eclipse launcher, however
Personally i think that if I click again the flash & run configuration, the launcher shuold work again no complaining... but I'm shure there are a lot of reasonable reasons (xD) to to that...

BTW, I use Eclipse under Ubuntu and there is no need of debs for that.

Giovanni

I know that... Most of my friends use it as a unpacked directory in /opt/ (or, worst, in the home :S).
when i asked they why they didn't use repositories, to get also automatic updates and tracking by apt, they say litterally:

"because the repo version is s***"

(debian eclipse version is the 3.8, not 4.x, debian is in freeze now, so they use a stable envirorment).

Despite that, i find using repo's is too comfortable, and i'll always prefer a - at least - working repo package to a zipped archive.

so, i'll break my head trying to "steal" the flash configuration to ChibiStudio

Thanks for all

Boris

[Boris_il_forte]

Sorry for double-posting...

I was trying to copy the configuration without success, so, i start thinking if that was an openocd issue.
So i tryed to import my project in the ChibiStudio workspace, copied one of the default configuration, modifying only the configuration name & project.

when i start it, i managed to flash sucessfully the MCU, but I still have reset problems...

some things I've noticed:
1) I'm using ChibiOs 2.4.2/3 (i've tried 2.4.3 before posting this) whereas the demos (that are working) are using 2.5.x
2) Just when i tell gdb to leave thebreakpoint I get in the console:

Code: Select all

Error: JTAG failure -4
Error: jtag status contains invalid mode value - communication failure
Polling target failed, GDB will be halted. Polling again in 100ms

this was happening even before, but I, stupidly, thinked was a "normal" behaviour... seeing some projects working without this, changed my mind.
So I've searched this string on google and I've found a site (I suppose I can't link it) saying something about WFI (Wait For Interrupts) causing this issue, but no ChibiOS related post...
3) Even if my project has some years now, I haven't noticed relevant difference between mcuconf.h, halconf.h, chconf.h nor Makefiles
4) my old openocd conf works exactly (at least it seemes) as the ChibiStudio configuration, while the gdb conf now is much more elegant, and seemes works better (even if doesn't work well yet...)
5) I'm a noob :'(

Any ideas for this strange behaviour? it's an issue of Chibios 4.2.3? i'm doing something wrong copying the conf? (with duplicate...) Ther's some reasons for not using some GPIO's for this purpose? now i'm using severals GPIOs, some of them setted up as AFIOs (USART, TIM) and some ADC... I don't have any idea if telling this make some sense...

Sorry again for double posting, and thanks again for all

[Giovanni]

WFI is not enabled by default in ChibiOS demos so it is not your problem.

Giovanni