Programming With SEGGER J-Link

New to XMOS and XCore? Get started here.
braddrew0
Member
Posts: 8
Joined: Sun Sep 15, 2019 7:09 am

Programming With SEGGER J-Link

Postby braddrew0 » Tue Oct 22, 2019 3:32 am

Hey guys - does anyone have experience programming any of the XCORE200 using the SEGGER J-Link debugger? I'm looking specifically at XU208 and XE216 devices on customs boards - just having some problems transferring usable binary using xflash.

Thanks! :)
User avatar
mon2
XCore Legend
Posts: 1630
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Tue Oct 22, 2019 7:33 am

Hi. Have not heard of anyone using the Segger tool in the past with XMOS devices. Any reason you are not using the proven xtag3 tool (under $20 usd from digikey) for your custom pcb? Post more details on your issues.

It may be helpful to review the xtag3 connections to the cpu with a partial schematic of your design.

Also see here:

viewtopic.php?f=26&t=4766
braddrew0
Member
Posts: 8
Joined: Sun Sep 15, 2019 7:09 am

Postby braddrew0 » Tue Oct 22, 2019 10:15 am

Thanks mon2 - I already have a J-Link debugger which I use for a number of other devices, I'd like to keep my toolchain standard if I can. This document from the XMOS website (https://www.xmos.com/file/xtimecomposer ... and-boards - https://www.xmos.com/download/xTIMEcomp ... rds(A).pdf) references the J-Link - "The ARM support within xTIMEcomposer has been developed using the SEGGER
J-Link series of development adapters" - however this is talking about the first generation XMOS devices.
User avatar
mon2
XCore Legend
Posts: 1630
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Tue Oct 22, 2019 10:32 am

Correct on that reference to the xcore-A cpu which offered a licensed ARM core from SiLabs. That version of the cpu I believe is EOL.

The XTAG3 is not open source but believe an older version of xtag is posted on GitHub. Best if you can just consider to use xtag3 with a small footprint pogo pin cable or similar for production.

If your xmos xcore-200 cpu is making use of external flash for booting then you can review the idea of parking the cpu by asserting the local reset line which will then tristate the interface flash lines. Then proceed to flash the target qspi device and enable the QSPI EN bit on your production line. For that task you may find faster alternate solutions but those cables will not be able to perform debugging of the XMOS cpu.

Xtag3 can do both but xflash (closed source) by XMOS is not the fastest flasher tool but is well supported so you are not reinventing every aspect of this tool.
braddrew0
Member
Posts: 8
Joined: Sun Sep 15, 2019 7:09 am

Postby braddrew0 » Wed Oct 23, 2019 7:05 am

Yeah thanks again - that's the approach I was taking with no luck. Could have been a few different things in my setup causing it but I missed the part where the Gen 1 devices used a licenced ARM core and that's no longer the case. Looks like it's XTAG with a custom footprint - shouldn't be too hard to change over.

Thanks again! :)

Who is online

Users browsing this forum: No registered users and 0 guests