Search Results

I've tried 3 of my devices - github.com/trezor/trezor-firmw…s/hardware/model-t/assets (there is schematics as well) and they randomly exhibit this behavior. Just 6 months ago I didn't have this issue. Also tried dev boards (STM32F407 and STM32F429 disco), the 429 version also hiccups ocassionally with thing like "WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1." Tried the old drivers, JLinkARM.dll V6.62b and also new drivers, JLinkARM.dll V6.82f. The newer drivers don't complain about …

This is probably not your exact use case, but since I spent a lot of time getting ITM PC samples trace via SWO on STM32 with JLink, lot of it spent looking at logic analyzer, maybe you can get someful information out of it: github.com/hiviah/ITM-howto-JLink-STLink

After some experimenting is seems that JTrace does not like if target CPU is powercycled. That's when the weird behavior starts. Letting the CPU run for a whole day and resetting via JLink commander does not trigger this behavior.

This misidentification of CPU - Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M4) - started happening recently to me, after I've been using the device with JTrace for about half a year. It seems random, it seems to appear when device is powered on for a while. However the same device works fine with STLink. Device: STM32F427VI Once the misidentification happens, the device cannot be debugged or flashed via JTrace, Ozone won't work. Power cycling JTrace and d…

There is loadfile which supports hex files, you could probably load it with those two commands. I use two-part firmware which is loaded with loadbin like this: Shell-Script (8 lines) If you need to specify addresses, you probably need to convert the files to .bin or .elf with objcopy or something similar.

OK, solved this. Apparently STM32 Cube IDE sets prescalers, etc. wrong and SWOViewer acts weird. I got it working via gdb scripts from orbuculum, this enables SWO ITM PC sampling, core clock 168 MHz, SWO baud rate 2Mbaud. Commands for GDB: Source Code (23 lines) This enables measuring the code profile via ITM with orbtop or pcsampl: Shell-Script (23 lines) It would be nice if Ozone had ITM code profile in addition to ETM code profile, since for most board it's easier to get ITM working.

Quote from SEGGER - Nino: “That is not correct and the issue you are describing here is due to an incorrect project setup. For more information see here: wiki.segger.com/Debug_on_a_Target_with_Bootloader So the reset behaviour is always the same. The difference is only what happens after the reset. ” You are missing the point. JLink Commander has 9 different reset types (section 7.10 from JLink/JTrace Guide). The default reset strategy is via AIRCR.SYSRESETREQ: Source Code (5 lines)It would be a…

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…