Reply
Posts: 11
Registered: ‎07-16-2017

EFM32 bricked

Hello. I am brick my g880f128 with disabling HFRCO in first few instructions. Now, my j-link can't connect to device.
Same, as I read efm32g devices havent the AAP Extension feature. But, my j-link have 25khz freq max.
So, I haven't the official stk/ask, too, and this is last free efm32 in hundred kilometers around.

What I need to do?
Posts: 242
Registered: ‎11-17-2013

Re: EFM32 bricked

Why is you j-link limited to 25kHz? Try setting something faster in jlink commander first.

 

Otherwise, you could use some other µC you have lying around to toggle some pins in order to generate the AAP "unlock" instruction sequence.

 

One could even try to do this with some 74xx logic chips and a EEPROM or flash memory.

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

Yes, Its my fault, not the 25kHz but 25kkHz. 

I am trying to run Jlink with parameters:  -If SWD -Speed 5000 -Device Cortex-M3 -CommanderScript D:\EFR_deBrick.jlink

 

The script  file contains cthis code:

Spoiler
// Use SWD
si 1

// Reset strategy 2 (pin reset)
rsettype 2

r0

Sleep 1000

r1


SWDWriteDP 2 0x00000000
SWDWriteAP 1 0xCFACC118
SWDWriteAP 0 0x00000001

 

But all i have is:

Spoiler
SEGGER J-Link Commander V6.16f (Compiled Jul 3 2017 15:58:03)
DLL version V6.16f, compiled Jul 3 2017 15:57:26


Script file read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: -1
License(s): RDI,FlashDL,FlashBP,JFlash,GDBFull
VTref = 3.073V
Selecting SWD as current target interface.

Target connection not established yet but required for command.
Device "CORTEX-M3" selected.


Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning APs, stopping at first AHB-AP found.
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning APs, stopping at first AHB-AP found.

****** Error: Connect: Communication error when trying to read IDR of AP[0].
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning APs, stopping at first AHB-AP found.
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning APs, stopping at first AHB-AP found.
Cannot connect to target.
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning APs, stopping at first AHB-AP found.
Found SW-DP with ID 0x2BA01477
Could not power-up system power domain.
Scanning APs, stopping at first AHB-AP found.
Reset type UNKNOWN: ???


Sleep(1000)


Write DP register 2 = 0x00000000 ***ERROR

Write AP register 1 = 0xCFACC118 ***ERROR

Write AP register 0 = 0x00000001 ***ERROR

Script processing completed.

IDK why jlink cant write the registers. Please help. 

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

Ok. Looks like i have moved the wrong way.

 

I found another scripts for debriking EFM32. And they starts to work.

 

I using this script, what found here near.

Spoiler

// Unlock script for EFM32

// Run with command: JLink -If SWD -Speed 5000 -Device Cortex-M4 -CommanderScript <path>\EFM32_unlock.jlink


// EFM32_AAP_ID 0x16e60001 - Device is locked
// EFM32_AHBAP_ID 0x24770011 - Device is unlocked
// EFM32_DPID 0x2ba01477 - Debug port ID

// Initiate SWD interface (only needed if pin reset has been asserted after USB 0 was issued)
// Reset the device
r0
Sleep 100
r1
SWDSelect

// Read DPID - should return value EFM32_DPID
SWDReadDP 0

// SELECT register: APSEL = 0x0, APBANKSEL = 0xf
SWDWriteDP 2 0xf0

// Dummy read AP address 0xFC. Ignore this value
SWDReadAP 3

// Read AP address 0xFC. This should be EFM32_AAP_ID when the device is locked.
// If the device is NOT locked it will instead read EFM32_AHBAP_ID
SWDReadAP 3


r0
Sleep 100
r1
SWDSelect


// SELECT register: APBANKSEL = 0
SWDWriteDP 2 0x00

// Enter the unlock key to AAP_CMDKEY to enable writing to AAP_CMD
SWDWriteAP 1 0xcfacc118

// Set erase bit in AAP_CMD
SWDWriteAP 0 0x1

// Check the AAP_STATUS register for erase BUSY bit, erase should take ~40ms
// Do a dummy read first
SWDReadAP 2

// Should return '1' - erase in progress
SWDReadAP 2

// Wait for erase (200ms)
Sleep 200

// Reset the device
r0
Sleep 100
r1
Sleep 100

// Initiate SWD interface (only needed if pin reset has been asserted after USB 0 was issued)
SWDSelect

// Read DPID - should return value EFM32_DPID
SWDReadDP 0

// SELECT register: APSEL = 0x0, APBANKSEL = 0xf
SWDWriteDP 2 0xf0

// Dummy read AP address 0xFC. Ignore this value
SWDReadAP 3

// Read AP address 0xFC. This should be EFM32_AAP_ID when the device is locked.
// If the device is NOT locked it will instead read EFM32_AHBAP_ID
SWDReadAP 3

With result 

Spoiler
Select SWD by sending SWD switching sequence.
Found SWD-DP with ID 0x2BA01477

Read DP register 0 = 0x2BA01477

Write DP register 2 = 0x000000F0

Read AP register 3 = 0x00000000

Read AP register 3 = ERROR


Sleep(100)


Select SWD by sending SWD switching sequence.
Found SWD-DP with ID 0x2BA01477

Write DP register 2 = 0x00000000

Write AP register 1 = 0xCFACC118

Write AP register 0 = 0x00000001

Read AP register 2 = ERROR

Read AP register 2 = ERROR


This says, what DEVICEERASE flag is writes, but MCU starts to ignore calls after that. 

 

Posts: 65
Registered: ‎05-19-2016

Re: EFM32 bricked

This is an interesting problem.

 

Can you try the following and post your results?

 

// Run with command: JLink -If SWD -Speed 6000 -Device Cortex-M4 -CommanderScript <path>\EFM32_unlock.jlink

 

and also

 

// Run with command: JLink -If SWD -Speed 6500 -Device Cortex-M4 -CommanderScript <path>\EFM32_unlock.jlink

 

from some reading, apparently the Silabs ARM cores can support upto 6.9 Mhz on the SWD clock before violating the setup/hold timing so very curious to hear about your results.

 

references:

http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/Debug-Unlock-with-J-link-commander/ta-p/182...

 

http://community.silabs.com/t5/32-bit-MCU/Maximum-frequency-of-SW-clock/td-p/108103

Posts: 65
Registered: ‎05-19-2016

Re: EFM32 bricked

@Niburugecko, also review this procedure:

 

http://community.silabs.com/t5/32-bit-MCU/unlock-external-EFM32ZG/m-p/195705#M14237

 

you will have to review the firmware for your CPU but the idea may work for your case. Interesting how the SWCLK is configured for 12Mhz by this poster (credit: aviral). Summary is that you have a very small window to perform the task of erasing the corrupted flash memory space before you will lose control with the external tool. Crank up the SWCLK value and post your results.

 

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

Thanks for the answer, but speed changes doesn't help me.

Whats about method you gave me with link, i have no STK or DVK to upgrade it. 

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

 Im trying many speeds, 5000, 6000, 6500, 12000 and 25000 kHz. But the results always same, i am post its higher.

Posts: 65
Registered: ‎05-19-2016

Re: EFM32 bricked

hmm...very interested to study this in depth but will take some time to review. Wish to work with our own hardware for this SWD specification.

 

Have you seen this idea?

 

http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/Recover-EFM32-or-EFM8-kit-that-was-bricked-...

 

Unless the CPU is electrically damaged which does not appear to be your case, it should be possible to revive the CPU using more precise timing (under 47us) to erase the corrupted flash. That is our understanding.

 

Have you tested this idea?

 

http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/Unlock-a-Bricked-EFM32/ta-p/122776

 

Using the "Unlock Debug Access" radio button? This method is supposed to quickly perform a flash erase using the same toolchain and J-link interface and do so under 47us (AAP window).

 

 

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

 I'm sure that MCU is not damadged. 

I know about 47us window.

 

"Unlock Debug Access" is only available with STK\SDK, i havent them. I have only PCB with EFM32G and J-Link. 

 

I am tryed to freeze MCU, with liquid gas, to reduce HF RCI freq, but it seems doesnt work.

 

Posts: 3,021
Registered: ‎02-07-2002

Re: EFM32 bricked


Niburugecko wrote:

"Unlock Debug Access" is only available with STK\SDK, i havent them. I have only PCB with EFM32G and J-Link. 

 

I am tryed to freeze MCU, with liquid gas, to reduce HF RCI freq, but it seems doesnt work. 


Wouldn't it be easier to just get an STK? It's not like they cost a fortune.

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

Offtopic

Spoiler

 

Like 1\4 of my salary, and arriving in months.

 

Posts: 3,021
Registered: ‎02-07-2002

Re: EFM32 bricked

If €28 is one quarter of your salary I really pity you. Unless you meant hourly salary Robot wink

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

It is. But question - why J-link have error when reading AP registers is not resolved. 

Highlighted
Posts: 65
Registered: ‎05-19-2016

Re: EFM32 bricked

Is the J-LINK an original or clone? Just thinking that perhaps the clone J-LINK tools may not be able to support all of the commands.

 

When you change the J-LINK speed parameter, does the timing change on the SWCLK? Can you check with a scope?

 

In theory, guessing that the posted procedures and J-LINK tool should work but otherwise, what other hardware do you have? Does your PC have a parallel port?

 

As far as we know, the J-LINK firmware is custom (closed source) to Segger so no idea on what it cannot do using the SWD interface. An alternate plan is to develop code using another micro or similar hardware in an attempt to fix the issue.

 

The best solution is to try to source another kit to move forward. You must be in a very remote part of the world for delivery to take months to your location? At least you have access to internet Robot Happy

Posts: 3,021
Registered: ‎02-07-2002

Re: EFM32 bricked

AFAIK the unlocking procedure was originally only present in the EFM32 (W)STK/DK and not in the original Segger J-Link. But maybe that has changed over the past years.

Posts: 65
Registered: ‎05-19-2016

Re: EFM32 bricked

AFAIK the unlocking procedure was originally only present in the EFM32 (W)STK/DK and not in the original Segger J-Link. But maybe that has changed over the past years.

 

>> Did not know that. Very good information. In light of these details, it should be possible to mimic the spec to beat the 47us timeframe to bit-bang the SWD handshake using external tools (another micro, FPGA, old school parallel port, etc.).

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

1.Clone

2.Its not changed. Robot surprised Its constantly 250kHz

3. I think problem not in JLink, but in commands and sequence, and speed now...

4. Its no all, curiosity too.

 

 

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

Where i can learn more about this procedure?

Posts: 65
Registered: ‎05-19-2016

Re: EFM32 bricked

That is what we suspected. If the J-LINK cannot go faster than 250khz, then this tool cannot perform the erase in the required under 47us.

 

Do you have access to other micros / PCI or PCIe (PCI express) parallel port that is not usb driven?

 

----

 

just saw your request for more information:

 

http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/Debug-Unlock-with-J-link-commander/ta-p/182...

 

http://markdingst.blogspot.ca/2014/03/programming-internal-sram-over-swd.html

 

Again, you need some fast bit banging GPIO solution to perform the SWD communication to reset the micro -> perform the flash erase and quit -> all of this in under 47us else game over and start again.

 

Interesting problem but what tools would you have that can perform the external GPIO bit banging? Do you have other Silabs boards / micros?

 

 

Posts: 65
Registered: ‎05-19-2016

Re: EFM32 bricked

and this document is excellent for a read about the SWD operation:

 

https://www.silabs.com/documents/public/application-notes/an0062.pdf

Posts: 11
Registered: ‎07-16-2017

Re: EFM32 bricked

ok. Thats all i already read. But thank you, much.

Now, im try to do something with my jlink, to increase speed.