I can't seem to find an answer with my searches, but can the Arduino IDE use a Segger J-Link as a SWD programmer?
I ask because my MK20DX256LVH7 board lacks on-board debug chips. I want to program it via the SWD pins.
What do I need to do?
I can't seem to find an answer with my searches, but can the Arduino IDE use a Segger J-Link as a SWD programmer?
I ask because my MK20DX256LVH7 board lacks on-board debug chips. I want to program it via the SWD pins.
What do I need to do?
The Arduino IDE uses external tools for all of the actual programming/uploading.
One of the tools it can use is OpenOCD used with a Jlink adapter (supported by several Adafruit boards, explicitly. OpenOCD itself is supported by the Arduino SAMD boards.
OpenOCD requires a relatively complex config file for each target, usually provided in the variants directory of the board support, ie:
[color=green]pwd[/color]
/Applications/Arduino-1.8.9 copy.app/Contents/Java/portable/packages/arduino/hardware/samd/1.8.4/variants
[color=teal]find . -name \*ocd\*[/color]
./mkrwan1300/openocd_scripts
./mkrnb1500/openocd_scripts
./arduino_zero/openocd_scripts
./mkrwifi1010/openocd_scripts
./mkrvidor4000/openocd_scripts
./mkrgsm1400/openocd_scripts
./mkrfox1200/openocd_scripts
./mkrzero/openocd_scripts
./mkr1000/openocd_scripts
./nano_33_iot/openocd_scripts
./circuitplay/openocd_scripts
./arduino_mzero/openocd_scripts
You will need to find or create the openocd scripts you need to work with your target CPU and probe, and craft the programmers.txt and boards.txt files to create the proper command line.
Thanks. This is turning into a little more than I was expecting.
I am thinking that hacking a Teensy 3.2 board and using it as a programmer is a simpler solution.
hacking a Teensy 3.2 board and using it as a programmer
Does that work? AFAIK Teensy 3s have a weird bootloading scheme where a proprietary chip loads a bootloader into RAM, and then that uploads and self-programs the flash... (actually, I think that's how a lot of SWD "programmers" work, too. Interfacing with the NVM controller in a particular chip is beyond the limits of the SWD/JTAG specs, so they put short device-dependent code in RAM and then execute it (which will generally allow much faster programming that manipulating the NVM controller registers directly.)
westfw:
Does that work? AFAIK Teensy 3s have a weird bootloading scheme where a proprietary chip loads a bootloader into RAM, and then that uploads and self-programs the flash... (actually, I think that's how a lot of SWD "programmers" work, too. Interfacing with the NVM controller in a particular chip is beyond the limits of the SWD/JTAG specs, so they put short device-dependent code in RAM and then execute it (which will generally allow much faster programming that manipulating the NVM controller registers directly.)
I haven't tried it, but there is this article that seems to describe exactly that:
It makes sense to me. You are essentially "disconnecting" the Teensy 3.2's on-board MK20DX256VLH7 MCU from the MINI54TAN Bootloader Device and rewiring that Bootloader to the new MCU via SWD.
Ultimately I will probably rewrite the software using NXP's MCUXpressoIDE (can't afford the big guns like Keil), but even with all the shortcomings, the Teensy and Arduino did a great job getting me to working code.
I'll let you know how this works out soon. My new PC board and chips arrive today and tomorrow. Crossing my fingers, eyes, and toes.