- #SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT MANUAL#
- #SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT SOFTWARE#
- #SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT CODE#
- #SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT BLUETOOTH#
- #SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT PROFESSIONAL#
The reason was that the \st directory got trashed as the files disappeared from Cube, even though I never touched anything in \st. I had to retrieve the \st directory from a machine at the office, which had an older copy of the sources I am working on. And as Cube sees files disappear (due to external action) it reconfigures itself accordingly. Except instead of Copy I did Cut And I saw all the open files, and everything else in Cube, disappear, over a few seconds Getting it back wasn't easy, because Cube stores some config under the project and some under c:\st (or whatever, under Configuration).
It was done by copying the project directory to a network drive, as I do now at least daily. Yesterday I managed to trash my project, seconds after I backed it up.
#SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT SOFTWARE#
And running everything in a VM (and archiving the VM) is a tacky option, which I reserve for old software and such. My main issue is having a futureproof development environment, which I can understand and is self-documenting, because I often have to revisit a project after many years. I last used source control many years ago. As I said, it depends on experience, ability, and project needs. But for some small projects like mine, it was a big accelerator! Just my experience.
#SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT PROFESSIONAL#
Maybe for a professional product, also no good. For me it would have been impossible to do all without the help of CUBE. I got it running in 2 weeks (first prototype), and working correctly after another couple of weeks.
#SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT MANUAL#
Alone reading the manual for the low power modes and clock generation would take me couple of days. Now should I have started bare metal, MAYBE I could have made it in 6 months?.
I did it with the USB and ADC of the controller. In the middle of the project I had to make me an "Oscilloscope" - long history. Requirement was to have an operating system running, so it was modular with tasks (customer requirement). Also had to control 3 BLDCs, including overcurrent protection. I had many IIC sensors, UART, USB, had to support low power modes, I had to make signal processing (some FIR and IIR filters) and 2 PID controllers so I had to use DMA for the communications if I did not want to loose time. I came back to programming microcontrollers after 5 years of no touching anything. Not so.My experience was I had to make a lawnmower robot in 1 month. I thought life would be easier in s140 than s130 and SES. Setting a breakpoint on the connection event in SES does not work, Neither the NRF_LOG or printf statements work in the connection event handler. I see on my client that I get a connection event and service discovery, enable characteristics but the client times out on the first write.
#SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT BLUETOOTH#
But something is seriously broken - I cannot print using NRF_LOG though I can print at the start using printf instead (but not once the Bluetooth runs). If I can stepwise debug in Keil using s130 I should be able to do the same in SES using s140. So there is clearly something incorrect in your statement or your understanding. There were a few changes I needed to make in the SodtDevice APIs but they were minor.
#SEGGER EMBEDDED STUDIO DEBUGGER NEVER HITS BREAKPOINT CODE#
This is the exact same code ported to Segger and s140 instead of s130 and Keil. Of course the BLuetooth communications will fail but that's always the case as the peer timesout. I can set a break point in the nRF51 project using SoftDevice and I willl hit it (Keil). (Yes I have seen the debugging video and that's how I know my Tools.xml is corrupt). I am not surprised that there are issues with the code as I have ported a SoftDevice only project from nRF51 and Keil.īut being unable to debug or even print to RTT (this is new for me) or via the UART and putty (the latter worked fine in the Keil project) is not helping.Īny help would be great. Yet the code I have does partially run - it advertises, gets connected to, responds to service discovery, gets two characteristic descriptors enabled but then when I try and write from the client the write times out. The only thing I can think of is that somehow the installation of SES got really corrupted or I am missing a major step. I can step line by line if I start and use F10/F11 from the start (do not use F5 and a break point) but never once I use F5 and a break point.Debug breakpoints are not hit unless it is in the main() part of main.c and when hit not in the code, only if a debug window to the left of the code.The CMSIS Configuration Wizard is NOT present in my Tools.xml.NRF_LOG_x does not print either through the UART and putty OR RTT in SES since CMSIS Wizard is not present.I am having major problems with Segger Embedded Studio I saw something in the list that might help but I have learned that if I go there I lose all the work I did to get here
0 kommentar(er)
