Facebook
Google
GitHub
Linkedin
hello everyone, I need your help, I am an electronics engineer and I need someone to help me solve a problem concerning a TMS320C28x microcontroller which has a problem with its firmware, my question is: there is a possibility to access this microcontroller knowing that on the electronic card have is a jtag input and a jumper to put this card in boot mode, then I want to know the tools to do this job, so I inform you that I have another card identical to that with the same microcontroller which works normally so I can extract the content of the MCU and copy it to a new chip thank you in advance friends
TI TMS320F28021 microcontroller corrupted firmware
- Thread starter nassih
- Start date
Please provide the full part number of the TMS320C28x.
TMS320F28021PTT tanks sir
Your first roadblock would be code security. If this has been enabled then you are out of luck.
Otherwise you will need a JTAG connection and a development kit such as LAUNCHXL-F28027 and UniFlash.
Lastly, if you do the wrong thing you could end up bricking your working MCU.
Otherwise you will need a JTAG connection and a development kit such as LAUNCHXL-F28027 and UniFlash.
Lastly, if you do the wrong thing you could end up bricking your working MCU.
This is what is stated in the TMS320F2802x Datasheet
9.1.9 Security
The devices support high levels of security to protect the user firmware from being reverse engineered. The security features a 128-bit password (hardcoded for 16 wait states), which the user programs into the flash. One code security module (CSM) is used to protect the flash/OTP and the L0/L1 SARAM blocks. The security feature prevents unauthorized users from examining the memory contents through the JTAG port or trying to boot-load some undesirable software that would export the secure memory contents. To enable access to the secure blocks, the user must write the correct 128-bit KEY value that matches the value stored in the password locations within the Flash.
In addition to the CSM, the emulation code security logic (ECSL) has been implemented to prevent unauthorized users from stepping through secure code. Any code or data access to flash, user OTP, or L0 memory while the JTAG debug probe is connected will trip the ECSL and break the debug probe connection. To allow debug of secure code, while maintaining the CSM protection against secure memory reads, the user must write the correct value into the lower 64 bits of the KEY register (KEY0 - KEY3), which matches the value stored in the lower 64 bits of the password locations (PWL0 - PWL3) within the flash. Dummy reads of all 128 bits of the password in the flash must still be performed. If the lower 64 bits of the password locations are all ones (unprogrammed), then the KEY value does not need to match. During debug of secure code, operations like single-stepping is possible. However, the actual contents of the secure memory cannot be seen in the CCS window.
When power is applied to a secure device that is connected to a JTAG debug probe, the CPU will start executing and may execute an instruction that performs an access to a protected area. If this happens, the ECSL will trip and cause the JTAG circuitry to be deactivated. Under this condition, a host (such as a computer running CCS or flash programing software) would not be able to establish connection with the device.
The solution is to use the Wait boot option. In this mode, the device loops around a software breakpoint to allow a JTAG debug probe to be connected without tripping security. The user can then exit this mode once the JTAG debug probe is connected by using one of the emulation boot options as described in the Boot ROM chapter in the TMS320F2802x,TMS320F2802xx Technical Reference Manual. These devices do not support a hardware wait-in-reset mode.
Note
• When the code-security passwords are programmed, all addresses from 0x3F7F80 to 0x3F7FF5 cannot be used as program code or data. These locations must be programmed to 0x0000.
• If reprogramming of a secure device via JTAG may be needed in future, it is important to design the board in such a way that the device could be put in Wait boot mode upon power-up (when reprogramming is warranted). Otherwise, ECSL may deactivate the JTAG circuitry and prevent connection to the device, as mentioned earlier. If reconfiguring the device for Wait boot mode in the field is not practical, some mechanism must be implemented in the firmware to detect when a firmware update is warranted. Code could then branch to the desired bootloader in the bootROM. It could also branch to the Wait bootmode, at which point the JTAG debug probe could be connected, device unsecured and programming accomplished through JTAG itself.
• If the code security feature is not used, addresses 0x3F7F80 to 0x3F7FEF may be used for code or data. Addresses 0x3F7FF0 to 0x3F7FF5 are reserved for data and should not contain program code.
The 128-bit password (at 0x3F 7FF8 to 0x3F 7FFF) must not be programmed to zeros. Doing so would permanently lock the device.
9.1.9 Security
The devices support high levels of security to protect the user firmware from being reverse engineered. The security features a 128-bit password (hardcoded for 16 wait states), which the user programs into the flash. One code security module (CSM) is used to protect the flash/OTP and the L0/L1 SARAM blocks. The security feature prevents unauthorized users from examining the memory contents through the JTAG port or trying to boot-load some undesirable software that would export the secure memory contents. To enable access to the secure blocks, the user must write the correct 128-bit KEY value that matches the value stored in the password locations within the Flash.
In addition to the CSM, the emulation code security logic (ECSL) has been implemented to prevent unauthorized users from stepping through secure code. Any code or data access to flash, user OTP, or L0 memory while the JTAG debug probe is connected will trip the ECSL and break the debug probe connection. To allow debug of secure code, while maintaining the CSM protection against secure memory reads, the user must write the correct value into the lower 64 bits of the KEY register (KEY0 - KEY3), which matches the value stored in the lower 64 bits of the password locations (PWL0 - PWL3) within the flash. Dummy reads of all 128 bits of the password in the flash must still be performed. If the lower 64 bits of the password locations are all ones (unprogrammed), then the KEY value does not need to match. During debug of secure code, operations like single-stepping is possible. However, the actual contents of the secure memory cannot be seen in the CCS window.
When power is applied to a secure device that is connected to a JTAG debug probe, the CPU will start executing and may execute an instruction that performs an access to a protected area. If this happens, the ECSL will trip and cause the JTAG circuitry to be deactivated. Under this condition, a host (such as a computer running CCS or flash programing software) would not be able to establish connection with the device.
The solution is to use the Wait boot option. In this mode, the device loops around a software breakpoint to allow a JTAG debug probe to be connected without tripping security. The user can then exit this mode once the JTAG debug probe is connected by using one of the emulation boot options as described in the Boot ROM chapter in the TMS320F2802x,TMS320F2802xx Technical Reference Manual. These devices do not support a hardware wait-in-reset mode.
Note
• When the code-security passwords are programmed, all addresses from 0x3F7F80 to 0x3F7FF5 cannot be used as program code or data. These locations must be programmed to 0x0000.
• If reprogramming of a secure device via JTAG may be needed in future, it is important to design the board in such a way that the device could be put in Wait boot mode upon power-up (when reprogramming is warranted). Otherwise, ECSL may deactivate the JTAG circuitry and prevent connection to the device, as mentioned earlier. If reconfiguring the device for Wait boot mode in the field is not practical, some mechanism must be implemented in the firmware to detect when a firmware update is warranted. Code could then branch to the desired bootloader in the bootROM. It could also branch to the Wait bootmode, at which point the JTAG debug probe could be connected, device unsecured and programming accomplished through JTAG itself.
• If the code security feature is not used, addresses 0x3F7F80 to 0x3F7FEF may be used for code or data. Addresses 0x3F7FF0 to 0x3F7FF5 are reserved for data and should not contain program code.
The 128-bit password (at 0x3F 7FF8 to 0x3F 7FFF) must not be programmed to zeros. Doing so would permanently lock the device.
