Search Results

Search results 1-15 of 15.

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • I had issues with resetting device from Ozone, it uses different method than JLink commander's reset or "monitor reset" via gdb (perhaps it just jumps to reset vector instead of doing device reset?) AFAIK there is no possibility to change resetting procedure in Ozone. As workaround, I use either JLink commander's reset or reset from GDB (My device's firmware has three stages, each with different set of interrupt vectors, and Ozone's reset doesn't work at all) I guess the reset should be somethin…

  • Since either my JTrace don't work correctly wtih STM32 board: The given reference board is STM32507VG (which is included in JTrace port. The program was micropython default build for STM32F4DISCOVERY. Since my STM32f427 board doesn't work well with ETM, I tried to use ITM PC sampling. However, mu current JLink board seems to suggest much higher CoreClockCpus, e.g. STM32F407 has just 168 MHz, but SWViewers showed estimated clock rate 252 Mhz. After measuing the responses and parsing with sigrok I…

  • Is it somehow possible to flash and try different JTrace firmware versions, including older ones? The reason I am asking is that I've seen fairly crazy ad-hoc-soldered designs from other people (like this: pbs.twimg.com/media/ETkKGnZXYAA5ZQV.jpg ) that worked with ETM trace on older firmware, but just when I use a bit longer cable with the reference board, the whole thing falls apart (the infamous LTRACE error) My current FW version is Firmware: J-Trace PRO V2 Cortex-M compiled Jan 7 2020 16:54:…

  • Quote from SEGGER - Nino: “Could you attach an example project that runs out of the box in Ozone, with which the behaviour is reproducible with? ” Here is link to the built project with sources: qabs.cz/o/ARM/micropython_wfi-1.12-out.tar.bz2 Inside the micropython_wfi-1.12-out directory, there is micropython-wfi.jdebug The ETM trace in this works for me without LTRACE errors only in the two cases ("power on" or or both cables on power bank). I also tried the USB galvanic isolators, and those don…

  • I will get USB galvanic isolators tomorrow to do more testing. For now, here is for reference how JTrace also works if JTrace and reference board are powered via power bank (JTrace connected via ethernet to Ozone). Attached photo of HW setup, screenshot of Ozone when it gets to hard fault. A feature request (maybe this should made be separately?) - you could show the stack trace on vector catch like Black Magic Probe in 3rd image (so that you don't need to go over SCB registers and stack manuall…

  • Quote from SEGGER - Nino: “I am a bit confused here. How was your setup before that? Did you not use separate USB cables before to power board and trace probe? Could you provide a photo of your setup before the "power on" part? ” See attached photo. This is a powered USB3 hub. Yes, two separate USB cables were used (blue JTrace cable that came with it and a the grey one for power of STM32F407 board). Quote from SEGGER - Nino: “Are you using a USB hub? If yes could you try using the USB ports on …

  • I think I solved it, partially at least for the reference STM32F407 board. (I will have to see later for my target board when it gets proper connector). Even WFI does not seem matter. There were 3 programs that caused LTRACE problems I did testing on: - micropython with WFI - micropython with all WFI replaced for NOP - the task 6 above The solution that works for the reference STM32F407 board: using "power on" in Jlink command so that target board is powered through 5V supply pin. Or have both o…

  • I get the LTRACE errors even with the reference STM32F407 board that came with JTrace. The most basic tutorial on the wiki works without LTRACE error - wiki.segger.com/Tracing_on_ST_…x-M_Trace_Reference_Board) . Though even it sometimes gives error like "Invalid trace timestamp detected at cycle 568542086, buffer index 747292". If I use different binary, just this simple example - github.com/k-code/stm32f4-exam…e/master/Task-6-Interrupt - LTRACE errors appear again. (Though Task 2 or 4 from this…

  • You could check it either with flashing via gdb, look at "readelf -a your_file.elf | less" if the sections are at right address or trying the stm32loader. The stm32loader expects that you have UART connection to the MCU and that MCU is in bootROM mode (stm32loader can pull the bootROM-enable pins if you have configured it and have them connected, or you connect the pins manually). STM32CubeIDE also uses the same way if you flash via UART. With stm32loader you can specify the address manually wit…

  • I don't know what "red LED" means on your probe (I have different probe - JTrace where red is trace), but I'd first check the wiring and then try OpenOCD, like this: Source Code (1 line) I'm just guessing what MCU you have (guesses STM32F0x) and guessing SWD connection, the selection Cortex-M0 doesn't tell which MCU you have exactly. If OpenOCD can connect, you are good. You can add extra -d parameter for more verbose output.

  • I have a bit of a puzzle. My code has a stack guard that should call "error_shutdown" function if stack is corrupted (-fstack-protector gcc option), but somehow it seems it's called when it should not have been according to ETM trace. The error_shutdown is declared as no-return function with the "noreturn" attribute (source link if you want to look at full code): C Source Code (11 lines) The issue is that that ETM trace shows instructions from the "error_shutdown" are executed, which should make…

  • I had the same issue with 3.10 on Ubuntu 16.04 LTS, tried also recording over network with JTrace, no luck either. After tracing system calls with strace and USB monitoring with wireshark I could see that it starts sending few USB bulk packets, then stops. However at least I found this older combination works for on the STM32F407VE reference and custom STM32F427VI boards: SystemView 2.52d and JLink libs V662b (can see in process map this library is loaded). Hope this helps someone in the meantim…

  • After additional debugging sessions, even recording via network through ethernet interface does not work. As if the data recording component never runs at all. (connection through network from windows for fine though). In strace after pushing the "record" button on linux, some process is spawned, it goes over the devices in /sys subtree, finds USB JTrace device file, tries to talk some packets with it and it ends there. Recording on Windows from network with SystemView sometimes works, but you n…

  • I can attach 'strace' and/or 'ltrace' of SystemView execution, but they they are quite long and I don't see any obvious reason for the failure (like EACCES for denied access to device or such).

  • I am using JTrace Pro Cortex-M with the reference STM32F407 board on Ubuntu 16.04 LTS and this sample - wiki.segger.com/Use_SystemView_without_RTOS The issue: when I press 'start recording' button, nothing happens. Not even an error. I looked at similar threads (bad shared lib links) but none of these match my issue. I have the following packages installed on Ubuntu 16.04 LTS (should be the latest ones) : - jlink 6.622 - ozone:amd64 3.10.5 - systemview 3.10 Udev rules are installed properly - Oz…