Posts by tkutscha

Here's a JLink Commander script you might be able to leverage to help with unlocking/erasing the STM32F7 parts...

Cheers,
Tim

I just tested out the 5.11d beta JLink DLL and it now properly allows my SDK-based programs to bypass around the pop-up window that comes up when attempting to read non-flash memory on read-protected STM32F427 parts.

Thanks to Segger for fixing these issues. Our team is now ready to go for production. This issue can be marked SOLVED.

Cheers,
Tim
nLIGHT Corporation

Hi Niklas,

I've verified that JLinkSTM32.exe properly clears out the SPRMOD bit with the beta 5.11b version.
Thanks for fixing support for the SPRMOD bit on the STM32F42x/43x devices.

We can probably mark this one as SOLVED.

Cheers,
Tim

Hello,

I'm going to work with the JLink SDK and the beta software to see if we can work around this issue.
Feel free to redact this question or put on hold for now.

Thanks,
Tim

Hi Niklas,

Thanks for the update. I'll give it shot (along with the SDK) and try it out.

Cheers,
Tim

Hello Segger,

In your JLink.exe 5.10h software release today, I see the following behavior for STM32F427 chips:

If the device has read-protect option bytes set, JLink will automatically attempt to reset the read-protect bytes before running the commands in the script file.
During the attempt to reset the read-protect bits, the internal flash is erased. I think there's a window that popped up and asked the user if they
wanted to reset the read-protect bits. I checked the box that said
"never show this window again." How do I reset this software bit so that
I can optionally NOT clear the read-protect bits?

If I have an application that simply wishes to read/write JTAG registers without erasing the part, is there a command-line option I can use to stop the automatic reset of the read-protect bits?

Also, during the process to clear the read-protect bits, the SPRMOD bit in the option bytes is not cleared, preventing the part from being programmed. You might need to add some steps to the JLink.exe startup procedure to properly handle this, just like you do in the JLinkSTM32.exe program.

As you've mentioned in several posts, there are several new command-line options to the 5.10 version of JLink software. When will these be added to the documentation?

Thanks for your support!
Tim

Hello Niklas,

I just downloaded version 5.10h of the JLink.exe software that was released today.

If the option bits on an STM32F427 are set to 0x8FFFBBE1, the new JLinkSTM32.exe script properly resets all the option bits back to 0x0FFFAAED. Great!

HOWEVER: If the option bits are set to 0x8FFFAAE1, the new JLinkSTM32.exe script does nothing and leaves them at 0x8FFFAAE1.
If the SPRMOD bit is set (in all cases), I believe you need to set the read-protect bits to 0xBB before clearing both SPRMOD and the read-protect bits.

It also looks like JLink.exe has the older behavior of changing 0x8FFFBBE1 to 0x8FFFAAE1 on startup and erasing the part, but I'll start a new thread to address that.

Cheers,
Tim
nLIGHT Corporation

I tried JLink 5.10h that was released today and it fixes the issue!

Many thanks to the Segger development team for fixing this in a timely manner. This can be marked as [SOLVED]

Cheers,
Tim
nLIGHT Corporation

Hi All,

I've been having difficulty with the SPRMOD bit as well. This is a new bit in the STM32F427/429 chips that has some quirky behavior.

If I run JLink.exe 5.02 it sees that the part has read-protect bits set and tries to clear them (from 0xBB to 0xAA). The problem is that the SPRMOD bit in the options register is also set and it prevents the read-protect bits from being cleared.

In the STM32F4 manual, there's a section that says:

"The deactivation of the SPRMOD and/or the unprotection of PCROPed user sectors can
only occur when, at the same time, the RDP level changes from 1 to 0. If this condition is not
respected, the user option byte modification is cancelled and the write error WRPERR flag
is set. The modification of the users option bytes (BOR_LEV, RST_STDBY, ..) is allowed
since none of the active nWRPi bits is reset and SPRMOD is kept active."

I don't believe the JLinkSTM32.exe currently has the smarts to do the above procedure to clear out the SPRMOD bit.
I've even tried version 5.10 and 5.11(beta) to see if JLinkSTM32.exe clears it out, but it doesn't.

I've resorted to writing my own "unlock" .jlink file (see attached) that forces the read-protect bits to 0xBB and then writes the whole thing to 0x0FFFAAE1 (I like to set the BOR level). In the process, it clears out the whole program, but at least my board isn't bricked and is programmable.

Since JLink 5.11 is still in Beta, perhaps this issue can be fixed in the JLinkSTM32.exe script.

Cheers,
Tim

Hi All,

Just a quick update. I was able to do some more experimentation with Sophos anti-virus. When I set "Block access to malicious websites" to Off and reboot the computer, JLink.exe runs fine without any problems.

Related Sophos knowledgebase articles: 118563, 111225, 116970

Cheers,
Tim

Hi All,

I've been having issues with JLink.exe crashing when Sophos Endpoint Security (anti-virus software) is active.

I have a crash dump file, but it's too large to attach (3.4MB). Is there anyone I can send this to?
I did attach a .zip file with the Metadata and version info.
It appears there's an access violation or unhandled exception in swi_ifslsp.dll from Sophos.
Our company is using about 20 of the J-Link probes for engineering and production use.

It turns out there's an interesting workaround: if you run one instance of JLink.exe and let it sit in the background, other instances won't crash.

I loaded the memory dump file into Visual Studio 2012, but the debugger doesn't have access to the JLink.exe internals.

Thanks for any thoughts you might have or who I can share the crash dump file with.

Thanks,
Tim
nLIGHT Photonics
Vancouver, WA
JLinkSophosCrash2.zip