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
