ChibiStudio preview 4

[DrunkenDonkey]

Workspace indexer settings like that looks to work okay too, it allows you to turn on the C++ analysis options too on default. Right-clicking and forcing the analysis to run results in mind-bogging amount of errors, something that works with indigo, but if you don't do that it works just fine in normal project files. I had to add a line in Project's C/C++ General/Paths and Symbols->Includes tab: I copied the already present line

Code: Select all

c:/chibistudio/tools/gnu tools arm embedded/4.7 2013q1/arm-none-eabi/include

and added it on top, otherwise it seems it can't find few standard defines line uint16_t. Looks like the fact this line is "last" has something to do, but still unsure how can I alter default variables to move it on the top without having to manually add it. Again, that works just fine with indigo (might aswell switch back but hey, juno is newer)

indexer.png (33.94 KiB) Viewed 4443 times

[inca]

Regarding ChibiStudio 4.7, the default "Debug Configuration" for the "ARMCM3-STM32F107 (OpenOCD, Flash and Run)" (and the others, I suspect) fails to Flash with OpenOCD STLINK/V2 targeting stm32f1x_stlink.cfg running. Here is the output:

Code: Select all

Open On-Chip Debugger 0.7.0 (2013-05-05-10:41)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : Target voltage: 3.186423
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Info : device id = 0x10016418
Info : flash size = 256kbytes
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
requesting target halt and executing a soft reset
requesting target halt and executing a soft reset
Error: timed out while waiting for target halted
in procedure 'wait_halt'
background polling: on
TAP: stm32f1x.cpu (enabled)
target state: unknown
Info : device id = 0x10016418
Info : flash size = 256kbytes
flash 'stm32f1x' found at 0x08000000
Error: Target not halted
stm32x mass erase failed
in procedure 'stm32f1x'
Error: Target not halted
Error: error writing to flash at address 0x08000000 at offset 0x00000000
in procedure 'flash'
requesting target halt and executing a soft reset
Warn : The target is not in the halted nor running stated, stepi/continue ignored.
Warn : target not halted

Our "monitor soft_reset_halt" is not occurring at the start of the Debug Configuration->Startup->Initialization Commands. Why are we not using "monitor reset halt"? This has always been the recommended behavior for development from OpenOCD experts across the land. I do not know what it is not built into those commands which require that state of the embedded target, but it is what it is.

When "monitor reset halt" is added to the beginning it appears to work. There are some glitches in the launch still, which led me to remove all of the monitor commands except for the mandatory "reset halt" in favor of using GDB's native ability to flash the memory using the elf file, which maps the binary data to various memory regions as well as debug information regarding the program.

Go to your Debug Configuration->Startup for this project.
Select "Halt"
Initialization Commands in the text box

Code: Select all

set remotetimeout 1000
set mem inaccessible-by-default off
monitor reset halt

Select "Load image" (build/ch.elf)
Select "Resume"

I am no Eclipse Guru, so some of these options may be in excess of what is necessary to just use the GDB interface, but this workflow has been working for me without flaw since the first time OpenOCD has ever worked for me.

Now I have to wipe the Eclipse install because I renamed the directory, then renamed it back to its original, which has completely broken the installation ("The system cannot find the path specified." for the yagarto tools).

Hope this helps.

Cheers

[Giovanni]

Just a note: in next version launch configurations will be done like described in the previous post, there are several advantages in doing so.

That "set mem inaccessible-by-default off" seems to have no effect, it works even without that. What is it supposed to do?

Giovanni

[colin]

I'm using Eclipse C/C++ IDE "Kepler" to work on ChibiOS/RT and I find that much of the code completion/indexing is not working. I think it has to do with the conditional compilation #if stuff. The Eclipse indexer is somewhat smart and ignores anything that is excluded from compilation with preprocessor conditionals #if/#else etc.

I think that the proper #defines are not getting set up somehow but I haven't dived in to see what is going on. Aren't all the configuration things set up in chconf.h / halconf.h / mcuconf.h, rather than in the compiler command line with -D options? So I need to see what the chconf.h et al are not getting found during Eclipse indexing.

BTW, this is based on my work using a 'demo' project, which has chconf.h/halconf.h/mcuconf.h files. If you're working on ChibiOS/RT itself as a top level project, you won't have chconf.h/halconf.h/mcuconf.h, right? So the #defines won't be set up and most stuff will be excluded from compilation...

[Giovanni]

All projects should have symbolic links to ./os, ./test and the board directly so that the indexed can find them. Provided projects are done this way.

Also, a workspace variable CHIBIOS must be created because the provided projects use that as prefix for paths.

Giovanni