It works by stopping the program, transferring data to the debugger (which will then perform the operation) and (after the i/o has completed on the host) restart the application. You don't need an UART for this, just a J-Link connection and the RTT module added to your software. Have a read at the excellent text by David Nadler on that subject: Īs for logging, I rather use SEGGER RTT (you get that with using a J-Link probe, see and. The other point would be: is your system re-entrant? If using the standard library malloc/free (which is used inside the standard library depending on your lib/gnu version) and using an RTOS and/or constructors/destructors you have to pay attention to make it reentrant. Make sure you have plenty (say >20 KByte heap and plenty (say >5k Byte) stack space available. It is very intrusive and really huge (code size and stack usage). IMHO semihosting is really a bad choice for things like this. I guess there is some setting I am missing somewhere or so. However creating a general debug output for C++ makes JLink show an error. There is one general debug console redirection for Eclipse and C++ that is possible to set up, similar to: There seems to be one specific for Jlink:īut I do not get the console content from MCUXpresso there, just the message Executed SetRestartOnClose=1 for the whole session. There are certainly settings for redirecting output to a file. Sure, we could just copy paste the console contents but that is a bit crude.

The task at hand then would be to redirect the debug console. However, it is a bit tricky when targeting many values, and also a bit slow? As we have the processing power for it, just printf() to a csv for a quick debug seems easier. I know this can be done using GBG, I found this guide for instance: Some simple output format like CSV would be preferrable. *startLFClk_reg = 0x01 // Start external 32.So I want to log some sensor data in MCUXpresso at around 50 Hz. *LFClkSource_reg = 0x01 // LF oscillator source = external xtal *startHFClk_reg = 0x01 // Start external 64 MHz crystal oscillator Volatile unsigned long * setPins_reg = (volatile unsigned long *)GPIO_BASE_ADDRESS + OUTSET_ADDRESS_OFFSET Volatile unsigned long * setupOutputs_reg = (volatile unsigned long *)GPIO_BASE_ADDRESS + DIRSET_ADDRESS_OFFSET Volatile unsigned long * LFClkStarted_reg = (volatile unsigned long *)CLOCK_BASE_ADDRESS + EVENTS_LFCLKSTARTED_OFFSET Volatile unsigned long * startLFClk_reg = (volatile unsigned long *)CLOCK_BASE_ADDRESS + TASKS_LFCLKSTART_OFFSET Volatile unsigned long * LFClkSource_reg = (volatile unsigned long *)CLOCK_BASE_ADDRESS + LFCLKSRC_ADDRESS_OFFSET

Volatile unsigned long * HFClkStarted_reg = (volatile unsigned long *)CLOCK_BASE_ADDRESS + EVENTS_HFCLKSTARTED_OFFSET

Volatile unsigned long * startHFClk_reg = (volatile unsigned long *)CLOCK_BASE_ADDRESS + TASKS_HFCLKSTART_OFFSET #define DIRSET_ADDRESS_OFFSET 0x518 // 1's written to this register setup corresponding pins as OUTPUT. #define OUTSET_ADDRESS_OFFSET 0x508 // 1's written to this register set corresponding pins (HIGH). Addresses to registers, tasks, and events for the GPIO Addresses to registers, tasks, and events for the clock Note: Programming the nrf52840 usb dongle cannot be done with Segger Embedded Studio because the nrf52840 usb dongle does not have a debugger. Can anyone tell me if I'm using the pointers correctly? My thought is that I may be incorrectly addressing the registers. After editing the linker file and recompiling, everything seems to be in the right place however, after programming (done with NRF Connect) the LED still doesn't light. I'm using Segger Embedded Studio to compile and link everything, but it seems to generate incorrect RAM and Flash locations. I'm trying to use pointers to directly access the registers in a nrf52840 usb dongle.

Segger embedded studio csv