Search Results

I have the feeling that you do not understand what I am saying…. 0x0 in your FPGA is not ROM but RAM. Otherwise, J-Link could not write it. No matter if it will be ROM in the final design / silicon, it is RAM now. In uVision you have told it to be flash, so uVision expects a flash loader for that region. A loader that you do not have and which does not exist. Therefore the error message… Tell uVision that there is RAM @ 0x0 and it will simply perform a wrte, like J-Link Commander does.

The device should not and is not in boundary scan mode by default. You either set it via fuses or boot pins. Last but not least it was only a wild guess from my side. You should know what mode you configured your device into. Also, did you make sure that there is no application booting that interferes with debugging? E.g. a Linux that power-off debug clocks, remaps debug pins to GPIO, … Inhibiting the boot of your application by selecting a different boot source is something you should consider.

IRLen = 5 is not a valid IRLen for a DAP-TAP (the JTAG TAP used to access the ARM Cortex core). It should be IRLen = 4. I see 2 possible reasons for this: 1) Signal quality issue so that some bit(s) are not sampled correctly and this leads to a wrong ID / IRLen to be detected 2) The chip is in some kind of special mode (boundary scan, ...) where not the DAP-TAP (IRLen = 4) is visible on the JTAG chain but another TAP (IRLen = 5)

Hi, What exactly is the question? You have an M0 and want to download some code to it? The M0 has RAM @ 0x0? If there is really ROM @ 0x0, I do not see how you can write that at all…

Thanks for providing the scripts. We have adapted J-Link Commander accordingly, even though having only carriage return (\r) as a newline / line ending is somewhat strange... However, this adaption will be part of a new version, planned for 20th September. Unfortunately, for today's version it is too late.

You most probably have a unit that is out of support & maintenance and will therefore not get firmware updates.

No. J-Link Commander is not designed for production. There are currently no plans to add a command / extension like parameterized command / script. You may however create the script on demand, by the caller, depending on the file to program.

Can you please attach your scripts as originals, so all line endings etc are preserved. Indeed the output does look strange here and there.

There is no help given for such things. A later HW version may not run with an older firmware or may require a completely different BTL + firmware. So, it is usually not possible to swap 1-2 components and expect the unit to suddenly be, report to be and work as a new HW version / revision

Just curious: What do you need the write for? I would expect the application to setup the CP15 registers on its own, if it needs them to run correctly. Otherwise, your application would not work without a debugger being attached that does these writes for you… While CP15 access is not available in script files yet, I will check if there are any plans. So far, there was no action on this because there was not a single other need since that thread from 2020 which is now 3 years ago…

So what exactly is the question? If the SPI flash is not responding, there is either a wiring issue or other setup issue… But your screenshot does not really show a complete sequence. There should be 8-bit = 0x9F on MOSI, followed by 8-bit 0xFF/0x00. When there is the FF on MOSI, the MISO should indicate the ID of the flash. However, in your screenshot I only see the 8-bit 0x9F transmission and that one is not expected to show anything useful on MISO… There is no activity on the clock line after…

So far, I agree to your analysis, that the pattern in memory looks somewhat too similar to the observed transfers than being a coincidence… May I ask how you use J-Link? 1) gdb -> OpenOCD -> J-Link 2) gdb -> J-Link GDB Server -> J-Link Accessing the DHCSR is a common operation because it tells about the „halted“ state of the core. So it is for example accessed while the application is running and the debugger executes a IsHalted() check. Making the writes to the TAR and CSW ending up in RAM is h…

See the init steps. Build a „clear protection bits“ sequence by adding a „write status register“ sequence.

Can you post a screenshot of the old version that shows that multiple connects in a row work? I would be surprised if a popular chip like the STM32H5 series would be that broken in a generic way but nobody else ran into and reported it. Are you 100% sure that it was ONLY the J-Link version you changed and not also the target application that changed, which now maybe switches the debug pins to GPIO by accident or similar?

Did you check out this? segger.com/products/debug-prob…-for-development-purposes

There is a firmware update available for the EDU Mini that adds WinUSB support, so it can be enabled in J-Link Configurator. This allows you to use the EDU Mini in your setup. Note that you will be unable to perform FW updates under Windows arm64. You need to be natively under macOS for the update and may switch to the VM afterwards.

Ping. Is this thread still active?

What settings are you working with (JTAG speed)? What speed is the CPU running when reading the memory? How much memory are you trying to read? (1KB, 16KB, 128KB, …) How long does the reading take in J-Link Commander? (Next to not noticable, 1s, 2s, …)

The size limit cannot be increased by you and > 64 KB sounds insane for a flash algorithm… You may post your ELF file here or send it via PM, if you want us to have a look. BR Alex

Hi, As far as I can see, this is an x86 based core. There is no native J-Link support for x86 targets. You may be lucky with J-Link + OpenOCD. BR Alex