I am very new to this type of work. In the hope of adding an I2C display to my remote control drone, I've been diving into the software that runs it and more recently, J-Link EDU. I was hoping to step through code in the area that tries to interface with the I2C display.

I have recompiled the C code and flashed it on the usual USB interface provided by the drone.

The guts of the drone, a board running a STM32F303CC processor, has pads labelled SWDIO, SWCLK, NRST, GND, and 3.3. This is in addition to boot pins that can be shorted to force the bootloader into a state to receive new code if the usual usb interface is not able to connect.

Through various guides, I'm pretty sure I've connected my J-Link EDU properly to the pads. I first added 100k pull up resistors to SWDIO, SWCLK. I latter changed this to 4.7k. I verified that the pads do in fact connect to the microprocessor at the correct spots. I've even tested the NRST pin by grounding it and seeing that it does in fact reset the CPU.

When I use the J-link commander to connect to the board, I am not able to get any sign of connection.

Wires connected to these pads connect to the J-link edu cable. I'm suspecting that the j link box is broken. I've ordered a stm 32 discovery board to test. I've noticed that I can consistently reset the processor by grounding the NRST pin. When this is connected to the J-link, there is never a reset actually performed. I'm wondering if the J-link is even strobing the reset pin as I understand that it has a bunch of different strategies based off this action to allow it to connect to the SWD interface.

I'm tempted to buy an oscilliscope to test if there is a reset strobe on the j link pin, pin 15

How long would the j-link hold this pin low to force a reset, can i test this with a multimeter or do i need an oscilliscope. In any case, the connected processor does not reset by j link as evidenced by its usual beeps.

Could there be any kind of code protection bits that prevent a jlink connection? Saw something about this somewhere.

The drone software is open source, i don't know about the bootloader.

Does the boot loader even get run if the j link resets and connects to swm like it should? I would think it breaks right in the bootloader.

My hope is to set a break point in my c code and step over the bootloader to the i2c area. Do I even need a bootloader? Can I use j link (or j flash) to place the C code in the drone where the bootloader is now and step through it?

Once this works, hopefully, is it reasonable to assume that I should be able to break on lines that talk to the i2c display and, if working, step line by line and watch text and pixels be placed on the display? is there any kind of a timing thing starting and stopping the cpu, but not the display?

Thanks,
Jeff

Hi Nick,
I will have to reset up my project to get you the exact screen shots. Some commands I've tried are the following

r
rx
swdselect

I have been mostly trying to work with the connect command as this go throws through a whole series of questions prior to an attempt. This asks for the device, target interface, and speed.

Here is what the screen looks like prior to the connection of Pin 19



SEGGER J-Link Commander V6.16e (Compiled Jun 27 2017 18:47:39)
DLL version V6.16e, compiled Jun 27 2017 18:47:05

Connecting to J-Link via USB...O.K.
Firmware: J-Link V10 compiled Jun 16 2017 16:15:19
Hardware version: V10.10
S/N: 260104011
License(s): FlashBP, GDB
OEM: SEGGER-EDU
VTref = 0.000V


When I connect pin 19, VTref = something like 4.9 volts. I will have to setup teh wires again again to get the exact value.

One interesting aspect I'm now thinking about after speaking with someone earlier is the following...

This person stated that VTRef, SWDIO, SWCLK, and RESET are the only pins that need to be connected. This person said that if I also connected pin 19, I could damage my board. My board was powered by the usb. Here is what I noticed...

When I connected pin 1, vtref to the 3.3 volts of my board, pin 7 (SWDIO) , pin 9, (SWCLK), and pin 15 (reset), the main screen would show as above...
VTref = 0.000V



It was only after I supplied 5 volts on pin 19, would VTref go to approx 4.9 volts and the connect command attempt to make the unsuccessful attempts.


Is this significant? Does having VTref show as 0.000V, while the circuit is powered of course, and pin 19 left unconnected, cause the debugger to simply not do anything meaningful?


Thanks, Jeff

Nick,
I connected after noticing that the pdf at segger.com/downloads/application-notes/AN00021 is incorrect. I noticed that the connector shown on page 12, J-Link Pinout for SWD, is reversed in the left column. Specifically, whats shown as pin 19 is really pin 1, pin 15 is really pin 5, etc. The right column appears correct, ie, pin 4 is really ground. In any case, I now connect to my processor and now see the following....

_______________

Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
TIF>S
Specify target interface speed [kHz]. : 4000 kHz
Speed>
Device "STM32F303CC" selected.


Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Scanning APs, stopping at first AHB-AP found.
AP[0] IDR: 0x24770011 (AHB-AP)
AHB-AP ROM: 0xE00FF000 (Base addr. of first ROM table)
CPUID reg: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
Setting AIRCR.SYSRESETREQ
Cortex-M4 identified.
J-Link>
_______________


After seeing the above, is it safe to assume that there are no code protection bits preventing me from using the debugger as planned, reviewing the i2c display code and hopefully trying to spot the problem?


I was wondering if I can, assuming the i2c code is correct/corrected, step line by line and watch text be updated on the display? is there any kind of a timing thing/clock that could show characters being written on the display when running full steam but not while being incrementally debugged?


Thanks,
Jeff

Nick,
I am a customer too and it does not appear to be correct. I looked at link above and it looks to be the same diagram as in the pdf that I originally used. Perhaps the unit I have is faulty/the internal connections are miswired? Perhaps they switched something in the newest edu version?

I attached a picture of the j link cable i am using on the drone side. Note the notch on the left side of the connector. Also note, there is nothing connected to the upper most left pin of this connector. I assume this is pin 1, vtref. I tested that the upper left most pin, with regard to the notch being on the left when looking down on the connector, is connected and not reverses in the cable. It connects to the same pin on the other side.

In any case, the other side of the connector in this picture plugs into the j link edu and it works. I tested the go/halt instruction with the TestHaltGo command.

I will look into using the mem commands you described.

I am using eclipse as it was on the page that originally pointed me to the j link edu debugger.

I might try ozone after I get the eclipse plugin to work. Though this is fun so far, especially now after the j link edu appears to work, I've spend a lot of time installing things and reading up on serial debug stuff than i originally thought.

Thanks for the help,
Jeff

Thanks Niklas.

Hi Nick,
I just have a couple of observations/questions.
I have the debugger working in eclipse and am able to set breakpoints and look at variables in routines the processor is executing. This first part might be outside SEGGAR support. Sometimes, the eclipse debugger reports an error in displaying a variable and that it is optimized out/something like that. It does this even when I compile my code with "DEBUG=GDB" in the makefile. Also, I am able to set flash breakpoints and sometimes look at variables when I compile the code without setting "DEBUG=GDB" in the makefile. The J link debugger references the elf file and the hex file is flashed to the chip. Does the j link debugger need anything special in terms of compiler flags to work properly? I suppose switching off all optimizations would be best so no confusion in eclipse. Does the eclipse debugger need symbol info in the bin file, the kind of stuff that tents to bloat the bin and make it overflow the text segment (another problem sometimes)?


My STM32F303CC chip is connected to a UART and an I2C based gyro. When I initially got this setup to work, I had problems connecting a google chrome app to the chip to interact with a gui interface to program settings. It then started working! This is a non issue and probably something that I was doing wrong. I was then wondering, Why did it start working. I mean, the chrome app connects to a usb port on the flight controller, not the chip. I was surprised that it actually worked when it did. I read something about the seggar j link device making a virtual serial port that might be copying info and presenting it to the chrome app. So, in a nutshell, i run my chip at full speed, all breakpoints unset except for a break point in some code that talks back to the serial port and returns a status. I can then go to my chrome app, connect to the chip, click a button and hit the set break point in eclipse. What is seggar j link doing to make this happen, if anything, that lesser powered debuggers might not? I realize that the J link edu is a great deal to learn about hardware debuggers, had i bought a j link mini, would this still have worked? I think i just got lucky in having this work as expected, while forgetting there is a uart that is connected to a web app also.


Also, I looked into using RTT client and RTT viewer. If I were to code a loop to display 30k "Hello World from SEGGER RTT!" strings and look at it using RTT client, will something break if the messages are dumped too fast?

I used the command ..... SEGGER_RTT_WriteString(0, "Hello World from SEGGER RTT!\r\n") in my flight controller code.



I placed this in a section which should have streamed a zillion messages a second from the flight controller and only saw a handful in the RTT client app with no error message after the few that displayed. Its like when it was run full steam, something lost communication with RTT client/the message stream? I can do some more testing.


The main goal of all this is that I wanted to see what is happening on the I2C2 bus. I have a display connected to that.


I note that I can communicate without error on the I2C1 bus/step through code/talk to the gyro using j link, so that is good. When I do this on I2C2, I can see where the errors are generated "bus not RESET". It appears that J link is a great tool to look at this bus communication and step though the code. I have no clue whats happening on the I2C2 SCL and SDA lines, so I might have to learn how to use an Oscilloscope.


Do you suppose it reasonable to assume that if I get an Oscilliscope, set a trigger on the SCL line or SDA line, I can see a pulse the moment I step over a line that properly speaks to the I2C2 bus? I would think the debugger would stop the clock if it was set and if i single stepped, it would start it and stop it momentarily and I can see something on the scope?


Thanks for all your help,
Jeff M