Hey guys, i tried to access the internal RAM and Flash of the MAC7116 (the MCU driving the Convers+) via JTAG. It turns out that this was a bad idea.... because after playing around a bit i powered the unit off and after turning it on it would not start any more. First, i thought i did something wrong in wiring or JTAG setup, because i could still read the Chip-ID and connect via JTAG but could not halt the CPU to access RAM or FLASH.
After some time i decide to read the datasheet of the MAC (yeah, should have done this before... i know!) and it turns out that the chip has some "intrusion protection" security modes which will store some kind of lock information into the internal flash if someone tries to read or read portions of the internal RAM or Flash. The lock mode can only be left by sending an 8 byte long security access code (vendor specific) via a special command procedure, or by completly erasing and reprogramming the chips flash.
Now, i try to find a way to do this, because i guess searching for the password is a waste of time...
How to recover bricked Convers+ (SOLVED)
Re: How to recover bricked Convers+
2^64 = password brute force will take too long
We have in free access:
Main flash after 0x5000
Extended flash after 0x3000000
So we need only PBL (0x0000 - 0x5000)
Maybe try to use ReadMemoryByAddress or RequestDownload OBD commands to download PBL?
We have in free access:
Main flash after 0x5000
Extended flash after 0x3000000
So we need only PBL (0x0000 - 0x5000)
Maybe try to use ReadMemoryByAddress or RequestDownload OBD commands to download PBL?
Not native English speaker
IPC hacker, embedded cracker, tamer of bears & beers
IPC hacker, embedded cracker, tamer of bears & beers
Re: How to recover bricked Convers+
The MCU is in a locked state and does not execute any software. So the only way may be to access it via JTAG.
Today i attached my Segger J-Link adapter to the JTAG port of the MAC7116. I measured out the pins of the header from the parts pins and got this: Fortunately the Seggers J-Flash tool supports the MAC7116 directly, but any attempt to "Connect" will timeout. Electrically the interface works as i can read the CPU ID from JTAG. But it refuses to execute any write or read attempt to Flash, RAM or IO registers of the device. This can only be done when the CPU is set to HALT mode, which is a JTAG instruction. But this instruction is not executed and so i have no chance to do anything.
I try to read as much as possible from the datasheets and forums to find out how to recover from this, but now i'm totally confused and need help to sort it out. It seems that there must be a special recovery procedure applied right after reset.For now i could'nt make out a /RESET pin at the header above. Only /TRST, but this is for the JTAG TAP only, not for the CPU. The /TRST signal is directly tied to the chips /RESET pin, so every JTAG-TAP reset is also a chip reset. This is not a problem, just seldom.
Today i attached my Segger J-Link adapter to the JTAG port of the MAC7116. I measured out the pins of the header from the parts pins and got this: Fortunately the Seggers J-Flash tool supports the MAC7116 directly, but any attempt to "Connect" will timeout. Electrically the interface works as i can read the CPU ID from JTAG. But it refuses to execute any write or read attempt to Flash, RAM or IO registers of the device. This can only be done when the CPU is set to HALT mode, which is a JTAG instruction. But this instruction is not executed and so i have no chance to do anything.
I try to read as much as possible from the datasheets and forums to find out how to recover from this, but now i'm totally confused and need help to sort it out. It seems that there must be a special recovery procedure applied right after reset.
You do not have the required permissions to view the files attached to this post.
Re: How to recover bricked Convers+
Now I see why you said not to use the JTAG, I’ll have a look around the forums and see if I can find any information on unbricking,
Digimod
Re: How to recover bricked Convers+
Imread in the docs that there is some kond of security locking information in the program flash (the MAC has two flashes, a big one for program 1 mb, and a smaller one for data 48 kb) around a low address 0x400 something. So, if one writes over this area the chip may get locked after next reset. But i am shure i did not wrote anything to the chip, i just wanted to read it put. So there must also be some kind of read protection which also locks it.
Now, i try to,find put which bootmode the chip uses. It is made up my reading two IO pins (MODA and MODB) after /reset rises high. Depend on this mode the memory map is choosen and also one mode let the chip boots from external flash by mapping it to 0x00000000. So if this mode is used, there maybe nothing in the chips own flash... but if not, it may that this bootloader is not in the usual updatefiles because it never changes...
One thing to get this information may be in desoldering the external flash, dump it and look if and where i can find the data of the flash in the update files. If they match 1:1 it could also be that there is special code in chips internal flash...
The SBL bootloader provided with the update may only for temporary store in the chips RAM while doing the update.
Now, i try to,find put which bootmode the chip uses. It is made up my reading two IO pins (MODA and MODB) after /reset rises high. Depend on this mode the memory map is choosen and also one mode let the chip boots from external flash by mapping it to 0x00000000. So if this mode is used, there maybe nothing in the chips own flash... but if not, it may that this bootloader is not in the usual updatefiles because it never changes...
One thing to get this information may be in desoldering the external flash, dump it and look if and where i can find the data of the flash in the update files. If they match 1:1 it could also be that there is special code in chips internal flash...
The SBL bootloader provided with the update may only for temporary store in the chips RAM while doing the update.
Re: How to recover bricked Convers+
I traced down both pins, MODA and MODB tied via 1k resistors to GND. So both are 0. As of Chapter 7 "Modes of Operation" of the MAC7100 Reference manual "The values of the configuration pins MODA and MODB are latched on the rising edge of the RESET signal". The signal i don't know is the "security state of the on-chip program Flash memory", which leaves two possible modes:
Normal Single-Chip Mode when flash not secured and Secured Single-Chip Mode when secured.
In "Single Chip Mode" the system boots from the internal program Flash. If the device is secured, the external bus interface is unavailable. However, if the device is unsecured, the system may be reconfigured by software to enable the external bus.
This also leads to this memory map:
0x0000 0000 – 0x000F FFFF = 1 MB Internal Program Flash
0x0010 0000 – 0x1FFF FFFF = Reserved
0x2000 0000 – 0x3FFF FFFF = External Bus Interface 1 (disabled at reset, must be enabled via software)
0x4000 0000 – 0x4000 CFFF = 48 KB Internal SRAM
0x4000 D000 – 0xFBFF FFFF = Reserved
0xE000 0000 = Periphal bus
0xFC00 0000 – 0xFFFF FFFF = Peripheral control registers and programming interface
0xFE00 0000 – 0xFE00 7FFF = 32 KB Data Flash
In unsecured single-chip mode, booting is performed from the program Flash and the following resources are available:
• Program and data Flash
• External bus interface (must be enabled via software)
• Full debug functionality
The secured single-chip mode is typically used to execute code in a final application, where a software bootloader is not required. The program Flash is used for boot code. Resource availability differs from normal single-chip mode as follows:
• Program and data Flash are available
• External bus interface is not available
• Debug functionality is limited to Flash lockout recovery
Normal Single-Chip Mode when flash not secured and Secured Single-Chip Mode when secured.
In "Single Chip Mode" the system boots from the internal program Flash. If the device is secured, the external bus interface is unavailable. However, if the device is unsecured, the system may be reconfigured by software to enable the external bus.
This also leads to this memory map:
0x0000 0000 – 0x000F FFFF = 1 MB Internal Program Flash
0x0010 0000 – 0x1FFF FFFF = Reserved
0x2000 0000 – 0x3FFF FFFF = External Bus Interface 1 (disabled at reset, must be enabled via software)
0x4000 0000 – 0x4000 CFFF = 48 KB Internal SRAM
0x4000 D000 – 0xFBFF FFFF = Reserved
0xE000 0000 = Periphal bus
0xFC00 0000 – 0xFFFF FFFF = Peripheral control registers and programming interface
0xFE00 0000 – 0xFE00 7FFF = 32 KB Data Flash
In unsecured single-chip mode, booting is performed from the program Flash and the following resources are available:
• Program and data Flash
• External bus interface (must be enabled via software)
• Full debug functionality
The secured single-chip mode is typically used to execute code in a final application, where a software bootloader is not required. The program Flash is used for boot code. Resource availability differs from normal single-chip mode as follows:
• Program and data Flash are available
• External bus interface is not available
• Debug functionality is limited to Flash lockout recovery
Re: How to recover bricked Convers+
I made further progress on this issue. After hours of reading and testing i found out two things:
1.) The Segger J-Flash tool uses "Reset" as initialization command right after trying to "Connect" to the target. By default it uses parameter "Type = 0" and "Delay = 0 ms". Reset is a meta-function which implies different things choosen by the "Type". Delay means how long to wait AFTER the reset is issued to let the CPU come up. After i change the delay to "20 ms" i get a different result: 2.) One of the lockout procedures tell to set chip into expanded mode by set MODB to HIGH (5V): After doing so, i can connect, but only the Segger can't download RAM code (which is normal, because in expanded mode, the internal Flashes are disabled and the external Flash is mapped to address 0x0000) and determine CPU clock. So now i'm looking for a way to issue the mass erase commands to clear the security bits inside the MAC flash.
For this i need to setup some things into the memory mapped periphal registers, like setting the CPUCLK and such... let's see if this is going to work now.
1.) The Segger J-Flash tool uses "Reset" as initialization command right after trying to "Connect" to the target. By default it uses parameter "Type = 0" and "Delay = 0 ms". Reset is a meta-function which implies different things choosen by the "Type". Delay means how long to wait AFTER the reset is issued to let the CPU come up. After i change the delay to "20 ms" i get a different result: 2.) One of the lockout procedures tell to set chip into expanded mode by set MODB to HIGH (5V): After doing so, i can connect, but only the Segger can't download RAM code (which is normal, because in expanded mode, the internal Flashes are disabled and the external Flash is mapped to address 0x0000) and determine CPU clock. So now i'm looking for a way to issue the mass erase commands to clear the security bits inside the MAC flash.
For this i need to setup some things into the memory mapped periphal registers, like setting the CPUCLK and such... let's see if this is going to work now.
You do not have the required permissions to view the files attached to this post.
Re: How to recover bricked Convers+
What i am really asking myself is, if the contents of the MAC internal program and data flash is contained within the update files of the Convers, or if it is not used in the end. I wonder why the developers places an external flash and eeprom on the board, if the MAC contains both. More suspicious is, why they don't used the internal data flash to store the eeproms contents, because this would,be more secureable...
Becuase of the fixed normal flash operation mode (MODA and MODB both tied to GND) there must be some internal code, let's call it PBL (primary bootloader) which does some inits and finally hand access over to external flash contents.
If this bootloader is not contained somewhere in update files, and i need to erase the chips content, i still do not have a working device.
Becuase of the fixed normal flash operation mode (MODA and MODB both tied to GND) there must be some internal code, let's call it PBL (primary bootloader) which does some inits and finally hand access over to external flash contents.
If this bootloader is not contained somewhere in update files, and i need to erase the chips content, i still do not have a working device.
Re: How to recover bricked Convers+
Anyway, to unsecure the device, the following steps are needed if the backdoor key (8 bytes long) are not known:
The CFM get's it's commands through the "CFM Command Register (CFMCMD)", a 8-Bit register (only 7 Bits used) located at memory address 0xFC0F0024.
It knows these commands:
0x05 Blank Check
0x06 Page Erase Verify
0x20 Program Word/Half Word
0x40 Page Erase
0x41 Mass Erase
0x65 Data Signature
In order to generate a "mass ersase" we need to write "0x41" at 0xFC0F0024, right after reset into extended chip mode. Let's take a look into the docs: "The mass erase operation will erase all Flash memory addresses using an embedded algorithm. All of the Flash (data and program) must be unsecured before this operation. After a mass erase, the Flash will be secured unless user writes to the security configuration word in Flash."
1. Write to any Flash memory address to start the command write sequence for the mass erase command. The specific address and data written during the mass erase command write sequence will be ignored.
2. Write the mass erase command, 0x41, to the CFMCMD register.
3. Write 0b1 to CBEIF to clear it, and to launch the mass erase command.
If any Flash logical sector is protected, the PVIOL flag in the CFMUSTAT register will set during the command write sequence and the mass erase command will not launch. Once the mass erase command has successfully launched, the CCIF flag in the CFMUSTAT register will set after the mass erase operation has completed unless a new command write sequence has been buffered.
So there must be some kind of "sequence" to launch CFM commands. Just writing to the register does not seem to be sufficient. Also, the execution depends on some other flags and they have a runtime (sure), which is reflected through readable flags. We need to "wait" for execution to be finished before issueing the next command. Here is what the docs say about the command sequence:
The Flash command controller is used to supervise the command write sequence to execute blank check, page erase verify, program, page erase, mass erase and data signature algorithms.
A specific sequence, consisting of three steps, must be strictly followed, with writes to the CFM not permitted between the steps. However, Flash register and array reads are allowed during a command write sequence. The basic command write sequence is as follows:
1. Write to one or more addresses in the Flash memory.
2. Write a valid command to the CFMCMD register.
3. Launch the command by writing a 0b1 to CFMUSTAT[CBEIF] (which clears the flag).
This is excatly what we seen above. One must write to an address (which is a 32bit write operation), which does not do anything without the now following write of the command to execute. But also this does not do anything unless the "GO" flag is raised in the last step, by writing a bit. After this we need to watch the bit until it is cleared (0) to show us, the command was executed.
But there are some stakes to climb first:
Prior to issuing any commands, it is necessary to write the CFMCLKD register to set the ratio between the IP bus clock frequency and fNVMOP such that fNVMOP is within the range of 150 KHz to 200 KHz.
- Execute a mass erase command to the internal flash (program + data erased)
- execute a blank check on the flashes (only if this returns "all blank" the next steps are done)
- program the "Flash Security Word" (offset 0x0414) bits corresponding to the CFMSEC[SEC] field to "Flash memory not secured" (0b10)
- RESET the device into expanded mode (MODA=0, MODB=1) to execute boot code from external memory.
The CFM get's it's commands through the "CFM Command Register (CFMCMD)", a 8-Bit register (only 7 Bits used) located at memory address 0xFC0F0024.
It knows these commands:
0x05 Blank Check
0x06 Page Erase Verify
0x20 Program Word/Half Word
0x40 Page Erase
0x41 Mass Erase
0x65 Data Signature
In order to generate a "mass ersase" we need to write "0x41" at 0xFC0F0024, right after reset into extended chip mode. Let's take a look into the docs: "The mass erase operation will erase all Flash memory addresses using an embedded algorithm. All of the Flash (data and program) must be unsecured before this operation. After a mass erase, the Flash will be secured unless user writes to the security configuration word in Flash."
1. Write to any Flash memory address to start the command write sequence for the mass erase command. The specific address and data written during the mass erase command write sequence will be ignored.
2. Write the mass erase command, 0x41, to the CFMCMD register.
3. Write 0b1 to CBEIF to clear it, and to launch the mass erase command.
If any Flash logical sector is protected, the PVIOL flag in the CFMUSTAT register will set during the command write sequence and the mass erase command will not launch. Once the mass erase command has successfully launched, the CCIF flag in the CFMUSTAT register will set after the mass erase operation has completed unless a new command write sequence has been buffered.
So there must be some kind of "sequence" to launch CFM commands. Just writing to the register does not seem to be sufficient. Also, the execution depends on some other flags and they have a runtime (sure), which is reflected through readable flags. We need to "wait" for execution to be finished before issueing the next command. Here is what the docs say about the command sequence:
The Flash command controller is used to supervise the command write sequence to execute blank check, page erase verify, program, page erase, mass erase and data signature algorithms.
A specific sequence, consisting of three steps, must be strictly followed, with writes to the CFM not permitted between the steps. However, Flash register and array reads are allowed during a command write sequence. The basic command write sequence is as follows:
1. Write to one or more addresses in the Flash memory.
2. Write a valid command to the CFMCMD register.
3. Launch the command by writing a 0b1 to CFMUSTAT[CBEIF] (which clears the flag).
This is excatly what we seen above. One must write to an address (which is a 32bit write operation), which does not do anything without the now following write of the command to execute. But also this does not do anything unless the "GO" flag is raised in the last step, by writing a bit. After this we need to watch the bit until it is cleared (0) to show us, the command was executed.
But there are some stakes to climb first:
Prior to issuing any commands, it is necessary to write the CFMCLKD register to set the ratio between the IP bus clock frequency and fNVMOP such that fNVMOP is within the range of 150 KHz to 200 KHz.
Re: How to recover bricked Convers+
When i look at the update-files for the cluster, they come with three parts:
1.) 7M2T-14C026-BC.vbf (~2MB) => This content is for the external Flash, because it does not fit anywhere else (rembember, the MAC has only 1MB internal program Flash). Also, when i look into the data i found our images there. This is only data with no executeable code inside. From the VBF-file the data is stored at memory location 0x30000000 with a size of 0x00200000 (=2MB).
2.) 7M2T-14C025-AA.vbf (~3KB) => This is a RAM-code loaded into the SRAM of the MAC7116 and controlls the further update process. It is directly ARM7 executeable code, not booted, but just run after uploaded. It shure has code to communicate via CAN to read the remaining data through CAN-Frames. But also needs code to unlock the internal and external flash in order to reprogram it. I'm pretty shure the unlock password (8 bytes) is located herein! Or the tool uses the general purpose unlock procedure by mass erasing the chip. This would be very dangerous because if the communication brokes down afterwarts, the unit is bricked. But on the other hand it has no backup flash nor enough SRAM to temporarilly store the downloads before updating the flashes.
3.) 7M2T-14C026-AG.vbf (~1MB) => This seems to be the executeable ARM7 code of the internal MAC's flash, containing the Convers software. So this is, what i need to write to my chip to get it back to life. But as from the size (0xFB000) and the infos in the VBF-wrapper file, it is intend to be loaded at 0x5000 into the flash (and then fills up the flash until the end), so the relevant boot part 0x0000 - 0x4FFF is still missing!.
These are (in reverse order to explain it better):1.) 7M2T-14C026-BC.vbf (~2MB) => This content is for the external Flash, because it does not fit anywhere else (rembember, the MAC has only 1MB internal program Flash). Also, when i look into the data i found our images there. This is only data with no executeable code inside. From the VBF-file the data is stored at memory location 0x30000000 with a size of 0x00200000 (=2MB).
2.) 7M2T-14C025-AA.vbf (~3KB) => This is a RAM-code loaded into the SRAM of the MAC7116 and controlls the further update process. It is directly ARM7 executeable code, not booted, but just run after uploaded. It shure has code to communicate via CAN to read the remaining data through CAN-Frames. But also needs code to unlock the internal and external flash in order to reprogram it. I'm pretty shure the unlock password (8 bytes) is located herein! Or the tool uses the general purpose unlock procedure by mass erasing the chip. This would be very dangerous because if the communication brokes down afterwarts, the unit is bricked. But on the other hand it has no backup flash nor enough SRAM to temporarilly store the downloads before updating the flashes.
3.) 7M2T-14C026-AG.vbf (~1MB) => This seems to be the executeable ARM7 code of the internal MAC's flash, containing the Convers software. So this is, what i need to write to my chip to get it back to life. But as from the size (0xFB000) and the infos in the VBF-wrapper file, it is intend to be loaded at 0x5000 into the flash (and then fills up the flash until the end), so the relevant boot part 0x0000 - 0x4FFF is still missing!.
You do not have the required permissions to view the files attached to this post.