OK - there must be another explanation as to why:
!defined(USE_SWD_JTAG) && !defined(USE_SWD)
is not evaluating false when USE_SWD_JTAG is set
Because replacing that line with:
#if 0
Does evaluate false (and at least allow progress, if not exactly do the right thing…)
I can’t figure out how USE_SWD_JTAG gets passed around for hal/photon, to be honest. I see it passed between some makefiles, but I never see it show up on a gcc command line.
Good to hear!
I just wanted to chime in and say that the debugger still works for me with the latest develop and tinker under Ubuntu.
I uploaded the log of rebuilding the firmware if you want to check it. I'm not sure what you meant Andy about how USE_SWD_JTAG gets passed around, but it's definitely on the command line for each invocation of gcc in as shown in my log.
OK - error between keyboard and chair here. I was using USE_SWD_JTAG=1 (like the PARTICLE_DEVELOP flag) and the correct usage is apparently USE_SWD_JTAG=y.
Maybe it should be made insensitive to content and just whether it is defined or not, or flags can get standardized on “1” or “y”
However, that still leaves the twin problems of why the #if in core_hal_stm32f2xx.c did not work correctly (but worked when replaced with #if 0) and the fact that what’s in that conditional is incorrect.
I wonder why JTAG works without change for you, @jvanier; but does not for you, @opprud ?
I’ve just verified that it works for me (once I get the right make directive syntax), just as it does for @jvanier.
That would suggest that the pre-processor is working as advertised in @jvanier and my (and likely for @mdma also) case, and not for @opprud - that just makes my brain hurt; but I’m sorry that I can’t reproduce it.
I still think the skipping init of all input pins iff JTAG/SWD is dead wrong, though.
One really nice thing with the modular firmware is that once you program the photon with JTAG-compliant system images, all subsequent applications are also JTAG/gdb friendly. Of course this still leaves the disposition of the JTAG pins open to discussion, but as long as you know what to expect, it works.
Interesting insight. What's the consequence of this? Can the debug workflow be simplified to rebuild only the user module, flash it OTA with particle flash user-module.bin, then reattach the debugger? Moving the USB around and reflashing with DFU is cumbersome.
merging the 3 elf’s into one, would be a great, i haven’t found a way to feed them all to eclipses GDB, even though @jvanier wrote a script to load them all into cmd-line GDB…
There’s an errata from Jan 2015, http://www.st.com/web/en/resource/technical/document/errata_sheet/DM00027213.pdf that mentions a bit on JTAG, not sure if it is relevant, furthermore i cannot find older erratas. @jvanier depending on the age of your Photon, could be the silicon is a different revision ? I haven’t popped the hood on my photon to to verify the chiprevision. Otherwise i have no guesses…
It's new, from a few weeks ago.
I think that “arm-none-eabi-ld --allow-multiple-definition user.elf system_part_1.elf system_part_2.elf” is a promising line of research for the single-debug-binary (but still not the monolithic build.)
Initial testing proves that we will need to write a special linker file to make things load at the correct addresses etc. I’m out of time tonight, but thought I’d share this much.
@opprud, I do not think that errata contains anything too painful for the JTAG port.
@jvanier, I would consider flashing the user-module.elf file using openocd , but I’m not sure it’s a great candidate for putting in a makefile just yet, because of the site-specific variations (especially in the openocd command line.) Something like:
openocd -f <debug hardware.cfg> -f <target.cfg> -c "reset halt" -c "flash write_image erase user-module.elf" -c "shutdown"
might work to save you the dfu two-step or bouncing stuff through the cloud.
I’d like to see this extended to either:
I think either of these options would provide a much more productive development workflow.