I think I have a fix! Branch feature/hal seems problematic, switching on the master branch, modifying firmware to disable JTAG and enable SWD makes it work! Hooray. Also COM port is working, which I had issues with before.
Im using OpenOCD 0.8.0 instead of st-link util (way faster upload) and updated my STLINK debugger to version: V2.J23.S4 STM32+STM8 Debugger. This is the configuration file that im using to start OpenOCD:
Sorry to hear you’re having trouble with feature/hal branch - it is a development branch so there may be unresolved issues, but I and a few other developers are using it successfully. If there’s any way we can dig in and find out more about the cause, I’d be happy to help.
One thing that’s not immediately clear is that the PR should be in it’s own branch, which you then push to your github repo. From there, you can create the pull request.
The first time you make a PR it can seem a bit daunting, but is much easier the second time. Also tools like SourceTree make the process much easier.
You don’t write to the spark repository directly so there’s no chance of doing anything harmful.
I followed it and had no real problems. But now I have run into something that I have been unable to figure out with the linking of the project. Where are the libraries specified that need to be linked into the final binary output? I’m trying to utilize functions in <time.h> but it’s failing at the link stage because it can’t find the functions I’ve used.
Being completely unfamiliar with how the Spark project is laid out and how the ARM GCC toolset works I was unable to find where this is done.
If you use the HAL branch, it all taken care of by the makefile. I do not have any experience with compiling the master branch, so I hope someone else can help you out.
Thanks for reiterating that! I thought I had seen it before but my eyes failed to find it. (I guess a simple “find in page” would have worked well!)
I’m playing around with my ST-Link and I can get it to connect to my board from the ST-Link Utility but when using the st-util from the command line it seems to be having problems. It also won’t program the chip. Here is the output from st-util:
C:\Users\xxxxx>st-util -m -p 9025
STLINK GDB Server v0.5.6 (Mar 24 2013 10:29:19)
Many thanks to the STLINK development team.
(https://github.com/texane/stlink)
2014-12-17T11:32:06 INFO src/stlink-common.c: Loading device parameters....
2014-12-17T11:32:06 WARN src/stlink-common.c: unknown chip id! 0xe0042000
Chip ID is 00000000, Core ID is 00000000.
KARL - should read back as 0x03, not 60 02 00 00
Listening at *:9025...
So I did some digging to see if there was something similar to the “hold in reset” for the st-util but no luck.
However, there was one lucky find in my digging. I solved the need for the patch file to keep restarting st-util. There is a command line option -m that causes the server to keep running after a disconnect and listen for another connection.
Any ideas on why the st-util is not able to properly connect? Thanks!
It sounds like you have not recompiled the core with USE_SWD_JTAG=y.
If you merge my pull request for just SWD support, you can use USE_SWD=y
See https://github.com/spark/firmware/pull/337
You need to compile the code with that flag and flash it via DFU before you can connect via SWD.
St-util will then find a Core ID that is not zero.
I have no idea where I could even try “help target” because it gives me an error if I try setting that in the target text box. I also tried Google and it did not turn up anything.
I tried it without the leading “target” since the gdbserver plugin suggested a target of “remote host:port” when I first started the attach. However this appears to do nothing as I don’t see anything happen in the st-util window and I don’t seem to be able to interact with the board from NetBeans.
@Elco, i’m trying to setup the same environment on my MAC so that i can dig a little deeper on issues. However, i’m getting the exact same warning for the chip id.
I have the JTAG shield and STlink V2 so hardware should be fine. If i found anything i’ll update this post
UPDATE
If you hold on the RST button before invoking st-util -p 9025, the correct core id is displayed but the user firmware does not run.
and it looks like NetBeans never tries to attach to the GDB server. I see that it is listening on port 9025 and nothing happens.
I have also noticed that my “Run” command seems to stay attached to the DGB server so I am pressing the X to stop the run before I try to attach the debugger. (I also tried it without stopping the run before attaching and still nothing.)
I left NetBeans in the “attach to GDB” mode and I came back a while later and saw that an error had popped up. It states:
Malformed response to offset query, timeout
Not sure if that helps anything but wanted to report just in case!
OK, so I found out that my little -m discovery was my undoing!
I ran a test without first doing the “run” command just to see if my firewall was getting in the way. Well, the debug session attached! So I terminated that and then tried a “run” but that failed to attach to the GDB server.
So, the problem is that st-util.exe is not actually accepting connections after a process detaches even though it looks like it is waiting.
I revised my “process” to use the batch file and all is happy now!
This script will start st-util, then fork it to the background and start arm gdb to connect to it and upload the code. After that it does a clean exit: no lingering processes that you should remember to close.
You can just set this script as the run command in NetBeans and it will upload the code with 1 click. The output of the script will be printed in the embedded terminal.
After you have uploaded the code, if needed, you can start st-util again and connect the debugger.
I think the process is great now, it just misses the ability to pause. This is related to the bug report I posted above, don’t forget to vote for it!