J-Link Debugger with SEGGER Embedded Studio on Mac

[RichieJH]

Continuing my mission to have SES set up to be the complete development environment on a Mac I am struggling to get the Jlink Debugger to behave with SES.

It appears I cannot use the J-Link RTT Viewer since I have a Mac and this looks like it is Windows only. So I have fallen back to using the SEGGER J-Link Debugger V2.14 which is for Windows, Mac and Linux.

In terms of the Target Device, I see the nRF52832_xxAA and can set the Target Interface (JTAG: 1 MHz) with a USB host. So far so good.

SES imports the RTT Files folder so I added the relevant headers at the top of Main.

The problem is that every time I try to Download & Reset, Attach to Running Program or Attach and Halt Program I get a Connection Failed message in the J-Link Debugger Console. Also I notice the SES becomes unstable and often freezes and I have to restart it (I have reported the logs to SEGGER).

Is there something I am missing or is this a known bug?

Thanks

[RK]

In Crossworks, RTT channel 0 output goes direct to the console, since SES is Crosworks, and RTT is a Segger technology, it would be hard to believe it doesn't work the same way. It's only channel 0, but that's the one you use most of the time anyway. You just run your code and the output shows right up, I've never needed to run RTT viewer or anything else in order for this to work.

You do have to set the 'Startup Completion Point' to main, or SystemInit (I use SystemInit) to tell it when the app has reached the point to enable things like RTT, but that's the only thing I've ever had to do.

I see Startup Completion Point exists in SES too and in the project I looked at is set to main, don't know whether it came like that or I set it like that. Either way - the Debug Terminal should show the RTT output.

[RK]

I don't know how the original printf() routes. Crossworks had some 'print to console' long before SEGGER_RTT but I never used it nor did I look to see how it communicated with the IDE. To complicate it further you could also output to a UART and then hook up a simple terminal inside Crossworks and print that way and that also showed up in a window. I think the printf() one is buried in libdebugio somewhere so without disassembling it, I dunno how it works.

If Segger RTT has an advantage it's that it's very lightweight and just requires the debug probe to check a chunk of memory on a regular basis and shuffle data back and forward. It doesn't block or hang or wait or anything else, so you can just leave it in the code after you're done testing if you like, won't make a difference, a memory buffer you're not using will just have stuff written to it which is never used.