Search Results

Search results 1-20 of 30.

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

  • I've had my notebook and lot of eletronics stolen (f*cking lockdown), fortunately not JTrace and the special devboards. But I'd like to thank the Segger team especially for: - reinstall of Jlink tools, libraries, Ozone, etc. is easy (provided that udev rules are met - Ubuntu Linux 20.04 LTS) - there is a prompt whether to update JTrace firmware which really helps that you know whether and when you are updating - getting all the tools to work again was almost a breeze So thanks guys. I'll add an …

  • I think I solved it, adding: Source Code (32 lines)I have no idea why I can't indent the code or remove the comments, but it just works this way ¯\_(ツ)_/¯

  • For some time I've been using this to correctly reset device to "boardloader" (first execution stage, we have two additional, bootloader and firmware, each in separate ELF file): Source Code (17 lines) It worked quite well, though for some reason it doesn't anymore (currently Ozone 3.20c). The code jumps at the right address, but it gets stuck on TRNG initialization (STM32F427VI). However when resetting from JLinkExe via SYSRESETREQ & VECTRESET bit (or GDB connected to JLink GDB server), it alwa…

  • Quote from SEGGER - Alex: “You have the possibility to downgrade (see UM08001 which explains how to do it). However, in your case, it looks like something inhibits further FW replacement (no matter if a new or an old FW shall be flashed). So even your “recommendation for the future” would not solve anything here. ” Currently the FW stopped at "Firmware: J-Trace PRO V2 Cortex-M compiled Feb 2 2021 16:39:38" which I'd guess is relatively very recent. What would prevent other FW replacement, includ…

  • Yes, it seems that reflashing loop stopped. However for future it would be best if it was possible to flash a specific version of firmware (from JLink Commander for example, from a FW image file). Forced upgrade without possibility of downgrade is always gamble.

  • I noticed this message at least 3 times this week: Source Code (8 lines) Also I have no idea what causes it, is it Ozone, JLink Commander or something else? Nevertheless there was never any confirmation. The firmware I bought it with worked fine, but the intermediate upgrades had some weird bugs, which are hard to report if it randomly upgrades and disconnects at random moments (like in the middle of trace). Currently it stopped at "Firmware: J-Trace PRO V2 Cortex-M compiled Nov 12 2020 10:10:59…

  • You need to install jlink dependency. Instead of having it installed as system-wide dependency, you can download and extract the tar.gz version and use LD_LIBRARY_PATH. E.g. install jlink libraries system-wide and install STM32Cube to a local directory BTW your first post mentions you are missing the Qt4 dependency. So you first need to install Qt4 libraries first. In older Ubuntus it used to be like: "sudo apt-get install -y qt4-default" But 20.04 removed Qt4 libraries, so you need to install t…

  • Here we have schematics and board layout in Eagle: github.com/trezor/trezor-hardw…lectronics/trezor_model_t

  • 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…

  • [SOLVED] Jlink Script

    zamniah - - J-Link/Flasher related

    Post

    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…